• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

Top-Usability-Probleme

Ich möchte eine Liste mit den Top-Schwierigkeiten bei der Bedienung
morderner Computersysteme (aus Anwendersicht) aufstellen. Das ganze ist
gedacht als eine Art Zusammenfassung meiner bisherigen Artikel:

http://plastictree.net/articles/thoughts_usage.de/
http://plastictree.net/articles/nowysiwyg.de/
http://plastictree.net/notes/win_not_userfriendly.de/
http://plastictree.net/articles/noms/

Langfristig strebe ich an, diese Auflistung an einer prominenten Stelle
zu plazieren. Genial wäre eine Nennung auf Slashdot o.ä. (mit einer
englischen Übersetzung natürlich).

Ich bitte um Kommentare, Anregungen, etc. Bislang sind es acht Punkte.
Viel mehr als 10 sind wohl nicht so gut. Das ganze sollte möglichst
kurz und knackig sein.


---- snip ----

(1) Sicherung der vom Benutzer eingegebenen Daten

Was der Benutzer eingibt, ist in der Regel das Produkt von Arbeit und
somit wertvoll.

In vielen Fällen werden Eingaben jedoch zunächst *nur* im RAM abgelegt.
System- oder Programmabstürze, versehentliches Drücken des Resetknopfes
oder versehentliches Schließen eines Anwendungsprogrammes[1] führen
somit zum Verlust der Eingaben. (Einige Anwendungsprogramme schreiben
zwar schon wärend der Eingabe im Hintergrund etwas auf die Festplatte;
dies ist aber längst nicht immer der Fall.)

Werden die Eingaben in eine Datei geschrieben, so liegen sie nun
immerhin an zwei Stellen im System: Einmal im RAM und einmal auf der
Festplatte. Im RAM sind die Daten aber nicht sonderlich sicher, und es
ist durchaus üblich, nach getaner Arbeit die Kopie im RAM zu vernichten
(zB. durch Schließen des Anwendungsprogrammes oder des jeweiligen
Puffers). Somit liegen sie letztlich doch wieder nur an nur *einer*
Stelle im System. Versehentliches Löschen oder Überschreiben der Datei
führt zum Verlust der Daten[2]. Änderungen am Inhalt der Datei können
nach dem Speichern und dem Schließen des Anwendungsprogrammes nicht mehr
rückgängig gemacht werden.

Es bleibt dem Benutzer überlassen, rechtzeitig Sicherheitskopien
anzulegen und auch frühere Versionen seiner Dateien zurückzulegen. Der
unbedarfte Benutzer macht sowas üblicherweise gar nicht, oder erst in
sehr, sehr späten Phasen seines Projektes. (Typisch ist, vor einer
solchen Sicherung dann erstmal "aufzuräumen", woraufhin nicht selten
auch wertvolle Dateien aus dem Weg geräumt werden.)


Vergleich mit der Unix-Konsole: Der Editor Vim verhält sich gut bei
unvorhergesehenen Ereignissen, da er alle paar Sekunden eine Sicherung
auf die Festplatte vornimmt und den Benutzer beim nächsten Start nach
einem Zwischenfall fragt, ob von dieser Sicherungskopie ausgegangen
werden soll.

Das Problem, dass die Daten erstmal nur ein *einem* Ort liegen, hat man
aber auch dort. Auf einem gut administrierten Unix-System laufen im
Hintergrund Backup-Skripte, so dass man in der Regel (über die
Systemadministration) die Version einer Datei von gestern oder letzter
Woche zurückerhalten kann.

Alternativen und Abhilfen: Man muss schon ab der ersten Version (eher
noch ab der nullten Version) eines Dokumentes eine Sicherungsstrategie
haben und umsetzen. Eine gute Idee ist, von Anfang an ein
Versionsmanagementsystem (zB.  Subversion oder Monotone) einzusetzen.
Lösungen dieser Art sind dem durchschnittlichen Benutzer jedoch völlig
fremd und werden ihm durch die typische Softwareumgebung auch nicht
nahegebracht.



