Da eben dieser Startvorgang recht lange dauert, lasse ich mich gern von meinem Telefon oder anderen Sachen ablenken. Ein Teufelskreis. Daher brauche ich nicht selten zwei, drei Anläufe, um in die deutsche Variante des Spiels zu gelangen.

Menüs sollten nie selbst entscheiden, nur weil der Nutzer sich etwas Zeit lässt. Und wenn kann etwas Logik in der Entscheidung helfen: Es lässt sich oft gut vorhersehen, was der Nutzer möchte. Bei der Spracheinstellung ist das besonders einfach: Die zuletzt gewählte Sprache hat man auch eine Woche später nur selten verlernt.

Das Dokument ist nicht nur für Smartphone-Entwickler interessant, sondern gibt generell interessante Einblicke in typische Usability-Probleme und wie man diese ggf. elegant lösen kann.

Die Themen sind dabei zahlreich, im Kern meist auf effiziente Platzausnutzung, bessere Verständlichkeit und einfachere Bedienung fokussiert. Wo soll man die Ladeanzeige platzieren? Wie eine Bestätigungsschaltfläche bezeichnen? Wie kann man Icons aussagekräftiger gestalten? All das analysiert Samsung im vorliegenden Dokument recht detailliert:

Relative Evaluation Report on S1, iPhone (2.3.2010)

Passwortabfrage ausschalten

In den Systemeinstellungen wählt man unter der Kategorie Hardware Energieverwaltung. In der linken Leiste wählt man dann Erweiterte Einstellungen, so dass die Schaltfläche Bildschirm nach dem Ruhezustand sperren erscheint. Hier den Haken entfernen und alles ist einfacher.

Usability: Hardware, Energie, Passwort, was?

Wie die Einstellung dahin gekommen ist, kann man sich als Informatiker ja noch fast herleiten. Wie ein normaler Nutzer eine Passwortabfrage hinter Begriffen wie Hardware und Energie finden soll, ist mir jedoch schleierhaft. Da sind Tastenkürzelunterstreichungen in der Menüzeile wohl noch das kleinste Problem des KDE-Desktops…

Windows 8 – erschreckend

In Windows 8 verläuft er sich in den traditionellen Desktop, findet das wegrationalisierte Startmenü nicht mehr und kommt deswegen nicht mehr weg – sein Urteil, dass das ja wohl noch nicht fertig sei, kann man da nur mithoffen.

Unity und die Sache mit dem Ausblenden und Verstecken…

Mit Ubuntus Unity scheint es einigermaßen zu klappen. Hier verwirren ihn vor allem die Workspaces. Ein Konzept, dass dem normalen Nutzer einfach gar nicht bekannt ist. Dementsprechend verläuft er sich darin.

Was ich daraus mitnehme: Popup, Overlays und ausgeblendete Elemente in jeder Form sind potentiell gefährlich. Viele Nutzer verstehen nicht, dass eine Seitenliste aufklappt wenn man die Maus an den Bildrand bewegt oder erschrecken sich sogar und haben Angst, etwas kaputt zu machen. Zudem muss man wissen, dass eine Funktion irgendwo ist. Das ist bei neuen Nutzern nicht der Fall.

Canonical will die ausgeblendeten Global Menus ja dadurch hervorheben, dass sie zunächst kurz angezeigt und dann erst ausgeblendet werden. Ich halte das für unnütz, ja sogar kontraproduktiv. Die Wahrscheinlichkeit, dass ein neuer Nutzer gerade in der kurzen Zeit genau auf den kleinen Teil des Bildschirms guckt, ist äußerst gering. Wenn er aber bemerkt, dass sich ohne sein zutun an einer anderen Ecke etwas ändert, so verunsichert das nur. Es ist schon lustig: In einem oder zwei Releases hat man in Unity alles minifiziert und versteckt. Ich bin mal gespannt wie lange es dauern wird, bis man das alles so hin bekommt, dass es der normale Nutzer auch versteht.

Die Videos

Valentin hat die drei Videos in einem Picomol-Artikel zusammengefasst: Video: Mein erster Kontakt mit Windows 8/Mac OSX/Ubuntu. Hat man was mit Oberflächenentwicklung zu tun, sollte man sich die Zeit nehmen.

Analysis-Synthesis-Bridge-Model

Das Brückenmodell beschreibt das Vorgehen während der Anforderungsanalyse, insbesondere der Recherche und des Prototypings. Es ist im wesentlichen eine Vierfeldertafel:

Die Tafel beschreibt die Schritte, die es zu beachten gilt.

