Google Streams

Fokus auf den aktuellsten Termin. Im Mittelpunkt steht immer der aktuelle oder der nächste Termin. Die einzelnen Entitäten des Termins sind visuell getrennt.

Die Timeline ist das Herzstück von Google Streams. Die Zeit verläuft von rechts nach links, vergangene Termine verschwinden links hinter dem aktuellen Termin. In der Timeline ist das Zoomen und Verschieben zu einem anderen Zeitpunkt möglich.

Orte und Routen sind die interessanteste Verknüpfung. Durch Einbindung der Route vom jetzigen bis zum nächsten Termin wird, neben der Anzeige der Örtlichkeit aller Termine, eine genauere Tagesplanung ermöglicht.

Google Streams, in all its glory. Für alle Events, die keine genaue Zeitangabe haben, gibt es den »Sometimes«-Bereich. Dort sind ToDos, Personen, … gelistet. Sie haben keine genaue Zeitangabe, rücken aber mit fortgeschrittener Zeit in das Blickfeld des Nutzers.

Google Streams lebt von Interaktivität. Die Daten, die wir mit Google Streams darstellen wollen, sind komplex. Durch eine vorgegebene – aber interaktive – Ansicht bieten wir einen Fokus, der vom Nutzer selbst gesetzt werden kann. Das Video zeigt die wichtigsten möglichen Interaktionen.

Prozess

→ How might we

Wie kann eine Darstellung aussehen, die die Daten von verschiedenen Google Diensten wie Mail, Docs, Sheets, Drive, Kontakte, Aufgaben, Kalender miteinander verbindet und ihre Korrelationen herausstellt, um mit ihnen zu interagieren? Wie können die sichtbaren und unsichtbaren Tabellen im Google Calendar aufgelöst werden, um die darin enthaltenen Netzwerke zum Vorschein zu bringen?

→ Analyse des Google Calendars

Der erste Schritt war, den Kalender in seine einzelnen Bestandteile zu zerlegen und die Frage zu stellen, wie die Zukunft eines Kalenders eigentlich aussehen könnte.

Dabei fiel auf, dass jede Ansicht – ob Monat, Woche, Tag oder Liste – immer einer statischen Tabelle gleicht. Das jetzige Tool bietet zwar auch schon Verknüpfungen, die jedoch erst nach Interaktion mit einem Event oder beim Erstellen eines Events sichtbar werden.

Auffallend ist, dass die einzelnen Termine auch nur eine simple Darstellung von verschiedenen Entitäten einer Tabelle sind. Derzeit setzt sich ein Eintrag im Google Calendar aus sieben Entitäten zusammen:

Interessant sind dabei aber vor allem die Verknüpfungen eben dieser Entitäten. Beispielhaft dafür ist die Route, die sich automatisch aus zwei aufeinanderfolgenden Terminen ergibt. Oder die verknüpften Personen, die in der Vergangenheit oder in der Zukunft an derselben Datei arbeiten.

Außerdem gibt es schon die Möglichkeit, Google Drive-Dateien und Aufgaben händisch hinzuzufügen, sowie Termine in Mails automatisch zu importieren. Die Informationsarchitektur des Kalenders wird jedoch in Zukunft vermutlich erheblich komplexer werden, wodurch der Kalender in Tabellenform nicht mehr zeitgemäß sein wird.

Dem User wird die Arbeit zunehmend abgenommen, selbst seinen Kalender zu pflegen, weshalb die jetzt schon bestehenden Verknüpfungen und Netzwerke durch viele weitere ergänzt und im nächsten Schritt automatisiert ineinandergreifen werden. Es bleibt jedoch die Frage offen, ob diese auch im Interface dargestellt werden.

→ Mapping unseres Kalenders

Um die benötigten Operatoren für unsere Visualisierung herauszufinden, zeichnete Marius einen Monat lang jede Interaktion mit dem Kalender auf. Die These bestand darin, dass wir durch die Aufzeichnung auf neue Interaktionen stießen, die wir sonst bei der täglichen Nutzung mit dem Kalender übersehen hätten.

Innerhalb des Monats Mai wurde der Kalender 45 Mal aufgerufen. Zu 37,7 % wurden neue Termine erstellt und zu 28 % der Kalender geöffnet, um eingetragene Daten zu überprüfen. Zu 15 % benutzte Marius den Kalender, um die Zeiten von Terminen zu ändern. Die restlichen 20 % teilen sich auf in Termin löschen, Ort ändern und Titel ändern.

Das Ergebnis war zwar ernüchternd, aber machte deutlich, dass die Auseinandersetzung mit den Operatoren zu diesem Zeitpunkt zu früh war. Trotzdem hatten wir einen Grundstock, der uns im Verlauf der Visualisierung dabei unterstützte, konzeptionelle Entscheidungen zu treffen.

