Usability Teil I: Einführung, Dialoge

[lemming]

Usability Teil I: Einführung, Dialoge

Inhalt:
Einführung
Arten von Dialoge
Beispiele
Aussichten Teil II
Quellen


Hallo, ich habe dieses Thema für mein erstes Tutorial gewählt, da ich mich mit dieser Materie eingehend beschäftigt habe. Computeranwender kommen jeden Tag mit Designschnitzern in Kontakt die hätten verhindert werden können. Hier sind die Programmierer gefragt.

Ich möchte in diesem Tutorial nicht die elf Human Interface Design Prinzipien aufzählen und erst recht nicht erklären. Dennoch möchte ich sie als Grundlage nehmen. Meine Quellen gebe ich am Ende dieses Textes bekannt.

Im ersten Teil möchte ich auf Dialoge eingehen. Sie sind eine wichtige Schnittstelle zwischen Mensch und Computer.
Dialoge als solche gibt es viele. Vom „Möchten Sie speichern Dialog“ über „Es ist ein Fehler aufgetreten“, „Farbpallete“, „Suchen“ bis hin zum „Drucken“. Manche bieten mehr Manipulationsmöglichkeiten, manche beschränken sich auf ein „OK“. Sie fordern und geben Informationen an den Anwender.

http://www.hardtware.de/enterprise/u...ty/dialog1.jpg

Was soll man bei einem Dialog mit einer Schaltfläche den falsch machen können? Ganz schön viel. Ein Dialog sollte immer vier Dinge beinhalten

Was ist passiert (präzise ohne Floskeln, ehrlich, am besten fett geschrieben)
„Die Datei pmdox.db wurde noch nicht gespeichert!“

Woran könnte es liegen, was kann man jetzt machen (Abhilfe schaffen)
„Möchten Sie die Datei jetzt speichern?“

Die Buttons zum interagieren
Dieses Thema ist auch sehr speziell, darauf werde ich später noch eingehen
„nicht Speichern“ „Speichern“ „Abbrechen“

Das Icon der Anwendung
Kein Warndreieck, kein rotes X und kein Fragezeichen. Hier gehört das Icon der Anwendung rein. Das gleiche gilt für Den Titel der Dialogbox. Im besten fall steht dort nur der Name der Anwendung. Die Meldung könnte ja sonst von jeder x beliebigen Anwendung kommen.

http://www.hardtware.de/enterprise/u...ty/dialog2.jpg

Ich habe jetzt bei den Buttons andere Beschriftungen gewählt als wie sie Standardmäßig von Windows geliefert werden. An diesem Punkt möchte ich sagen das die Dialog API von Windows furchtbar schlecht – im Bezug auf Usability – ist.
Bei einem Dialog der mich fragt „Möchten Sie jetzt speichern?“ Muss ich zunächst den kompletten Satz durchlesen bevor ich mir ausrechnen kann auf was für eine Schaltfläche ich nun klicken muss. „Ja“, „Nein“, „Abbrechen“. Das nimmt zum Teil fast komische Ausmaße
an. Verben sind viel verständlicher als Adverben.

Dass es auch anders geht hat Microsoft wohl selbst erkannt.

http://www.hardtware.de/enterprise/u...ty/dialog3.jpg
Dieses Fenster erscheint beim öffnen eines Word-Dokuments mit Makros. Da Microsofts Office-Paket ja durch seine Makrofunktionen arg von Viren gebeutelt ist, legten die Entwickler anscheinend sehr viel Wert auf einen einigermaßen verständlichen Dialog.

Leider wurde nicht sehr viel Wert darauf gelegt wie Parkinsonsicher diese Abfrage ist. In meinem Beispiel oben habe ich mit Absicht die zwei Schaltflächen die die gravierendsten Unterschiede in der Aktion aufweisen so weit wie möglich auseinander gesetzt.
Ganz anders in dem Dialog von Microsoft. Hier liegen die Schaltflächen direkt aufeinander und ein versehentliches verklicken kann passieren.

Ich halte einen Mindestabstand zwischen Schaltflächen von mindestens 12 Pixeln für angemessen. Schaltflächen die eine genau gegenteilige Aktion machen, sollten so weit wie möglich auseinander liegen. Die „Abbrechen“ Schaltfläche sollte immer ganz rechts unten stehen, da es bei allen Dialogen in der Windows Welt üblich ist. – Leider. Die „Abbrechen“ Schaltfläche könnte schön als Seperator dienen, aber nein. Erfinden wir das Rad nicht neu. Neue glänzende Felgen reichen ja auch schon.