(2) Datensicherheit bei webbasierten Anwendungen
(Webmail, Webforen, Wikis, Formulare, etc.)

Dies ist ein besonders brisanter Spezialfall von (1). Denn die heutigen
Webbrowser erlauben es dem Benutzer nicht, eingegebene Daten
zwischendurch auf der Festplatte abzulegen. Man muss erst alles fertig
eingeben, dann kann man es abschicken. Mozilla zB. warnt nicht einmal,
wenn eingegebene Daten verlorengehen würden beim Schließen des
Browserfensters. Ein Systemabsturz, ein Absturz des Browsers, ein
versehentlicher Reset oder ein Stromausfall sind ebenso nicht mit
eingeplant. In vielen Fällen verliert man seine Eingaben auch, wenn die
Verbindung zum Server während der Arbeit unterbrochen wird. Man merkt es
aber erst beim Abschicken. Dann heißt es, man möge sich neu einloggen,
und oft ist es nicht möglich, seine vorigen Eingaben danach
wiederzubeleben (oder es ist nicht klar, wie das gehen sollte). Einige
Server haben auch selbst ein Timeout, nach dem sie eine erneute
Anmeldung fordern, so dass einen auch eine stablie Internetleitung nicht
vor dieser Art des Datenverlustes schützt.

Dies sind alles prähistorische Zustände, vor welchem Hintergrund es
geradezu eine Farce ist, dass webbasierte "Lösungen" als besonders
fortschrittlich gelten.


Vergleich mit der Unix-Konsole: Der näheste Vergleich ist wohl der mit
dem Arbeiten über Secure-Shell (SSH). Dabei arbeitet man im wesentlichen
in der Unix-Umgebung des Servers. Somit unterscheidet sich die Umgebung
in der Secure-Shell von den Möglichkeiten her nicht von einer lokalen;
ist der Server entsprechend ausgestattet, dann hat man dort alles zur
Verfügung was man auch sonst hat (Editor, E-Mailprogramm, Newsreader,
etc). Einen Nachteil hat man über langsame Leitungen: Dadurch, dass
jeder Tastenschlag erst zum Server geschickt werden muss, und dieser
jede Antwort darauf auch erst durch die Leitungen jagt, bis man sie
sehen kann, können unangenehme Verzögerungen entstehen.

Weitere Alternativen und Abhilfen: In vielen Fällen ist es aber gar
nicht nötig, online zu arbeiten (weder über das Web noch über SSH). Auf
dem eigenen Rechner kann man Mail, News, etc. lokal konfigurieren.
Webforen können komplett mit Mailinglisten oder Erweiterungen wie Gmane
erschlagen werden. Dies erlaubt es den Teilnehmern, offline zu arbeiten.
Wikis können durch richtige Versionsmanagementsysteme (zB. Subversion
oder Monotone) ersetzt werden. Diese erlauben das Arbeiten offline und
in der gewohnte, lokalen Umgebung. Auch Formulare lassen sich offline
realisieren (Proof of Concept: send-pr von NetBSD).



(4) Mauszwang

Grafische Benutzeroberflächen (kurz: GUI) weisen oft wichtige
Bedienelemente auf, die *nur* über die Maus zu erreichen sind. So zum
Beispiel Knöpfe und Eingabefelder in Webseiten[3], oder der Rahmen eines
Fensters. Manchmal gibt es auch Funktionen, die *nur* über Menüs zu
erreichen sind (welche wiederum *nur* per Maus erreichbar sind).

Warum ist Mausbenutzung überhaupt von Nachteil?

- Man kommt selten *nur* mit der Maus aus. Die Tastatur wird immer mal
wieder gebraucht. So landet man bei einem ständigen Wechsel zwischen
Maus und Tastatur. Dieser verläuft oft im Takt von wenigen Sekunden.

- Mausbedienung *ansich* tendiert dazu, ineffizient zu sein. Denn man
muss zunächst das Ziel mit den Augen suchen, dann hat man einen
Ausrichtvorgang (der bei zarten Bedienelementen sehr umständlich sein
kann, siehe auch (6)), und schließlich erfolgt der Klick.

