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

Seit dem Continuity-Seminar versuche ich verstärkt, die Methoden des Paper Prototyping umzusetzen. Warum? Weil wir beispielsweise erst mit Hilfe der vielfältigen und leistungsstarken Methoden, die man diesem Schlagwort zuordnet, unser Abschlussexperiment, die Neukonzeption des Interfaces für den DB-Fernverkehrsautomaten, umsetzen konnten.

Aber was ist Paper Prototyping?

Shawn Medero beschreibt das aktuell bei A List Apart (via Tim). Der Artikel geht nicht gerade in die Details und betrachtet auch nicht alle Möglichkeiten, gibt aber einen guten Überblick.

Insbesondere die Beispiel-Scans/Fotos solltet ihr euch anschauen, da sie offen-sichtlich machen, worum es geht und wie Paper-Prototypen im Prinzip funktionieren.

Amazon search inside

Wer wirklich mehr über das Potential von Konzeption, Entwurf und Testen mit Stift und Papier wissen möchte, sollte ich das Buch Paper Prototyping von Carolyn Snyder zulegen! Es scheint das Standard-Werk zu sein, gehört inzwischen auf meinen coffee table.

Dieses Buch empfielt übrigens nicht nur Shawn in seinem ALA-Artikel, sondern auch Jensen Harris in seinem Office User Interface Blog. In dem Artikel Paper Prototypes beschreibt er, wie das Office 12-Team auf die Idee für das radikal neue Office-Interface gekommen ist.

Jensen zeigt damit auch, wie vielfältig Papier-Prototypen ausgelegt werden. Es geht nicht nur um Stift und Papier, sondern auch um Interface-Ausdrucke, wie er auch in The Wall of Ribbons beschreibt und zeigt.

Persönlich reizt mich an dieser Arbeitsweise, dass die Arbeit mit Stift und Papier immer noch viel intuitiver ist, als den Umweg über Software zu gehen. Trotzdem gibt es auch gerade hier viel zu lesen: Jensen Harris schreibt über Prototyping With PowerPoint und bei boxesandarrows kann man über Prototypenentwicklung mit Dreamweaver und Visio lesen. Gerade was die PowerPoint- und Dreamweaver-Verwendung angeht, bin ich skeptisch :).

Vielversprechender dagegen finde ich den Ansatz von Prof. James Landay: DENIM Einmal, weil er mit Tablet-PCs arbeitet und somit die praktische Stifteingabe berücksichtigt. Zum Zweiten aber auch, weil sein Ansatz den gesamten Prototyping-Prozess in einer Anwendung berücksichtigt. In welche Richtung das geht, zeigen seine Videos.

Doch wieder weg von der Software:

In dem Artikel An Introduction to Using Patterns in Web Design beschreibt Ryan Singer schon 2004, wie er durch Papierskizzen seinen Konzeptionsprozess beschleunigt und anschließend direkt in die Umsetzung springen kann.

In den Kapiteln There's Nothing Functional about a Functional Spec und Don't Do Dead Documents des Getting-Real-Buchs, das ja bekanntlich inzwischen kostenlos online steht, geht 37signals ebenfalls auf diesen Vorteil ein: Im Rahmen des Feldzugs gegen Spezifikationsdokumente werden die Chancen der schnellen Papierskizze hervorgehoben: Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document.

flow|state beschreibt noch einen anderen Vorteil in dem Artikel Matching design sketches to the desired level of design feedback. Kurz gesagt: Zu hübsch kann nachteilig sein, da es den Blick vom Konzept hin zu visuellen und unwichtigen Details (ab)lenkt. Schaut euch die vier Beispielbilder des gleichen Interfaces an und ihr versteht, worauf Jan Miksovsky hinaus will.

Und wen das alles noch nicht überzeugt hat: Auch Jakob Nielsen finden Paper Prototypen gut — wenn das kein Argument ist? ;-)

Es ist jetzt 4 Jahre her, dass ich mit Niklas und Kristina in Oliver Wredes Seminar Continuity ein alternatives Interface für den Fernfahrkarten-Automaten der Deutschen Bahn erstellt habe. Seit dem ärgere ich mich alle Jahre wieder aufs Neue, dass ich mir nicht die Zeit genommen habe oder nehme, unsere Semesterarbeit endlich mal online zu stellen.

