Auffüllen mit Daten

Wir alle kennen sie: diese Balken, die den Fortschritt eines Vorgangs anzeigen. Meistens handelt es sich um Ladevorgänge, wie bspw. beim Start eines Computers, Aufladen eines Akkus oder der Anzeige eines Download-Vorgangs. Es haben sich seit vielen Jahren vor allem horizontal-orientierte Balken in so gut wie allen Betriebssystemen und Web-Frameworks etabliert.

Die folgende Übersicht aus den Material Design Richtlinien zeigt verschiedene Ausprägungen dieser Ladebalken:

 

Aufladen einer Batterie

Im iPhone wird das Laden des Akkus über einen horizontalen Balken visualisiert:

Die meisten Android-Smartphones folgen hingegen bei der Visualisierung des Ladevorgangs den vertikal-orientierten Säulen:
android-battery

Welches dieser beiden Ansätze ergibt nun mehr Sinn und ist somit passender?

Diese Frage verweist auf das Thema, welches mentale Modell zu diesem Vorgang besser passt.

Dazu folgende Gedanken:

  • Nehmen wir den Begriff „Aufladen“ wörtlich wird ein Gegenstand auf eine Ladefläche gepackt. Wird weiter aufgeladen, so denke ich eher an eine Stapelung als daran, dass etwas daneben gestellt wird. Insofern passt die Visualisierung über vertikale Säulen besser als über horizontale Balken.
  • Wenn ich mir die inneren Vorgänge einer Batterie konkret vorstelle, so stelle ich mir den Ladestand ähnlich wie den Füllstand eine „Gefäßes“ mit einer Flüssigkeit vor. Auch aus dieser Sicht passt eine Säulendarstellung.

Download vs. Upload

Bei Download-Vorgängen stelle ich mir vor, wie die Festplatte als Speicher mit Daten gefüllt wird. Dies würde auch für die Säulendarstellung sprechen.

Im Nintendo eShop wird dies sehr skeuomorph visualisiert, in dem mehrere Beutel mit einer Flüssigkeit an einer Leine hereinfahren und nacheinander in einen Container fallen, darin zerplatzen und ihn so nach und nach mit Flüssigkeit auffüllen:

Beim Upload hingegen stelle ich mir vor, wie die Daten verschickt werden. Und „Verschicken“ hat damit zu tun, dass sich ein Gegenstand von mir weg bewegt, was nach meiner Auffassung eine horizontale Bewegung ist. Hier passt also die horizontale Balkendarstellung.

Abstrahiere ich diese Gedanken, so sind Bewegungen von einem Ort zu einem entfernten Ort horizontale Bewegungen, während Aufladevorgänge vertikale sind.

Ein kleines Design Pattern

Ich möchte mit diesen Gedanken Entwickler von digitalen Benutzeroberflächen dazu anregen, bewusst den passenden Kontext für Vorgangsdarstellungen zu wählen, um dem Nutzer ein Gefühl der Nachvollziehbarkeit des Vorgangs zu vermitteln.

Ich habe zu diesem Thema ein kleines Design Pattern entwickelt, welches einen Download-Vorgang simuliert:

See the Pen Progress fill by Tamio Honma (@IOIO72) on CodePen.light

Der Code ist in Vanilla ES6 geschrieben. Wer den Code für eine reale Anwendung nutzen möchte, kann einfach eine Controller-Funktion dazu schreiben und darin den prozentualen Fortschritt über view.setPercent(percent) anzeigen.

Belohnung per Animation unterstützen

Man braucht kein Psychologiestudium abgeschlossen zu haben, um zu wissen, dass Menschen sich über Belohnungen und Geschenke freuen.

Digitale Services stehen mit dem Nutzer im Dialog und funktionieren i.d.R. besser, wenn sie auf den jeweiligen Nutzer individuell eingehen. Hier stehen dann weniger technische Informationen im Vordergrund sondern vielmehr die Art der Kommunikation,  die Tonalität und Gestaltung im Allgemeinen.

Eine dieser Kommunikationssituationen ist die Belohnung des Nutzers über ein erreichtes Ziel. Im Wort Belohnung steckt schon eine positive Wertung und Beschreibung der System-Nutzer-Situation. Aus technischer Sicht könnte das System einfach eine nüchterne und unscheinbare Information angeben, wie „Registriert“, nachdem der Nutzer eine Formularstrecke erfolgreich abgeschlossen hat. Stattdessen könnte das System diese Information als Belohnung verpacken und dem Nutzer so ein kleines, motivationssteigerndes Erfolgserlebnis bereiten.