Vergleich mit der Unix-Konsole: Entfällt, da es dort gar keine Maus
gibt.



(5) Schlechte oder schlecht dokumentierte Tastaturbedienung

Dies ist eine Art indirekter Mauszwang.

Die Tastaturbedienung bei vielen Anwendungsprogrammen mit GUI wirkt
wenig durchdacht und mehr als eine Art Alibi. Die Entwickler scheinen
davon auszugehen, dass sowieso jeder lieber die Maus nimmt wo es nur
geht. Und so kommt es dann natürlich auch. Denn die Tastenkürzel sind
oft schlecht zu merken, umständlich auszulösen (man muss meistens
mindestens zwei Tasten gleichzeitig drücken), und nicht oder nur
lückenhaft dokumentiert, oder die Dokumentation ist irgendwo im System
vergraben. Ein Teufelskreis liegt hier vor: Benutzer nehmen die Maus,
weil die Tastatur keine Konkurrenz dazu darstellt, daraufhin wird
konstatiert, dass Mausbedienung dem Anwender besser gefällt, also wird
noch mehr Aufmerksamkeit vom Design guter Tastatursteuerungen abgezogen,
usw.


Vergleich mit der Unix-Konsole: Da man auf der Unix-Konsole nur mit
Tastatur arbeitet, wurde hier von Anfang an viel Wert auf gute
Tastenkürzel gelegt. Es gibt im wesentlichen zwei alternative Systeme:
Das eine an den Editor Emacs und das andere an den Editor Vi angelehnt.
So kann man in der Shell und im Editor im wesentlichen dieselben Kürzel
haben. Da man unter Unix im meistens im Editor oder in der Shell
arbeitet, ist damit das meiste bereits abgedeckt. Anwendungsprogramme
die eigene, besondere Kürzel mitbringen (zB. E-Mailprogramme,
Newsreader, etc.) halten in der Regel die wichtigsten davon dem Benutzer
schon direkt nach dem Start vor. Eine Übersicht ist meistens über '?'
oder 'h' zu erhalten. Für einige Anwendungsprogramme (zB. für Emacs und
Vim) gibt es Referenzkarten zum Ausdrucken.



(6) Schwierige Mausbedienung durch zu kleine Bedienelemente

Wie in (4) und (5) beschrieben zwingen viele GUIs direkt oder indirekt
zur Mausbenutzung, was unter anderem die auch unter (4) beschriebenen
Nachteile hat. Hinzu kommt nun noch, dass viele mit der Maus zu
bedienende Elemente der Oberfläche sehr klein sind, so dass es zu einem
Geschicklichkeitsspiel wird, den Mauszeiger darüber zu positionieren und
zu klicken, ohne dass er wieder verrutscht. Prominente Beispiele dafür
sind Fensterrahmen (auf welche man klicken muss, um das Fenster zu
vergrößern oder zu verkleinern) und die Knöpfe in der Titelleiste der
Fenster.

Besonders brisant wird das, wenn als analoges Zeigegerät nur ein
Touchpad o.ä.  zur Verfügung steht, wie es ja doch unterwegs mit einem
Notebook desöfteren der Fall ist. Auch Menschen mit nicht perfekter
Feinmotorik (zB. älteren Menschen) machen diese zu kleinen
Bedienelemente besonders zu schaffen.


Vergleich mit der Unix-Konsole: Entfällt. (Tasten auf der Tastatur sind
in der Regel sehr gut zu treffen mit den Fingern.)



(7) Wo ist der Tastatur-Fokus?

Gelegentlich treten Situationen auf, bei denen nicht ohne Weiteres klar
ist, "wohin" der nächste Tastendruck gehen wird und was dieser
auslösen
wird. Dies ist etwa dann der Fall, wenn in einem Dialog der Fokus nur
über einen hauchdünnen Rahmen um das fokussierte Element herum
angedeutet wird. Sowas findet sich bei vielen Datei-Auswahl-Dialogen
(was dann dazu führt, dass extra noch einmal auf das gewünschte Element
geklickt wird, obwohl es eigentlich den Fokus schon hatte).

