flying sparks ein Weblog von Tobias Jordans zu den Themen software designstudium web2.0 webdesign informationsdesign oekologie werbung usability tj video interfacedesign marketing // alle Themen...

Alle Funken für das Thema formular:

Buttongestaltung in Webformularen im Usability-Test

Primary & Secondary Actions in Web Forms

Das hat mich schon immer interessiert! Die als letzte dargestellte Variante wäre mein Favorit gewesen. Meiner Meinung nach sollte die Primäraktion stark von der Sekundäraktion getrennt werden. Und eigentlich sollte damit die letzte Variante diejenige sein, die am Besten abschneidet. Ganz so einfach ist die Welt aber nicht.

Kurz zusammengefasst:

  • Die erste Variante (und damit die konventionellste) schneidet am Besten ab, wenn es um Schnelligkeit geht.
  • Die letzte Variante ist nur dann zu favorisieren, wenn es nicht um Schnelligkeit geht, sondern darum, die Wahl zu vereinfachen und deutlicher zu machen.

Alle Ergebnisse im Detail inklusive Eyetracking und weitere Varianten gibt es im Artikel Primary & Secondary Actions in Web Forms von LukeW.

Diesen Artikel hat Niels in unserem internen Blog gepostet und da er den Kern trifft und ich ihn nur hätte nachtexten können, zitiere ich lieber gleich ganz.

Ich war wirklich erstaunt über dieses Ergebnis von LukeW, das auch seinen älteren Aussagen zu diesem Thema, über die ich nur am Rande bloggte, in gewissen Anwendungsfällen widerspricht.

Die einzige Erklärung, die ich für dieses Ergebnis habe, ist, dass die Ausbildung von Gewohnheiten (hier: „bei zwei Button unter einem Formular ist der linke der ‚Gute'") einfach viel zu stark ist. Neue Methoden funktionieren zwar und mögen sogar Vorteile haben, noch sind sie aber nicht allgemein empfehlenswerter als die gewohnten alten.

PS: Eine Frage am Rande: Ich habe für dieses Posting ein Zitat von Jacob Nielsen gesucht von dem ich sich war, dass er es einmal geschrieben hat. Sinngemäß sagt es, dass ein neues Interface nur Sinn macht, wenn es 100% besser funktioniert als das alte. Leider konnte ich nichts dergleichen bei useit.com finden — irre ich mich?

Delicious: Things we’ve learned

Vorab: Dieses Posting habe ich schon im März in einem internen Blog geschrieben und füge es jetzt der Vollständigkeit und einfachen Verlinkung wegen zu den flyingsparks hinzu.

Auf der gleichen Konferenz spricht Joshua Schachter, Gründer von Delicious über Dinge, die er bei der Erstellung seines bekannten Social-Bookmarking-Dienste gelernt hat (MP3).

Auch hier findet sich wieder eine Zusammenfassung des 40-Minuten Vortrags im Netz.

Und auch hier geht es unter anderem wieder um das Thema URL-Design.

Die Punkte die Schachter ab Minute 16 anspricht:

Interessant auch unter dem Gesichtspunkt der Bedeutung von RSS: Delicious hat mehr RSS-Traffic als HTML-Anfragen. Entsprechend gutes Caching ist nötig.

Auch in diesem Vortrag wird im Übrigen die Bedeutung offener APIs angesprochen:

Meine Stichworte dazu:

Die ursprüngliche URL http://www.webuser.co.uk/carsonworkshops/JoshuaSchachter.mp3 ist leider nicht mehr verfügbar. Ich habe mein Backup bei mir bereit gestellt.

Date-/Time-Picker

Wie sähe ein optimales Datums- oder Zeit-Eingabefeld aus?

Update 06-05-31: Eine Lösung könnte eine Datums-Autocomplete-Funktion sein…

Ich glaube Jacob Nielsen ist es, der schreibt, dass es das Formular ist, das die Validierung der Daten vornehmen muss, nicht der Benutzer.

Das erfordert natürlich mehr Arbeit auf der Serverseite, hebt aber das Benutzerempfinden erheblich. Gerade aufgrund dieser Mehrarbeit kann ich gut nachvollziehen, dass viele Websites auf Lösungen zurückgreifen, die für den Benutzer unbeqeuemer, für den Entwickler aber bequemer sind.
Anders ist das jedoch bei Formular-Generatoren wie sie Ruby On Rails beispielsweise mitbringt … oder aber die beiden Websites in diesem Post. Hier würde es sich lohnen einmal genau zu überlegen, wie man die Formulareingabe so einfach wie möglich machen kann.

Dabei läuft es in erster Linie auf zwei Dinge hinaus:

1. den Wechsel zwischen Tastatur und Maus minimieren — Raskin (The Human Interface) beschreibt in seinem Kapitel „Quantitative Analyse von Interfaces" anschaulich einen Ansatz, bei dem alle Mehrfeld-Lösungen durchfallen würden. Der Wechsel der Hand von der Tastatur zur Maus kostet in dieser GOMS(-ähnlichen) Analyse die meiste Zeit (und kognitive Arbeit) und ist zudem meist unnötig.

2. Gewohnheiten des Benutzers übernehmen — Lästig und zeitraubend bei der Eingabe ist, sich auf die Art und Weise einzustellen, wie der Entwickler meine Daten gerne geliefert hätte. Ich passe mich an die Software an — spätestens hier wird deutlich, dass das besser gehen muss.

Die Lösung? Sorry, die muss ich auf später verschieben, dafür ist heute keine Zeit.
Aber bei all den Artikel, die es über Formulardesign mit CSS und XHTML gibt, wundert es mich, dass ich noch nichts über wirklich durchdachte Lösungen gelesen habe und wollte zumindest meinen Unmut schon einmal ausdrücken :-).
Zum Abschluss drei Beispiele, deren Lösung ich nicht gut finde:

To be continued…