Vielleicht liegt das an diesem Phänomen, dass man, wenn man ein Semester lang an einem Thema arbeitet und schlussendlich eine sehr gute, einfache Lösung findet, diese als so offensichtlich und banal empfindet, dass mein Sendungsbedürfnis nicht geweckt wurde. Hinzu kommt sicher auch, dass wir es damals nicht geschafft haben, unserem Anspruch gerecht zu werden, nicht nur ein gutes Interface zu entwickeln und das dann auch noch bei der DB in Frankfurt zu präsentieren, sondern darüber hinaus noch das komplexe Thema Continuity in ein paar aussagekräftigen Seiten zusammen fassen wollten. Perfektionsmus als Handbremse =(.

4 Jahre später bin ich klüger und werfe euch einfach unsere und meine gesamte Arbeit auf den Bildschirm — mit alle seinen guten Ideen und Ansätzen, seinen unfertigen Kapiteln (man beachte unser Fazit — es ist leer :)) und den nicht Korrektur gelesenen Texten. Man möge es mir und uns nachsehen :-).

Bevor ich euch unser — wie ich finde — damals wie heute revolutionäres ;) DB-Interface zeige, noch ein paar Worte vorweg: Das Redesign des Automaten war der Praxisteil für das Seminar Continuity, in dem wir uns erstmal mit Flow, Experience Design, Emotionalität im Interface und solchen Dingen befasst haben (Seminarbeschreibung). Versucht bitte, euch 4 Jahre in der Zeit zurück zu versetzten: Damals gab es noch kein innovatives iPhone- oder iPod-touch-Interface mit all seinen Animationen und Bewegungen und dem großen iPhone-Ökosystem (wohl natürlich den iPod Classic mit seiner links/rechts-Metapher, dessen Einfluss ihr im UI auch sehen werdet), die Anzahl an jQuery- oder gar HTML5-gepimpte Webseiten mit vielen auf/zu-, vor/zurück-Animationen und Übergängen die kleine Continuity-Erlebnisse schaffen war auch noch spürbar geringer… und damals haben sich auch Firmen noch nicht User Experience auf die Startseite geschrieben.

Das Endergebnis:

Was haben wir also gemacht? — Lasst es uns von hinten nach vorn betrachten und mit dem Endergebnis starten:

Einen guten Einstieg bietet die Präsentation, die wir nach unserem Semester bei der DB in Frankfurt gehalten haben.

Interessant wird es nach der Einleitung ab Folie 7. Hier zeigen wir die Demo unseres Interfaces. Zum Glück habe ich damals meine Präsentationsnotizen abfotografiert: Wir sind eingestiegen mit einer interaktiven Demo, in der ich das Szenario eines Kunden durchgespielt habe.

Klickstrecke: Expresskauf → Zurück → Expresskauf → Düren → Aachen → Aachen HBF (Angabe wird in Demo nicht gespeichert) → Regionalverkehr → Regionalverkehr oder zurück → Verbindungen suchen. Weiter geht es leider nicht. Den Kauf abbrechen-Button kann man in der Ziel-Ortsauswahl testen.

Diese Aspekte haben wir in der Präsentation hervorgehoben:

• Der Start-Screen des Automaten ist das UI selbst, kein vorgeschalteter Werbescreen. Vorteil: Schon während der Nutzer auf den Automaten zugeht, kann er entscheiden, welchen Button er klicken will. Hier die UX durch Werbeinteressen zu mindern, ist unvernüftig. Und außerdem können die Einnahmen nicht so groß sein, denn es handelt sich ohne hin häufig nur um Eigenwerbung.
• Die Basis-Interface-Design-Metapher ist ein vor/zurück-System bei dem die Schaltflächen schon zeigen, wo der Screen weiter geht und sich aus der Schaltfläche die nächste Ebene entwickelt. Sehr flexibel und sehr gut zu verstehen und vor allem: Veränderungen leiten sich her/sind nicht plötzlich. Das Gefühl der Kontrolle für den Nutzer bleibt erhalten.
• Die Animationen müssen dabei so schnell sein, dass die Metapher verstanden wird, ohne nervige Wartezeiten zu erzeugen.
• Einher mit der Animationsmetapher geht die Idee, die Anzeige wie den Ausschnitt aus einem Lageplan zu verstehen. Hinter dem Display wird der Lageplan nach links/rechts bewegt. Man weiß aber immer, wie man zum vorherigen und nächsten Schritt kommt. Auch hier wieder unsere zwei Kernziele: Vorhersehbarkeit im UI und das Gefühl der Kontrolle für die Nutzer.
  
