Tabelle sortieren – (k)eine leichte Aufgabe

Unzählige Stunden habe ich wohl schon mit dem UI-Pattern umsortierbarer Tabellen verbracht. Nicht nur im Verschieben einzelner Pixel – sondern auch in gemeinsamen Spekulationen über “was funktioniert und was nicht”…

Schluss mit Hypothesen, dachte ich mir.

Nun also wie versprochen – mit einem Tag Verspätung – die Auswertung meiner bescheidenen Chalkmark-Studie:

Hier die beiden Testkandidaten im Vergleich:
A:

3073-table-smi-arrowsort-thumb-225x128-3072.png

B:

3076-table-smi-cleansort-thumb-225x128-3075.png

A – Jede sortierbare Spalte hat Pfeile für auf- und absteigende Sortierung. Die aktuelle Sortierung wird mit schwarzem Pfeil angezeigt.

B – Nur die aktuell sortierte Spalte ist hervorgehoben und besitzt nur den Pfeil der Richtung der Sortierung.

Die Testaufgaben waren explizit formuliert. Beispielsweise: “Du möchtest die SMI Tabelle nach Name sortiert haben.” So kann man ausschliessen, dass es sich um ein Problem im Verständnis der Frage handelt.

Das Management Summary vorneweg: Spürbare Vorteile für Variante B durch grosse Fehlertoleranz und leichteres Klicken durch grössere Klickfläche (Fitt’s Law).

Ich muss jedoch zugeben, dass beide Lösungen funktionieren können. Denn ganz durchfallen tut auch A nicht. Jetzt aber zu ausgewählten Details…

Problem: Verwirrung durch die unnötige Anzahl an Pfeilen

3079-heatmap-arrow_problem-thumb-500x256-3078.png

In beiden Testfällen gibt es – vermutlich unachtsame – Klicks auf die Pfeile der ersten Spalte, obwohl jeweils die Sortierung der anderen Spalte gefragt war.

Zum Vergleich das positive Resultat der übersichtlicheren Variante B. Die eine Testperson beim Sortieren der SMI Werte hat wohl zuweit gedacht: Die umgekehrte Reihenfolge von der Tiefst-Spalte ist nicht nach Höchstwerte sortiert ;-)

3082-heatmap-noarrow_positive-thumb-500x243-3081.png

Zwang zum Pfeil-Klick

Interessantes Detail der exakten Klick-Positionen bestätigt eine Ahnung: 65% der Personen fühlen sich gezwungen exakt den jeweiligen Auf- oder Ab-Pfeil mit der Maus zu treffen. Das ist eine Klickfläche von ca. 11×8 Pixel!
Fatal wäre es, wenn tatsächlich nur die Klickfläche der Pfeile verlinkt wäre! Denn dann wären 25% der Klicks auf die Bezeichung im Spaltentitel wirklungslos.

Hingegen als sehr fehlertolerant erweist sich die Auszeichnung von Spaltentitel als Link. 85% treffen eine gültigen Bereich. Woher die deutlich ungenauen beiden Klicks oberhalb kommen kann ich mir jetzt so nicht erklären.

In der Summe heisst das für den Task-Erfolg – je nach Umsetzung – eine Patt-Situation (A: 90% zu B: 85%) oder ein deutlicher Vorteil für B, falls nur die Pfeile verlinkt sind.

3085-sortierpfeile-zwangzumklick-thumb-250x137-3084.png
3087-sortieren_link-fehlertoleranz-thumb-250x160-3086.png

Fitt’s Law

Je grösser die wahrgenommene Zielfläche für die Maus ist, desto schneller bewegt man die Maus darauf zu und kann natürlich auch leichter treffen. Die zu erwartende Verzögerung bei Verkleinerung ist nicht linear, sondern logarithmisch. Hier also der Heatmap Vergleich der geklickten Flächen, welcher zeigt dass der spontan geklickte Bereich durch weglassen der Pfeile weniger konzentriert ist.

3088-sort-fitts-law.png

Für diese Beurteilung ist auch nicht relevant, ob nun in Variante A 100% der Treffer auf dem kleineren Fleck vereint sind.

Abschliessend noch zwei Kommentare und die Auswertung der Präferenzen.

Zu Variante A:

Grösse der klickbaren Fläche beachten!

Zu Variante B:

Die grafische Darstellung der Sortierpfeile ist bei den auf- und absteigenden einleuchtender als bei der Version 2. Da aber die nächste Aktion bei einer Spaltensortierung klar ist, finde ich die mit den klickbaren Texten ausreichend und nicht so’n Gefummel. Nur die Pfeildarstellung sollte anders gemacht werden.