Um die erhaltenen Operatoren mit reellen Daten zu paaren, wurde anschließend eine Mindmap mit einem Monat aus Marius’ Kalender erstellt. Gemappt wurden hier die jeweiligen Titel der Termine, ihre Zeit, die beteiligten Personen und dazugehörige Dokumente. Diese Visualisierung war die Basis, anhand dessen wir die späteren Screens erstellt haben.

→ Problemidentifizierung

Wir fassen also das Problem mit aktuellen Kalendern zusammen: sie sind zwar in der Lage, übersichtlich über kommende Termine zu informieren. Das eigentlich interessante sind aber die Verknüpfungen, die zwischen Terminen gezogen werden können. So ist ein Tagesablauf, der aus Titel & Uhrzeit besteht, zwar funktional, bietet aber nicht die effizientes Tagesplanung.

Wir wollen das Problem des ineffizienten Kalenders in Verbindung mit weiteren Google Diensten lösen. Dafür sollen Informationen, die sich in handelsüblichen Ansichten schon im Dunkeln befinden, ans Licht geholt werden und dadurch einen Mehrwert bieten.

Gestaltungablauf

Die Zeit einfach neu erfinden. Die Darstellung von Zeit und wie Zeit ablaufen soll, führte mit zu den intensivsten Diskussionen. Einig waren wir uns darüber, dass es drei aufeinanderfolgende Bereiche geben sollte. Links die Vergangenheit, in der Mitte ein aktiv zu gestaltender Bereich für die Gegenwart und rechts ein Planungsbereich für alles Undefinierbare in der Zukunft. Frei herumschwebende Entitäten sorgen dafür, dass das Interface aufgelockert wird und sich die Elemente bei Bedarf untereinander über alle Zeiten hinweg verbinden lassen. 

“Oh, das ist ja wieder eine Tabelle …” Alternativ entwickelten wir ein strengeres Wireframe, bei dem ein Grid eingesetzt wird, welches in der Horizontalen alle Events chronologisch darstellt. Wie lange ein Event dauert, spielt in dieser Fassung keine Rolle. In der Vertikalen ist jedes Event unterteilt in die sieben Entitäten, was einen einfachen Vergleich zwischen den einzelnen Einheiten ermöglicht. Mit dem Entwurf lagen wir nur wieder bei einer Tabelle, weshalb wir uns von dieser Darstellung distanzierten und zunächst den freieren Ansatz verfolgten. 

Daten anzeigen ≠ Daten lesen können. Während der digitalen Umsetzung mussten jedoch neue Regeln eingeführt werden, um eine gewisse Lesbarkeit für die frei herumschwebenden Daten zu ermöglichen. Sogenannte Streams unterteilen alle Daten in Kategorien – in diesem Fall Studium, Campusgarten, Privates. Entitäten, die zusammengehören, werden des Weiteren zu Einheiten zusammengefügt. Das Ergebnis zeigte jedoch zu diesem Zeitpunkt, dass diese Visualisierung zu viele redundante Informationen erzeugt, wodurch Verknüpfungen nicht eindeutig erkennbar wurden. 

Wordcloud? Eventcloud! Um dieses Problem zu lösen, vernachlässigten wir die typografischen Elementen zu beiden Seiten, um den Blick auf die Mitte und damit auf die Gegenwart zu lenken. Positiv lässt sich hierbei hervorheben, dass die erzeugte Datenwolke besser den »Jetzt«-Bereich sichtbar macht und auch die wichtigen Verknüpfungen eleganter identifiziert werden können. Jedoch hat die Darstellung durch die Trennung der Entitäten voneinander wieder an Lesbarkeit verloren. Es wird nicht direkt sichtbar, welches Event nun mit welchen Parametern aktuell wichtig ist. 

Google Streams wird ein Dashboard. Nach diesen und unzähligen weiteren Iterationen, hatten wir das Gefühl, uns im Kreis zu drehen. Wir führten bestimmte Darstellungen ein, verwarfen sie anschließend, um sie dann wieder einzusetzen, weil die neuen Iterationen doch nicht funktionierten und nur neue Probleme schafften. Um dieser Sackgasse zu entfliehen, nahmen wir unsere bis dato erstellten Entwürfe und lösten sie in ihre Bestandteile auf, um sich erstmal einen Überblick über unsere Elemente zu verschaffen. 

Anschließend stellten wir die Ergebnisse in Verhältnis zu unserer Zielformulierung. Die wichtigsten Netzwerkformen betrachteten wir in separaten Fenstern und stellten sie in einem gemeinsamen Interface gegenüber. Die drei Bereiche, die sich hierbei herauskristallisierten, machten uns deutlich, dass wir einem einzigen Interface zu viel abverlangten. Zu viel Freiraum führt zu geringer Lesbarkeit und zu strenge Designregeln verhindern die Darstellung von Verknüpfungen.