• Zum Schluss haben wir auf die feste Position des Abbrechen-Button hingewiesen, da Interfaces, die mit Animation und solchen Metaphern arbeiten, aufpassen müssen, den Nutzer nicht (visuell) zu überfordern. Einheitliche Positionen für zentrale Elemente und ein visuell ruhiges UI war unsere Lösung dafür.
• Als nächstes ging es uns um die Sprache im Interface. Durch kontextbezogene Texte, konnten wir eine freundlichere und klarere Interface-Sprache wählen. Schaut euch im Vergleich die Fotos des alten Automaten an…
• Als Voraussetzungen für dieses UI haben wir ein performantes System angegeben, das diese Animationsqualität auch abbilden kann. Auf den hochformatigen Bildschirm — eine der Kern-Änderungen, die diese Idee erst möglich gemacht hat — bin ich in diesem Zusammenhang interessanter Weise nicht mehr eingegangen.

Zu den Dokumenten:

1. Zur Präsentation auf Slideshare
2. Zur Demo/Clickdummy
3. Das PDF zu den Screens, die in der Demo animiert sind. Der essentielle vor-zurück-Effekt kommt dort natürlich überhaupt nicht rüber…

Das war also unser Endergebnis. Aber es gibt noch eine Reihe weiterer Artefakte, die einen Blick wert sind:

Erster Entwurf:

Mein erster Redesign-Entwurf für den Automaten hat sich noch stärker an dem bestehenden Automaten orientiert. Es ging mir erstmal darum, das UI zu verstehen, aufzuräumen und zu schauen, wie viel man schon durch Verbesserung der einzelnen Screen (Anordnung, Funktionen) erreichen kann.

Was sieht man hier:

• Startseite ohne vorgeschalteten Werbe-Screen — statt dessen Werbung im „Footer"
• Neue Gruppierungen der Button und neue Funktionstexte, die den dahinterliegenden Screen direkt erklären
• Eine Art OneClick-Kauf-Zusammenfassung mit möglichst intelligenten Defaults, die man dann selbst anpasst.
• Eine Karten-Ansicht für den Kauf für den UseCase „Ich möchte in die Nähe des Schokoladenmuseums", bei dem man den Haltestellen-Namen noch nicht kennt
• context-bezogene Hinweise (vgl. Minigruppenticket) im Interface, um die Tarifkomplexität abzubilden
• Plus/Minus Eingabe-Pattern für Reisende und Bahncards
• 4 Varianten: Verbindungsdauer und Umsteigen visualisiert in Form von Sparklines in der Verbindungen-Ansicht (weiße Linien) — Das ist eine Funktion für erfahrene Nutzer. Für diese sehr nützlich, für den Rest nicht störend…

Mein zentraler Fehler bei dieser Vorgehensweise: Ich habe in Einzelscreens in InDesign gedacht und nicht in einer (animierten) Abfolge von Screens. Hier war das Tool schon das Problem, weil es hat mich in Einzelbild-Sequenzen gefangen hat. Inhaltlich finde ich die Screens viel besser als das alte UI. Meine ersten Animations-Experimente haben aber gezeigt, dass ich kein logisches Animationsmuster finden werde, das dieses Interface unterstützt (weiter nach Rechts, zurück nach oben, Button öffnen einen überlagernden Screen… — alles unlogisch).

Paper Prototyping als Heilsbringer:

Nachdem der zweite Entwurf in seiner Animationsphase gescheitert ist, habe ich eine andere Herangehensweise probiert: Statt im Detail an UI-Verbesserungen zu arbeiten, musste erstmal eine tragfähiges Basis-System gefunden werden. Für diesen Schritt war das Arbeiten mit Papier genau das richtige: Man achtet weniger auf Details, kann schnell experimentieren und läuft nicht Gefahr, sich von seinem Authoring-Programm oder dem Rahmen, den man glaubt vom System vorgegeben zu bekommen, einschränken zu lassen.
Auf diesem Weg wurde dann auch klar, dass unser UI ein hochformatiges Display braucht. Schließlich geht es beim ganzen Kaufprozess ständig um Listen-Ansichten…