Die sechzehn Testpersonen haben sich nach Abschluss aller Tasks mit einer geringen Mehrheit für Variante B entschieden. Variante A bevorzugen 7 und Variante B bevorzugen 9 Testpersonen.

Natürlich möchte ich meine Entscheidung nicht aufgrund der quantitativen Betrachtung treffen – denn 7 zu 9 ist unentschieden.
Den Ausschlag für meine Wahl von Variante B sehe ich im grafisch überlegenen Resultat und der bestechend einfachen Umsetzung. Keine Pfeile bedeutet weniger “Noise” und gleichzeitig wird bei vielen Spaltentitel für die Pfeile kein zusätzlicher Platz benötigt. Was das im ungünstigsten Fall zur Folge hat zeigt die

Vorlage der Tabellensortierung

.

3 Gedanken zu “Tabelle sortieren – (k)eine leichte Aufgabe

  1. Wie ist denn die Erwartungshaltung der Benutzer bei Variante B bzgl. der Sortierreihenfolge A>Z oder Z>A?

    Oder anders ausgedrückt: Was erwarten die Besucher für eine Sortierung, wenn sie auf eine noch unsortierte Spalte klicken?

  2. Zu der Erwartung der Sortierreihenfolge gibt es keine Aussage/Kommentare der Testpersonen – und daher erscheinen die häufig verwendeten Worte “it depends” angebracht.

    Mein persönlicher Wunsch wäre, dass die Reihenfolge je nach Spalte automatisch “richtig” wäre.

    Als Standard würde ich folgendes vorschlagen:
    * Textspalten nach A>Z
    * Zahlen nach Max>Min
    * Zeitangaben nach Min>Max
    * Bilder nach Vorhanden>NichtVorhanden

    Ich nehme mal das Beispiel der SMI Werte:
    Name: A>Z
    Aktuell: Max>Min
    +/-: Max>Min (das bedeutet Max+>Max-)
    Vortag: Max>Min
    Hoch: Max>Min
    Tiefst: Max>Min
    Zeit: Min>Max (!)
    Trend: Max>Min

  3. An solchen Details interessierte Leser sollten unbedingt den Follow-Up von Tobias auf uxzentrisch lesen:
    http://uxzentrisch.de/sortierbare-tabellen

    Mein Kommentar muss ich vorerst hier erfassen

    @Maikel
    Die Möglichkeit der Kontrolle der Sortierung ist im “Original” umgesetzt: http://boerse.raiffeisen.ch/raiffeisen2/listings/stockPrices.jsp
    Was Du lapidar als “genau zielen müssen” beschreibst hat zur Folge, dass man zum Klicken/Treffen die Mausgeschwindigkeit massiv verlangsamt, damit man die Fläche trifft. Dieses Prinzip habe ich in meinem Artikel nur als Referenz zum wissenschaftlichen Bezeichnung (Fitt’s Law) erwähnt und diese Gleichung beinhaltet eine Logarithmus-Funktion. Demzufolge also keine lineare Verlangsamung!

    Alleine die Darstellung der Pfeile hat dazu geführt, dass die Testpersonen tatsächlich vermehrt auf die Pfeilbereiche geklickt haben. Das bestätigen auch meine Beobachtungen im Testlabor.

    Zudem bin ich erschrocken, wie falsch die Pfeile zur Sortierung von Testpersonen interpretiert werden! Auch wenn ich keine genauen Zahlen habe – ein entscheidender Teil der Testpersonen denkt bei einem nach unten zeigenden Pfeil ▼ an eine Richtungsangabe – also Klein-zu-Gross – , während andere den Pfeil als grafische Darstellung von Gross-zu-Klein interpretieren. Einfach mal selbst im Finder/Windows Explorer überprüfen: Es ist im Betriebssystem das Letztere.

    @Tobias
    Der Grund für meinen Vorschlag liegt ist der effizienten Nutzung des verfügbaren Platzes. Du hast in Deiner Skizze den Pfeil neben den Titel “Tiefst” gesetzt. Da hat er wunderbar Platz. Leider sieht das in der “+/-%” Spalte anders aus und man muss die Spaltenbreiten der Tabelle je nach sortierter Spalte ändern. Das wollte ich vermeiden.

    Nebenbei: Die Darstellung ist nicht meine Idee – das Interface Element habe auch aus Windows Vista geguttet:
    http://quince.infragistics.com/Patterns/Sortable%20Table.aspx

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>