In Teil II werde ich auf Menus eingehen.

-lemming


Quellen:
http://developer.apple.com/documenta...ogs/index.html

[neolithos]

Ich würde die Weisheit, nur bedingt verwenden.

Bis überhaupt nicht.

Meine Dialoge folgen alle den Windows Standard:

Titel: Frage
Die Datei speichern?

[FileName mit Pfad]

[Yes] [No]


Wenn ich den Dateinamen sehe ist die Frage völlig klar, ich lese sie gar nicht!

Wer neu am Rechner ist liest jede Box sowieso genau durch, der liest auch die Frage, weil sie schön kurz ist.

Zu was bitte schön brauche ich [Nicht Speichern] und [Speicher].

Hier stimmt der Aufwand nutzen nicht!


Tipp: @lemming
Es gibt ein Buch "GUI-Design" von Ivo Wessel, welches ich gelesen habe, aus dem ich diese Weisheit habe (und noch andere).
ganz güstig bei Amazon oder in jeder UNI-Bibo.

so das musste gesagt werden...

[roderich]

Ich finde den Beitrag von Lemming klasse -> bitte mehr davon !

Schon oft habe ich mich geärgert über Dialogboxen (gerade von MS), wo die eigentlich Frage in der CAPTION des Formulars stand oder sonstwie versteckt war, dann langes Gesülze innerhalb der Box, gefolgt von Buttons mit "Ja", "Nein" und "Abrechen".

Den Vorschlag für das explizite Belegen der Buttontexte und das Platzieren je nach Aktion kann ich nur unterstützen.

Roderich

[Wormid]

Ich finde auch, man sollte sich unbedingt an den Windows Standard halten...

Zitat:

Ich halte einen Mindestabstand zwischen Schaltflächen von mindestens 12 Pixeln für angemessen.

Mit solchen Aussagen kann ich irgendwie nicht sooo viel anfangen. Der Standard ist nunmal 8. Warum jetzt auf einmal 12? Warum nicht die Standard-Icons von Windows für Fehlermeldungen etc?

Ich will jetzt das Tutorial nicht schlecht machen, aber auch ich rate davon ab, Dialoge und Oberflächen nach eigenen Geschmacksvorstellungen zu entwerfen! Wobei ich dem Tenor oben grundsätzlich zustimme: Meldungen, Captions, Buttontexte, Icons und all der andere Krimskram müssen (sollten) auch bei Nutzung der Standarddialoge sinnvoll, aussagefähig und vor allem korrekt sein.


Warum ich das so sehe:

Ich war bereits live bei einem Projekt dabei, bei dem die Projektleitung konsequent auf eigene Dialoge, eigene Hilfesysteme etc. Wert gelegt hat. Die meisten Entwickler (auch ich) haben von Anfang an gemeckert, das das nur schief gehen könne... Und richtig genug: Die Anwender kamen mit den Dialogen und Hilfen nicht klar, fühlten sich mit der Software nicht wohl. Sie haben uns das Produkt um die Ohren gehauen, und wir hatten monatelang alle Hände voll damit zu tun, das Programm nachträglich optisch und bedientechnisch zumindestens nährungsweise an Windows-Standard ranzubringen....


Gruß

Wormid

[GuenterS]

@lemming

Kann es sein, dass du genau das gleiche schon mal im Delfi-Forum veröffentlich hast? - Nicht, dass das nicht erlaubt wäre, würd mich nur intressieren. Auch dort hats ja starken Gegenwind gegeben.

Ich für meine Meinung empfinde es als eher störend, wenn sich einige wenige Programme nicht an einen erprobten Standard halten. Die fallen dann dadurch schon mal negativ auf, weil sie irgendwie eher auf eine schnell hingepfuschte Lösung, als eine sorgfältig entworfene hindeuten. Ist aber eine subjektive Empfindung.

Was nicht heißt, dass ich mir kryptische Dialogboxen wünsche, da hats leider auch schon einiges an Beispielen gegeben. Aber nicht ohne Grund, gibt es verschiedene, standardisierte Symbole für Messageboxen. Würde man da nur das Symbol der Anwendung verwenden, würde gleich einmal ein Teil der Information wegfallen, denn um welches Programm es sich handelt sieht man eigentlich entweder daran, dass es sich direkt darunter befindet oder aber es blinkt schön in der Taskleiste.

[thomasw]

Hier noch zwei sehr lesenswerte Links der Apple-Konkurrenz:
http://msdn.microsoft.com/library/de...idesigndev.asp
http://msdn.microsoft.com/library/de...ml/welcome.asp