Die Prototypen wurden jew. in den Seminar-Terminen vorgeführt und besprochen.

Paper-Prototype Entwurf 1:

Der Erste Entwurf ist noch sehr roh…

Dazwischen gibt es eine Reihe an Skizzen, in denen ich mit Details wie dem Zurück-Button (Design und Position) experimentiere.

Paper-Prototype Entwurf 2:

Der zweite Entwurf ist dann schon nah an dem dran, was ich dann erneut in InDesign gestaltet habe.

Zum Schluss noch zwei weiterführende Links:

Seminar-Dokumentation:

Unsere (unfertige) Seminardokumentation versucht, wie zu Beginn gesagt, das ganze Thema Continuity einzuordnen und unser Seminar mit allen Teilaufgaben und Entwürfen zusammen zu fassen.

Fotos vom alten Automaten:

Da die Bahn zur Zeit ja ihren Automaten neu gestaltet, erhalten diese Fotos bald Museumsqualität :-) Ich habe fast jeden Screen im alten Automaten fotografiert.

Danke und das neue DB-Inteface

4 Jahre nach unserem Entwurf hat nun auch die Bahn ihr Fahrkartenautomaten-Inteface erneuert. Links dazu sammel ich übrigens in einem Google Buzz-Post. Ich habe selbst noch nicht genug mit dem neuen Interface experimentieren können, um es wirklich beurteilen zu können. Es scheint zumindest keine Verschlechterung zu sein :-) und einige der Probleme, die wir gesehen und gelöst haben, wurden zum Glück angegangen und zum Teil ähnlich gelöst.

Vor allem muss ich der Bahn aber für das neue Interface danken, weil es mir noch einmal gezeigt, das unsere Arbeit damals sehr interessante Ansätze hatte über die gebloggt werden muss.
Der wirkliche Dank gilt aber Oliver für das gute Seminar und Kristina und Niklas für die gute Projektarbeit!

Was haltet ihr von unserem Interface-Ansatz?

An diesem Wochenende haben Alex, Tim, Siggi und Jay zum Google Wave Hackathon in Düsseldorf eingeladen. Herausgekommen ist dabei nicht nur ein Google Wave-Testaccount für alle Teilnehmer sondern auch zwei Tage voller spannender Diskussionen rund eine neue Technologie voller Potential: Google Wave (Screenshots, Einführungs-Video).

In diesem Blogpost findet ihr eine lange Liste an Notizen, die ich im Nachgang zu unseren Diskussionen eben erstellt habe — darunter auch die Erklärung zum Blog-Titel :-).
Sie stammen allesamt aus dem Austausch mit Tim, Siggi, Jay und Lydia.

Wir hatten uns in dieser kleinen Gruppe zurückgezogen, wärend die anderen Teilnehmer sich am Wave-Code versuchten und in den zwei Tagen einen Prototypen programmiert haben, der Daten aus einer Wave ausließt, an einen Webservice übergibt, zurück in die Wave schreibt und dort über einen Robot in einem Gadget wieder darstellt. Die Wave-API scheint wirklich einiges herzugeben und einfach zu verwenden zu sein.

Rainald hat uns übrigens porträtiert während dieser Zeit — ihr seht, wir haben intensiv diskutiert und nachgedacht, nicht nur gegrillt ;-).

Google Wave ist an erster Stelle ein Kollaborations-Tool (Was ist Google Wave?)

