→

→

→

Trotzdem habe ich mir gestern die durchaus abendfüllende Präsentation von Jensen Harris auf der MIX in Las Vegas angesehen: The Story Of The Ribbon (nett: auch als iPod-MP4). Jensen Harris ist Group Program Manager of the Microsoft Office User Experience Team, ok., und stellt rund 1.5 Stunden die neuen Errungeschaften des Office-2007-UI vor, allerdings nicht ohne mit den UIs von Office 97 bis 2003 ordentlich abzurechnen. Dabei verrät er tatsächlich einige Dinge, die man auch im täglichen Hausgebrauch einer Website-UI brauchen kann (Überraschung!). Sowieso ein sehr interessanter Vortrag und damit das einzige Microsoft_produkt neben, der einfachen Microsoft-Maus, das ich zum Konsum empfehlen kann…

Aus gegebenen Anlass wiederholen wir aber jetzt nochmal:

http://www.youtube.com/watch?v=KMU0tzLwhbE

Je nach Aufgabe und Formular scheint es verschiedene passende Lösungen zu geben. Das label über das Formularfeld zu schreiben, hilft dem Benutzer am besten beim Ausfüllen des Formulars, benötigt aber viel vertikalen Raum, ist also bei langen Formularen eher anstrengend. Links ausgerichtete, links stehende label scheinen hier die Lösung zu sein, während die links stehenden, aber rechts ausgerichten eher für kurze, oft genutzte Formulare (bspw. Username/Passwort) passend sind.

Auffällig gut gelöst finde ich allerdings in den Beispielen, die Platzierung der Hilfetexte (»first«, »MM/DD/YY«) an Formularteilen mit mehr als einem Feld, kleiner und grau, aber eben direkt am Input-Feld. Das sieht super aus, hat maximalen Hilfseffekt und braucht kein Javascript etc. um aufzupoppen. Allerdings kommt man hier ein wenig durcheiander, was label ist, denn ein Label kann ja immer nur für ein Formularfeld stehen¹. Damit wäre Name hier also eher ein fieldset, vielmehr die legend dazu, dann würde aber bei Email bspw. das label fehlen oder eben genauso aussehen. Andererseits, wenn man das konsequent macht und immer eine Legend-Label-Kombination findet…

Hier ein kurz zusammengestricktes Beispiel, erst das HTML:

[syntax,formular_hilfen.html,html]

Und dann das CSS (ich schätze, nicht IE-kompatibel):

[syntax,formular_hilfen.css,css]

¹ Gewußt? Wenn man auf das Label klickt, bekommt das zugehörige Formfeld den Fokus. Und: das <label> kann Labeltext und Input-Feld auch umschließen, dann braucht man kein for-Attribut und spart sich die ID am Formularfeld.

→

Dabei kommt es natürlich zu ganz deutlichen Konstruktionsfehlern, denn, das hätte man wissen können, beides passt nicht zu jeder Situation. Ein paar motivierende Farben können dabei ja noch ganz in Ordnung sein, dumm wird’s beim Mißverständnis über dach Nachladen von Content, mit Javascript, AJAX im weitesten Sinne – dazu gehört in minder aufgeklärten Kreisen eben auch das verstecken von Inhalt und Wiederanzeigen auf Mausklick.

Beispiel? Gerne, wenn auch nur theoretisch.

Was man beispielsweise auf gar keinen Fall verstecken sollte, sind Formulare, zumindest nicht die, von denen man möchte, dass sie ausgefüllt werden. Natürlich kann man ein fades Formular mit dem die Benutzer Beschwerden an den Seitenbetreiber schreiben hinter einem winzigen Knopf verstecken, dann muss man nicht soviel Support leisten. Will man jedoch, dass sich Leute für etwas anmelden, dann macht man das Formular besser sichtbar, gut sichtbar. Das hab ich jetzt nicht getestet, aber bitte, mal kurz nachdenken… na also. Man muss eben nicht Herr Nielsen sein, um so etwas herauszufinden, hier hilft der gesunde Menschenverstand.

Ebenso ist irgendetwas falsch, wenn man roundabout 20 Formulare auf einer einzigen Seite antreffen kann. Auch, wenn man 19 davon mit oben genannte Methoden vor dem Auge des Benutzers versteckt.