Die folgende Meldung könnte bildschirmfüllend am Ende einer Formularstrecke stehen:

See the Pen Reward view by Tamio Honma (@IOIO72) on CodePen.19231

Betreiber von digitalen Diensten, die vor allem auf batteriebetriebenen Geräten genutzt werden, sollten dieser häufig als kritisch erlebte Nutzererfahrung Rechnung tragen und den Energieverbrauch in der Umsetzung ihrer Dienste als wichtigen Optimierungsfaktor betrachten. Stelle man sich vor alle Websites und Apps würden energiefressende Ladevorgänge und rechenintensive Animationen und andere Berechnungen abschalten bzw. reduzieren, wenn der Energiestatus des genutzten Endgeräts kritisch ist, so könnten Nutzer noch länger gewünschte Dienste nutzen bis sie die nächste Steckdose finden. Vor allem Dienste des ÖPNV, des Reiseverkehrs allgemein und der Navigation wären sehr gute Beispiele für die Sinnhaftigkeit einer solchen Optimierung. Wer einen ganzen Tag in einer fremden Großstadt unterwegs ist, wird dies zu schätzen wissen. Hier geht es um die kurze, schnelle, aktuelle und fokussierte Beantwortung einfacher Fragen und nicht um aufgeblähte Zusatzinformationen, welche ggf. unnötige und große Datenmengen benötigen und unnötig Energie aus der Batterie zur Übertragung und Verarbeitung ziehen. Urban Traffic

Ein guter Service hält einige Daten offline vor, synchronisiert nur das nötigste in kompakter Form aus dem Internet und ist auf die eigentlichen Bedürfnisse des Nutzers zugeschnitten.

Wenn das Gerät mit einem schnellen Netzwerk verbunden ist und in einem guten Energiezustand ist – womöglich sogar an der Steckdose angeschlossen -, so kann der digitale Service größere Datenpakete zur späteren Nutzung synchronisieren. In diesem Gerätestatus befindet sich vermutlich auch der Nutzer des Geräts in einer entspannteren Situation und ist bereit sich durch angereicherte Inhalte inspirieren zu lassen bzw. sich weiter vertiefen zu können.

Kennt das Gerät und der digitale Service den Zustand des Geräts, so kann der Service auch gute Annahmen über die Situation des Nutzers treffen. Niedriger Batteriestand, 5 Stunden ohne Steckdose und im UMTS-Mobilfunknetz deutet bspw. darauf hin, dass der Nutzer unterwegs ist und in dieser Situation mehr Wert auf schnelle und zielgerichtete Informationen als auf inspirierende und umfassende Präsentationen legt. Wenn der Service dazu noch Ortungsdaten, Nutzungsdaten und Gerätebewegungsdaten berücksichtigt, wird die Annahme noch genauer.

Es lassen sich durch solche Daten adaptive Systeme entwickeln, die es erlauben, die Lösung dynamisch an den Gerätestatus und die Nutzungssituation dem KANO-Modell folgend anpassen.

Kano Modell allgemein“ von Original uploader was Trappatoni at de.wikipedia – Neugezeichnetes Diagramm, selbst erstellt. Lizenziert unter CC BY-SA 3.0 über Wikipedia.

In nativen Apps für Smart-Devices ist die Auswertung solcher Daten längst möglich. Dank der stetigen Weiterentwicklung der Web-Browser und der zugrundeliegenden Web-Standards, stehen auch Websites immer mehr Daten zur Verfügung, die solche Szenarien mittlerweile größtenteils abdecken.

Neben Gyroskop, Beschleunigungssensor und Offline-Funktionalitäten, steht u.a. auch der Zustand der Batterie zur Verfügung.

Um die Unterstützung dieses Standards genauer zu untersuchen, habe ich ein Javascript als Experimentierbasis entwickelt. Damit können diverse Nutzungsszenarien ermittelt, getestet und entwickelt werden.

See the Pen Battery API by Tamio Honma (@IOIO72) on

Über Slack können wir sehr gerne über dieses Projekt chatten:
IOIO Software Slack