Back to the roots. Durch diesen Erkenntnisgewinn fokussierten wir uns darauf, eine neue Darstellungsform zu erarbeiten. Dabei stießen wir auf eines der ersten Wireframes, welches zu grid-lastig wirkte und kombinierten es mit den »Streams«-Iterationen. Außerdem war uns wichtig, die darzustellenden Entitäten auf ein Minimum zu reduzieren. Mit der Einführung einer Karte im unteren Sektor, die den gesamten Tagesverlauf darstellt, erhält jeder Tag sogar eine leicht zu identifizierbare Rahmenhandlung.

Sicherlich fehlt bis zu diesem Zeitpunkt immer noch der Fokus auf der Darstellung von Netzwerken, aber mit der letzten Iteration haben wir einen wichtigen Schritt gemacht. 

Reflektion

Das gesamte Projekt hatte einen gewissen Zielkonflikt: das Ziel des Kurses war eine operationalisierte Datenvisualisierung. Unser zusätzlicher Anspruch war aber, diese Visualisierung als alltägliches Tool zu gestalten. Die Idee zu Beginn war, den Google Calendar zu ersetzen und die Integration anderer Google-Dienste zu verbessern.

Durch den Fokus auf nutzerzentriertes Gestalten ist aber immer wieder der Fokus von den eigentlich interessanten Eigenschaften unserer Visualisierung abgekommen, hauptsächlich den aufgedeckten Verknüpfungen verschiedener Entitäten. Außerdem ließen wir uns schnell von den Edge-Cases einschüchtern, die unsere systematischen Vorstellungen zunichte machten. Obwohl wir immer wieder neue Ansätze verfolgten, blieben diese häufig in der digitalen Umsetzung nach der ersten Iteration stecken. Interaktionsprobleme mit den Interface-Entwürfen oder den Daten erschwerte das Vorankommen, weshalb wir uns zuerst auf eine Lösung des Interfaceproblems stürzten, als zu versuchen geeignete Darstellungsmöglichkeiten für Daten zu gestalten. Hier hatten wir mehr Raum nach oben.

Gut gelungen ist die Verknüpfung der _location_-Daten. Im Usability-Kontext und in der Datenvisualisierung konnten wir eine geeignete Lösung finden, die unsere anfängliche Zielbeschreibung gut getroffen hat. Diese ausführliche Ausarbeitung der Verbindungen hätten wir aber auch auf andere Entitäten ausweiten können, wie zum Beispiel auf die Bearbeitung von Dokumenten und die damit verknüpften Personen.

Abgesehen davon ist uns bei der visuellen Gestaltung des Interfaces eine gewisse »David gegen Goliath«-Mentalität aufgefallen – es gibt einen guten Grund, dass die meisten Kalender-Tools sehr ähnliche Ansichten anbieten, sie sind schlicht am geeignetsten für eine effiziente Nutzung eines Kalenders. Das, gepaart mit der Integration von neuen Diensten, ist eine komplexere Aufgabe als wir angenommen hatten.

→ Learnings

Viele Iterationen sorgen für Frustration, sollten aber nicht einschüchtern. Die häufigen Richtungswechsel während des Kursverlaufes waren frustrierend – haben wir ein visuelles Problem mit aufwändigen Methoden und ausführlichem Sketching lösen können, sind dadurch viele neue aufgetreten. Geholfen hätte hier sicher, öfter bei null anzufangen und nicht nur zwei Schritte zurück zu gehen. So sind wir zwar den ersten visuellen Ideen treu geblieben, haben aber unnötig viele Schleifen gedreht.

Die Unbestimmtheit im Gestaltungsprozess als Chance wahrnehmen. Die im bisherigen Studium gelernten Methoden aus dem Kopf zu kriegen ist gar nicht so einfach – wir haben uns sehr schwer getan, vom user-centered design wegzukommen und den Fokus auf eine freie Datenvisualisierung zu legen. Oft haben wir also versucht, Interface-Probleme mit systematischen – und damit einschränkenden – Methoden zu lösen. Der richtige Ansatz wäre gewesen, mit einer neuen und freieren Richtung an das Thema Datenvisualisierung heranzugehen. Kurz gesagt: in solchen Projekten zukünftig agiler arbeiten.

Speziell bei operationalisierten Datenvisualisierungen nicht die Usability einschränken. Ein häufiger Diskussionspunkt war die unklare Grenze, die wir zwischen Datenvisualisierung und Kalender-Tool ziehen wollten. Schwierig war hier, dass eine Nutzbarkeit im alltäglichen Umgang mit dem Kalender gegeben und dennoch die Daten im Hintergrund in der Visualisierung sichtbar sein sollten. Eine klare Entscheidung, früh im Prozess, hätte hier eine einfachere Gestaltung ermöglicht.