• Kollaboration ist nichts Neues. Viele Programme behaupten, dass sie dieses Alltagsproblem lösen und Google hat mit Google Docs eines der wichtigsten beigetragen.
• In Wave hat Google aber eine bisher noch ungesehene und technisch beeindruckende Sammlung von Tools zusammengestellt, die Kollaboration begünstigen: Instant Feedback durch das Live-Typing mit sehr gutem visuellen Feedback welcher Autor gerade wo arbeitet, automatische Versionierung der Inhalte, Playback-Funktion zum Änderungen nachvollziehen zu können, Kommentare und Inline-Kommentare sind glaube ich die wichtigsten.
• Google Wave ist dabei anders als eMail: Man etwas nichts ab („kopiert" es auf einen anderen (Mail)server), sondern lädt jemand ein bzw. fügt ihn hinzu, damit er an etwas mitarbeiten kann.
• Google Wave ist auch kein Chat-Tool — auch wenn die Übertragung jedes Tastendrucks das vermuten lässt und es gerne erzählt wird. Chatten funktioniert in Wave aber zur Zeit garnicht weil das nötige Pattern (ein Eingabefeld das Nachrichten zu einer zeitlich sortierten Liste hinzufügt) im Interface überhaupt nicht abgebildet wird. (Es könnte allerdings zukünftig problemlos Chatmodus für Blibs (Wave-Elemente) entwickelt werden.)

Was macht Google Wave so interessant?

• Google Wave hat das Potential die Alltagskommunikation wie wir sie zur Zeit kennen, völlig zu verändern.
• Wave kann Dateien überflüssig machen
  • Der aktuelle Workflow im Berufsalltag sieht so aus, dass wir in Worddokumente Texte schreiben, Zahlen in Excel packen, Wireframes in Visio/Axure/… und Bilder in Photoshop bearbeiten.
  • Diese Dateien speichern wir auf einem Fileserver, versionieren sie durch Dateinamen und schicken sie zwischendurch wild in der Gegend herum, erzeugen Kopien, verändern sie und mergen sie anschließend mehr oder minder aufwändig zu einem Dokument das dann ausgedruckt und bspw. unterschrieben wird.
  • Wave gibt uns die Möglichkeiten, völlig anders zu arbeiten: Für all die Dokumententypen legen wir immer eine Wave an. Alle die mitarbeiten, werden eingeladen. In der Wave entsteht der Text. Für spezielle Inhaltsbereiche wie Wireframes, Datenbanken/Tabellen, Bilder werden Wave-Gadgets eingebunden die wie eine eingebettete GoogleMap zwischen dem Text stehen. Die Gadgets bieten einem zusätzliche Tools für die Arbeit an den Spezialproblemen (Wireframe, Tabellenauswertung, Bildbearbeitung, …).
  • Während des gesamten Prozesses wird jede Version automatisch gespeichert. Diskussionen können mit allen Teilnehmern oder „privat" in Kleingruppen geführt werden.
  • Am Ende wird ein Snapshot der Wave erstellt und das Dokument ist abgenommen.
  • Voraussetzung dafür ist natürlich neben einigen anderen Verhaltensänderungen, dass wir technisch und gesellschaftlich bereit sind, Verträge, Abnahmen, … nur noch digital zu unterzeichnen.

• Wave kann Office-Programme an sich überflüssig machen
  • Betrachtet man den oben skizzierten Workflow, kommen darin Programme, wie wir sie jetzt kennen, nicht mehr vor. Aus informationsarchitektonischer Sicht wird der Knotenpunkt gewechselt:
    • Excel –> test.xls –> Serverversionierung
      wird zu
    • Waveversionierung –> Test-Wave –> Excel-Modul/-Gadget
      Das bekannte Feature-System wird also einmal umgedreht.

  • Wem bei diesem Beispiel „Archy" (alias THE http://en.wikipedia.org/wiki/Archy) einfällt, der ist an dieser Stelle wahrscheinlich genauso gespannt wie ich: Könnte das etwa der Weg zum Betriebssystemlosen Computer sein? — Vielleicht. Aber auch wenn Wave Fileserver und Office-Dateien wahrscheinlich überflüssig macht, funktioniert das Gedankenspiel bei Computerspiel-Programmen schon wieder nicht mehr. Es sei den, man geht davon aus das auch diese bald nur noch im Browser online stattfinden. Dann bräuchte es nur Wave und Websites, also nur einen Browser. Hier wären wir dann bei Google Chrome OS angelangt und der Kreis schließt sich wieder.
  • Aber zurück zu Wave und einem anderen Beispiel:

• Ich wünsche mir Wave zum konzipieren…
  • Schon seit der Wave-Einführung auf der Google I/O wünsche ich mir Wave als Konzeptionstool. Denn auch wenn schon seit vielen Jahren Websitekonzepte gemacht werden, ist gerade das Problem der Kollaboration (in der einfachsten Form Feedback-Schleifen mit dem Kunden) für mich nicht sauber gelöst.
  • Hier sei als Beispiel einer von vielen möglichen Konzeptionsprozessen skizziert und dann mit einem möglichen Wave-Prozess verglichen:
  • Aktueller Konzeptionsprozess:
    • Wir schreiben Grundsatzkapitel zum Konzept in Word
    • Dann werden Skizzen per Hand gemacht, vielleicht besprochen
    • und in einem Wireframing-Tool umgesetzt
    • Entweder man kopiert dann die Skizzen in Word um sie mit guten Text-Tools zu annotieren… oder man kopiert den Text ins Wireframing-Tool. Beide Methoden sind suboptimal.
    • Die einzelnen Kapitel, meist aber das ganze Dokument werden dann intern und vor allem mit dem Kunden gereviewed. Bei der Word-Variante kann man dabei die Word-Überarbeiten-Tools nutzen. Für einen richtigen Diskurs übers Konzept ist das aber auch nur eine Krücke.
    • Mit der Abnahme wird das Konzept dann eingefroren und an die Entwicklung übergeben.
    • Die wiederum erstellt unter Umständen ihr eigenes, technisches Konzept und macht das gleiche Spiel wieder durch.
  • Wave-Konzeptionsprozess:
    • Mit Wave könnte das alles besser sein :-). Wir erstellen eine Master-Wave die auf viele andere Waves (Kapitel) verlinkt.
    • Die einzelnen Waves können Text und Wireframes enthalten. Die Wireframes werden aber direkt in der Wave editiert. Zum Beispiel mit Tool wie Balsamic (http://www.balsamiq.com/) bzw. ihren hoffentlich besseren Nachfolgern.
    • Kollegen können dabei problemlos in der Wave gemeinsam arbeiten und sich gegenseitig verbessern.
    • Einzelne Kapitel können asynchron zur Freigabe und Diskussion an andere Gewerke oder den Kunden gegeben werden. Der Status kann durch Status-Gadgets in der Wave festgehalten werden. Und man bräuchte eine neue Wave-Funktion für Snapshots „diese Version wurde so abgenommen".
    • Die Inline-Kommentare und das gemeinsame Editieren am Haupttext sind dabei zwei hervorragende Funktionen um schnell ein gutes und für alle verständliches Ergebnis zu erzielen.
    • Darüberhinaus kann man jetzt endlich die Trennung zwischen Konzept, Design, Technikkonzept und Dokumentation auflösen: Zu einem Kapitel „Startseite" bspw. können drei Wave-Bereiche existieren. Einer fürs Wireframe, einer fürs Design und einer für die technische Konzeption.
    • Für die wirksame Arbeit bräuchte man dann wahrscheinlich Filter-Methoden um Waves die mit „Technikkonzept" getaggt sind je nach Bedarf auszublenden.
    • Am Ende hat sich das Konzept in eine Dokumentation verwandelt. Wissensmanagement ist also inbegriffen :).
  • Diese Beschreibung hat bestimmt viele Lücken und Probleme und Wave muss noch ein paar Funktionen hinzubekommen, um so einen Prozess wirklich abdecken zu können. Auch müssen wir unser Verständnis von Konzepten ändern, damit wir wirklich akzeptieren, dass das Konzept nur ein Prozess hin zum fertigen Produkt ist und als eigenes Objekt nicht wirklich aufbewahrt werden muss (über die Playback-Funktion kann man es immer wieder „herausholen"). Insgesamt sehe ich aber ein sehr großes Potential in Wave.
  • Exkurs zu Useraccounts: Wer übrigens bei diesen Beschreibungen denkt, dass wir ähnliches auch in Sharepoint und anderen DMS haben… — Uns ist beim Wave-Hackathon ein interessanter Unterschied aufgefallen: Um gemeinsam mit bspw. einem Kunden an einem Dokument zu arbeiten, dass in Sharepoint abgelegt ist, gibt man heute dem Kunden einen Zugang zum Sharepoint. Wave müsste hier anders vorgehen: Sowohl Kunde als auch Agentur müssten Waveserver laufen haben, um eine Zusammenarbeit zu ermöglichen. Oder aber, man würde externe Wave-Accounts auf dem Agentur-Waveserver erstellen… — Ein Szenario, dass ich so bei Wave noch nicht gehört habe.

Das Interface von Wave muss sich weiterentwickeln!

• Das Interface von Wave, das Google zur Zeit allen als Demoanwendung zeigt, ist sehr klug gemacht: Man hat bewusst die Anordnung von Office kopiert um den Einstieg in ein System zu erleichtern das fast wie eMail ist aber doch ganz anders.
• Betrachtet man aber die Wave-Anwendungsfälle die ich oben mit Blick auf die Dokumentenformate beschreibe, muss sich das UI noch stark weiterentwickeln. Hauptsächlich geht es dabei um Platz und schnelle Interaktion, vor allem für den Wechsel zwischen Waves (aka Programmen).
  • Zur Zeit kann ich mit Alt-Tab oder über die Taskleiste sehr schnell zwischen Programmen wechseln — eine der wichtigsten Funktionen des Betriebssytems.
  • Wave dagegen existiert zur Zeit hauptsächlich in einem Tab und versucht dort möglichst sinnvoll Platz zu schaffen.

• Kurzfristig kann die Lösung sein, Waves einfach in neuen Festern und neuen Tabs zu öffnen um darüber schnell zwischen ihnen wechseln zu können.
• Visionärer gesehen könnte Wave aber eines der ersten Interfaces sein, bei dem ZUI-Metaphern (http://de.wikipedia.org/wiki/ZUI) und Interfaces und die die Räumliche Anordnung von Elementen sinnvoll angewendet werden.
  • ZUI für Wave: Das beste Beispiel ist der Wechsel von einer Wave die text mit Gadgets (wie einem Excel-Gadget) enthält hin zur Editieransicht des Excel-Gadgets. Hier macht ein ZUI sehr viel Sinn um schnell und verständlich zu einem neuen Screenzustand zu gelangen, der einem neue Tools auf voller Fläche bietet (und wieder zurück).
  • Räumliche Anordnung von Elementen: Das Thema beschreibe ich unten ausführlicher aber vereinfacht gesagt: Ich habe meine RSS-Reader-Waves, meine Office-Intern-Waves, meine Kunden-Waves in denen (ZUI) auch meine Kundenprojekt A-Waves liegen und kann all diese Gruppen auf einer räumlichen Fläche anordnen, so dass ich sie leicht wiederfinde. Oben Rechts sind die Kunden-, Links unten die RSS-Reader-Waves etc.

Danke an dieser Stelle insbesondere an Tim für den Austausch und die Anregung zu diesen Gedanken.

War das schon alles?

• Nein ;).
• Neben all diesen Themen haben wir auch noch darüber nachgedacht, dass Waves in Unternehmen feste Hierarchien brauchen um wiedergefunden werden zu können. Man braucht ein Pendant zum Intranetstrukturbaum Projektmanagementtipps oder Konzeptrichtlinien… Diese Waves müssen für alle Mitarbeiter auf die gleiche Weise auffindbar sein, damit auch analog darauf verweisen kann (Telefon: „Schau in der Sammlung X nach die unter Y liegt").
• Gleichzeitig braucht es persönliche Navigationsmechanismen wie favorisierte Waves (Stern-Funktion) und eigene Hierarchien (wie hierarchische Browser-Favoriten).
• Das ganze Playback-Thema hat noch viel Potential um bspw. Szenarien wie das Nachbereiten der letzten Wochen nach dem Urlaub abzudecken.
• Außerdem gibt es eine Reihe an Funktionen, die meiner Ansicht nach nicht über Robots oder Gadgets in Waves eingebunden werden können, sondern nativ unterstützt werden sollten. Eines hat Google schon eingebaut: Ein Adressbuch das Kontaktverwaltung erlaubt. Weitere ist ein Kalender-Tool mit Zusage-Absage-Funktion, eine Apple-Mail-Artige Verknüpfung von Waves mit einem ToDo-System und ein Note-System mit dem man sich Textpassagen zur späteren Bearbeitung merken kann.

Jetzt wäre es natürlich toll, wenn ihr im Wave-Stil eure Kommentare und Korrekturen direkt in den Artikel schreiben könntet. Da das aber nicht geht, freue ich mich über Gedanken in den Kommentaren.