Und da laufen die Fäden zusammen. Da entwirft jemand eine Seite und merkt relativ schnell, dass etwas nicht stimmen kann, denn da sind ja so viele Formulare daruf, dass sieht ganz doof aus… und die Lösung die einfällt ist: verstecken wir’s halt und schreiben AJAX dran.

Ich sage jetzt mal, das würde dem aufrichtigen Webentwickler nicht passieren, er würde nach eine programmatischen Lösung suchen, die Formulare zu einem zusammenzufassen, beispielsweise. Oder vielleicht muss man das auch inhaltlich auftrennen? Aber der Webdekorateur, der soetwas mit Photoshop zusammenstückelt, der kommt auf genau die Idee mit dem mißverstandenen AJAX. So mitten in der Nacht spart das natürlich auch eine Menge Arbeit. Und man kann das Nachdenken dann den anderen überlassen.

Das ist natürlich nur ein Beispiel.

Durchaus diskutabel, wie ich leider finden muss. Die <abbr /> und deren title-Attribut werden zur Auszeichnung der Datumsangaben genutzt. Das ist zunächst mal eh’ semantisch nicht korrekt und führt wohl auch zu einem doppelten Vorlesen und damit zu allgemeiner Verwirrung. Hier müsste man das abbr-Design-Pattern wohl anzweifeln.

Cool sind nebenbei bemerkt allerdings die semantic markup standards der BBC. Die werde ich jetzt mal direkt kopieren, übersetzen und ein Logo draufknallen… ;) wirklich phat!

99% of readers can stop here; this column is for people who have a great website or intranet.

www.useit.com

Kann mir mal einer erzählen, was drin steht in dem Artikel, ich konnte durfte wollte leider nicht weiterlesen… ;)

Dabei, wenn man etwas gebaut hat, das in diesem Sinne usable ist, dann kann man das auch schonmal merken. Und am besten abspeichern, auch wenn man das woanders sieht. Das mache ich jetzt mal:

Im Hamburger Pressehaus rückt demnächst eine Fensterputzfirma an, die, um ihre Arbeit störungs- und stressfrei verichten zu können, natürlich freie Fensterbänke brauchen. Darauf weisen sie auf jeder Etage mit einem kleinen Plakat hin. Alles normal bis hier. Der Witz ist, wo die Jungs die Plakate angebracht haben: jeweils an die Türen der Toiletten. Das ist, a) eine gute Idee und ein gutes Beispiel für Usability (und natürlich Marketing), b) etwas, worauf im Haus bisher noch niemand gekommen ist.

Man muss auf einer Webseite also soetwas wie die Klotür finden. Und dann sollte man dort keinen Spontispruch anbringen, sondern vielleicht den Loginbutton oder besser noch die Suche…

→

Das ist doch gar nicht so schwer zu bewältigen, möchte man meinen. Stattdessen setzt man aber vielerorts eher auf die Hausfrauentests, Freunde und Bekannte wird eine neue Seite mal kurz gezeigt: »Sag’ mal ‘was dazu!«

Das ist aber nun mal kein echtes Testen. Obwohl man es meist mit der Zielgruppe zu tun hat, handelt es sich doch im Allgemeinen nicht um eine echte Testsituation. Zeitdruck, mangelnder Wille und hernach fehlende Dokumentation des Ganzen, alles Faktoren, die den Ich-frag-mal-meine-Frau-Test von einem echten Testing unterscheiden. Und dann tritt noch der Will-Helfen-Effekt auf: je nach Einleitung und Fragestellung sind die Ergebnisse eines solchen Tests unbrauchbar. Was sagt meine Frau wohl, wenn ich mit folgender Bitte an sie herantrete: »Kannst du dir die Seite hier mal ansehen, ich finde da stimmt irgendetwas nicht«. Genau. Je nach Anzahl solcher Tests, findet man so nur die gnaz offensichtlichen Bugs, die man wahrscheinlich auch selbst nicht übersehen hätte. Und die Ergebnisse sind immer Gegenstand von Diskussionen.

Es geht aber natürlich noch schlimmer: man kann ganz aufs Testen verzichte und einfach annehmen man wisse, wie der User das sieht. Interessanterweise hört man das oft: »der User« – und es klingt immer so ein bisschen nach »der Russe«…