Ein weiteres Beispiel ist das Umbenennen von Dateien unter Windows. Man
klickt auf den Dateinamen, dieser wird komplett markiert und daneben
wird ein hauchdünner Cursor angezeigt.  Dieser Cursor wird von vielen
unerfahrenen Benutzern gar nicht wahrgenommen.  Ebensowenig ist ihnen
klar, dass ihr nächster Tastenschlag aufgrund der Markierung den
bisherigen Dateinamen komplett löschen wird. Um dies zu verhindern,
müsste man zuerst zB. eine Pfeiltaste drücken, woraufhin die Markierung
verschwinden würde.


Vergleich mit der Unix-Konsole: Üblicherweise hat man dort einen
deutlich sichtbaren Cursor. Gibt es keinen Cursor, so werden einem meist
die wichtigsten verfügbaren Tastenkürzel angezeigt. Es könnte noch mehr
geben, doch wenn man die nicht kennt, drückt man eben keine anderen
Tasten als die angegebenen.

Einige Programme, zB. der Vim, zeigen von sich aus keine Hilfe an. Eine
ausgedruckte Referenzkarte kann dann die Rolle dieser Hilfestellung
übernehmen.  Einige Leute werden argumentieren, beim Vim wisse man oft
nicht genau, in welchem Modus man sich befinde. Darauf gibt es eine sehr
einfache Antwort: Drückt man Escape und es macht Piep!, dann ist man im
Kommandomodus. Drückt man Escape und es gibt keinen Signalton, dann war
man in einem anderen Modus, ist aber nun wieder im Kommandomodus.


(8) Arbeitsfluss

Die üblichen GUIs (Windows, Gnome, KDE, etc.) bieten erstmal nur "ganz
viele Fenster". Der typische Desktop sieht nach einiger Zeit der Arbeit
immer gleich aus (bei jedem Benutzer): Ein Haufen sich überlappender
Fenster, von denen zur Zeit immer nur eines verwendet werden kann.
Werden bestimmte Fenster benötigt, müssen diese meist umständlich
herausgesucht werden.


Vergleich mit der Unix-Konsole: Eine Shell wie zB. die Korn-Shell bringt
bereits Möglichkeiten mit, mit mehreren Prozessen zu jonglieren ("Job
Control"). Es gibt auch das Zusatzprogramme (GNU Screen zB.), die noch
mehr Funktionen anbieten. Es gibt dabei einige Vorteile gegenüber den
üblichen GUIs: Diese Systeme sind sehr effizient per Tastatur bedienbar,
und man kann sich mit wenigen Tastenschlägen eine Übersicht über alle
laufenden Prozesse anzeigen lassen und dann daraus einen bestimmten in
den Vordergrund holen. Bestimmte Windowmanager für das X-Window-System
(Ion und Ratpoison zB.) bringen ähnliche Vorteile mit.

Ein gutes Management des Arbeitsflusses bleibt jedoch auch dort dem
Benutzer überlassen.




Fußnoten:
========
[1] Rückfragen vor dem Schließen können dies verhindern, sind allerdings
nicht immer vorgesehen (zB. gibt es bei Mozilla keine Rückfrage).

[2] Man müsste schon zu besonderen Tricks greifen, um diese Daten
wiederzubekommen. Es gibt unter vielen Betriebsystemen
Undelete-Funktionen, oder man kann die Festplatte auf niedriger Ebene
versuchen auszulesen. Das ist viel Arbeit und führt nicht mit Sicherheit
zu einer vollständigen Wiederherstellung. Etliche Unternehmen verdienen
ihr Geld damit, solche Aufgaben für ihre Kunden zu übernehmen.

[3] Durch wiederholtes Drücken der Tab-Taste wären auch diese (meist)
per Tastatur erreichbar, was aber indiskutabel ineffizient sein kann.
Außerdem ist der Rahmen, der den derzeitigen Fokus angibt, meist derart
hauchdünn gezeichnet, dass man ihn nur schwer überhaupt ausmachen oder
verfolgen kann. Siehe auch (7).


---- snip ----

Antworten