Warum ist das so? Weil Usability oft erst dann auffällt, wenn sie fehlt. Sie lässt sich schwer messen, wird nicht immer spezifiziert – und im Alltag häufig durch technische Machbarkeit, Zeitdruck oder Gewohnheit überlagert. Dabei merken wir alle sehr schnell, wie wichtig sie ist, wenn wir selbst betroffen sind.
Die besten Features sind die, die keiner bemerkt
Ich kenne das zum Beispiel aus meinem Alltag. Am Morgen will ich mir schnell eine Tasse Milch aufwärmen – eigentlich eine simple Aufgabe. Aber der Mikrowellenofen macht daraus ein kleines Geduldsspiel:
Erstmal das Touchpanel „wecken“. Und anstatt die letzten Einstellungen einfach wieder zu verwenden, muss ich jedesmal wieder die Leistung einstellen und die Zeit wählen. Die Touchfelder reagieren träge oder zu schnell, manchmal überspringe ich versehentlich eine Auswahl.
Wenn man noch halb verschlafen ist, sorgt das für ordentlich Frust. Ich hab das dem Küchenbauer gesagt. Seine Antwort: „Seien Sie froh, dass Sie dieses Modell überhaupt noch bekommen haben. Die neueren sind noch schlimmer.“
Hmm - das hilft mir jetzt nicht wirklich weiter. Sollte ich dann doch mal dem Hersteller schreiben?
Debug-Interfaces: Der unterschätzte Usability-Brennpunkt
Und genau deshalb lohnt es sich, das Thema Usability auch in der Softwareentwicklung ernst zu nehmen.
Oft heißt es bei uns: „Das HMI-Design kommt vom Kunden, wir setzen nur um.“ Aber halt – es gibt ja auch die internen Schnittstellen. Ein Debug-Interface zum Beispiel.
Und da habe ich schon einiges erlebt:
- Befehle, die man – inklusive exakter Groß- und Kleinschreibung – fehlerfrei eintippen muss. Kein Leerzeichen zu viel!
- Ein Parameter in Dezimal eingegeben? Pech, das Interface erwartet Hexadezimal.
- Der eine Befehl will optionale Parameter ohne Bindestrich, der nächste mit.
- Rückmeldung, ob der Befehl erfolgreich ausgeführt wurde? Fehlanzeige.
Das alles nervt gigantisch. Aber warum definieren Entwickler solche Interfaces, die sie selbst tagtäglich nutzen müssen? Die Antwort könnte lauten: "Weil sie's können". Oder besser: "Weil sie's eben doch nicht können" und die Leidensfähigkeit schier grenzenlos ist.
Klein, aber oho: Usability für interne Tools
oder: Hex, Dez, Enum – macht’s dem User einfach (auch wenn er Entwickler ist)
Aber wie kann gute Usability einer solchen Schnittstelle dann aussehen? Hier ein paar Vorschläge - in einem aktuellen, real existierenden Projekt so umgesetzt:
- Groß-/Kleinschreibung ist egal
- Befehle können abgekürzt werden. Sobald zwei oder mehr Buchstaben für einen Befehl genügen (also nur ein Befehl mit diesen beginnt): Treffer!
- Ganz heißer Tipp: Backspace kann auch via Serial Terminal funktionieren
- Hexa- und Dezimalzahlen erlauben
- "sprechende" Bezeichner für z.B. I2C-Clients. Dann könnte ein Befehl, zum Setzen von Registern so aussehen: "i2c audio 0x4 32"
- Wenn ein Befehl eine Liste von Optionen erlaubt, dann sollte der Befehl ohne Parameter die Optionen auflisten. Das erspart lästige Suche in der Dokumentation. Geheimtip: Ist der Parameter ein Enum-Typ, dann macht den iterierbar und stellt eine "c_str()"-Funktion zur Verfügung. Dazu mehr in einem anderen Blog-Artikel.
- Überhaupt: Das Debug-Interface sollte sich selbst dokumentieren. "help all" listet zum Beispiel alle Befehle und die jeweilige Hilfe dazu.
- In dem Projekt gibt's ein richtiges Filesystem? Na, dann bitte die Kommandos "dir", "del", "cat", "copy" implementieren. Ist nicht aufwändig, aber ungemein hilfreich im weiteren Projektverlauf oder für die Tester. Dann kann man schnell ein Backup einer Config-Datei anlegen, um sie später wiederherzustellen.
- Aliases für Befehle: Die Linuxer verwenden gerne "rm", Windows-User "del". Hey - warum nicht beiden das Leben erleichtern? Seid nett zueinander ;-)
So viel vorweg: Die Tester werden euch zu Füßen liegen. Und wenn dann auch noch die Kunden oder andere Zulieferer mit dem Interface arbeiten müssen, habt ihr mit Sicherheit einen Stein im Brett!