1. Man benötigt detaillierte Kenntnisse über die aktuelle Situation, in welcher die Software eingesetzt werden soll. Um Probleme zu beheben, ist es absolut notwendig, diese zunächst genau zu verstehen.
2. Die Situation muss modelliert werden. Es entsteht ein deskriptives Modell, welches die Realität auf das wesentliche reduziert. Dies heißt auch, dass zu behebende Probleme mit modelliert werden und deren Behebung im Modell möglich ist.
3. Aufgrund dieses Modells gilt es Lösungen zu finden und diese in das Modell zu integrieren. Um sicherzugehen, dass ein Ansatz auch wirklich funktioniert, ist hier ein Prototyp ein geeigneter Ansatz.
4. Die gefundenen Lösungen müssen auf ihre Realitätsnähe geprüft werden. Dies beinhaltet selbstverständlich, dass die modellierte Lösung auch wirklich funktioniert. Aber auch andere Aspekte sind wichtig: Wird der Nutzer die Software auch wirklich so nutzen, dass das Problem gelöst wird? Wird dies in angemessener Zeit möglich sein? Sind hierfür ausführliche Schulungen notwendig? Neben der Effektivität der Lösung ist somit auch immer ihre Effizienz in Bezug auf ihre Benutzbarkeit zu beachten.

Unser Vorgehen bei Tweedback

Die ersten drei Schritte macht jeder Software-Entwickler intuitiv richtig. Das Problem ist vor allem der vierte. Auch wir sind bei Tweedback sauber der Vorgabe gefolgt: Wir haben das Problem analysiert, modelliert und eine Lösung auf dem Modell erarbeitet.

Wir haben uns bewusst gemacht, welche Probleme es in Vorlesungen gibt und detailliert beschrieben, welche Fragestellungen bei Studenten aufkommen. Anschließend haben wir die Dozenten betrachtet und uns mit dem Problem auseinandergesetzt, dass diese sich nicht auf Feedback-Bildschirme konzentrieren können, sondern Auf-einen-Blick-Übersichten benötigen.

Das Problem mit dem vierten Schritt

Das Ergebnis war eine detaillierte Vorstellung von Nachrichten, die zwischen Studenten und Dozenten ausgetauscht werden müssen. Diese gilt es nun ein- und auszugeben. Folglich versucht man möglichst knappe und intuitive Darstellungsmöglichkeiten und Eingabemasken zu entwickeln.

Was an sich nicht verwerflich klingt ist aber schnell falsch gemacht: Man baut auf sein eigenes Wissen um Programm- und Nachrichtenstruktur. Man kennt die einzelnen Funktionen des Programmes und bildet diese auf knapp bemessene Formulare ab. Für die Direktevaluierung fragt man sich vor allem eines: Würde ich Funktion x auf der Programmoberfläche finden? Diese Frage unterstellt aber, dass der Nutzer um Funktion x weiß. Dies ist aber vor allem am Anfang keineswegs der Fall.

Nicht „Wie mache ich was?“, sondern „Was kann ich machen?“

Und hier ist vor allem der vierte Schritt wichtig: Man muss sich bewusst werden, wer in welcher Situation mit der Oberfläche arbeiten muss. Es geht darum zu erkennen, was ein Nutzer von einem Programm erwartet. Da er keinerlei Vorwissen über interne Abläufe und Funktionen mitbringt, sucht der Nutzer auf der Oberfläche nach Möglichkeiten, seine Erwartungen umzusetzen. Dabei gilt es ihn an die Hand zu nehmen und Möglichkeiten aufzuzeigen.

Wir wussten um unsere Konzepte: Wir haben die Formulare zur Teilnahme an einer Veranstaltung und Erzeugung neuer Veranstaltungen nebeneinander gestellt. Wir wussten, wann welches zu nutzen ist. Die Frage, ob jeder Nutzer überhaupt den Unterschied versteht, stellt man sich hingegen nicht mehr. Auch unsere nächste Darstellung war für uns klar: Man kann bereits dargestellte Rückmeldungen anderer unterstützen. Folglich sucht man diese Möglichkeit in der darstellenden Feedback-Wolke. Weiß ein Nutzer allerdings nichts von dieser Möglichkeit, wird ihm diese auch verborgen bleiben.

Erwischt man sich bei solchen Problemen, redet man sich schnell damit raus, dass es sich nur um einen Prototypen handele. Aber das verschärft das Problem: Man gewöhnt sich an ein Konzept und hält es für selbstverständlich. Bei der Implementierung möchte man schnell und effizient arbeiten, man möchte fertig werden. Daher ist es aber gerade so wichtig, dass eine effiziente Darstellung des Programms und seiner Funktionen möglichst früh zu durchdenken und zu implementieren. Es sind vor allem Details, die bei der Fertigstellung gerne mal vergessen werden.