Als Google Mapmaker vor einer Weile veröffentlicht wurde, habe ich selbst nicht viel davon mit bekommen. Abgesehen von dem Kommentar aus der Openstreetmap-Community, das Google sich nicht die Rechte an Daten sichern sollte, die von Nutzern freiwillig für Google erstellt werden. Ein berechtiger Einwand, den Google aber durch die Möglichkeit zum Datendownload zum Teil entkräftet.
Ein TED Talk hat mich jetzt aber noch einmal eine Blick auf Map Maker werfen lassen. In dem 1,5 Minuten kurzen Video beschreibt ein Google Mitarbeiter, das 2005 nur 15 % der Erde durch gute Karten erfasst waren. Ein Umstand, der die Hilfe in Krisensitutionen wie beim Tsunami oder aktuell in Haiti extrem erschwert. Seit dem Tsunami in 2005 haben in Google Map Maker tausende Freiwillige aus 170 Ländern Millionen von Informationsschnipseln zusammengetragen.
Visualiserung aus dem TED Talk: Entwicklung der Zeichnungen in Map Maker von 2005 bis 2009 (Vergrößern)
Laut dem TED Talk war die Ursprungsidee oder -motivation also, in Kriesenregionen gutes Kartenmaterial bereitzustellen. Und tatsächlich wird man, wenn man heute die Google Map Maker-Seite besucht, dort auf Haiti und den Aufruf, Haiti sauber zu kartografieren, hingewiesen.
Besonders schön finde ich, dass unten rechts im Map Maker die Personen aufgeführt werden, die an diesem Kartenausschnitt beteiligt waren. So kann man sich beispielsweise das Profil von Tony, einem in New York lebenden Studenten angucken, der unter anderem die Gemeindegrenzen für einen der Orte im Kartenausschnitt eingefügt hat.
Insgesamt ein wirklich schönes Projekt von Google mit beeindruckenden Ergebnissen.
Ich denke, Peldi sollte auf jeden Fall darüber nachdenken, einen Prototypen (Labs Projekt) zu erstellen, der zeigt, wie man mit einem Flash-Wireframing-Tool in Google Wave arbeiten könnte.
Update: 26.2.2010: Den Vortrag gibt es jetzt auch als Video. Leider klappt das AVI nicht, aber die Flashplayer Version funktioniert. Quelle: http://www.informatik.haw-hamburg.de/usability.html
"In jeder Ausgabe bereitet das Greenpeace Magazin in seiner Serie „Wieso, weshalb, warum?“ ein aktuelles Thema verständlich und mit vielen Illustrationen auf."
(download) Anzeige als PDF Vorschau leider nicht möglich, da in diesem PDF andere Sicherheitseinstellungen verwendet wurden. @greenpeacemag: Bitte das "kopieren" in den Sicherheitseinstellungen erlauben. Sonst kann man es nicht verbreiten :).
Eine gute Zusammenfassung: Wie man die Mechanismen, die Spiele spaßig und süchtig machen auf Communities und Applikationen übertragen kann.
Note to self: Ich muss mein aktuelles Charity-Projekt stayscout.de nach diesen Checklisten überprüfen. Zum Beispiel das Prinzip durch seine Freundschaften anzugeben… Ideen willkommen :).
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.
Mit Office 2007 wurde das Ribbon eingeführt und mit ihm hat die User Experience und das User Centered Design bei Microsoft Office und viele anderen, ähnlich komplexen Programmen, Einzug gehalten.
Endlich hat man verstanden, dass es nicht darum geht, 10 Features mehr zu veröffentlichen, sondern die bestehenden besser zugänglich und leichter bedienbar zu machen.
Als Office 2007 eingeführt wurde, hat Jensen Harris über viele der Entscheidungen gebloggt (und ich wiederum über ihn). Die frühen Folger wie MindManager , die kurze Zeit später das Ribbon ebenfalls eingeführt haben, waren leider nicht so offen.
Autodesk dagegen teilt mit uns einige ihrer Erfahrungen! Zwar berichten auch sie erst nach dem fertigen Release von ihrem Prozess — dafür legen sie jetzt richtig los: Es gibt schon zwei Blogs (1, 2) die sich mit User Experience für Autodesk befassen und Artikel wie "The Foundation of a Great User Experience" , die zeigen, dass Autodesk sich die volle UX-Spritze gesetzt hat :).
Video 1: Der Prozess zum neuen Interface mit Magneten, Papier und Statistik.
Was hat Autodesk also gemacht? – Sie haben alle Menüeinträge/Befehle auf Magneten geschrieben und auf einem Whiteboard arrangiert und kommentiert.
Das ganze fand irgendwo statt, wo alle Kollegen immer auf den Stand der Dinge schauen konnten um Kommentare abzugeben und mitzumachen. — Ein wichtiges Detail, wie ich finde, schon allein um die Akzeptanz einer solch großen Änderung im Unternehmen zu steigern.
Auf diese Weise konnten sie verschiedene neue Gruppierungen für das zukünftige Ribbon austesten. Die Zwischenschritte wurden über Fotos dokumentiert.
Schritt 1: Die Informationsarchitektur schaffen.
Anschließend wurden Prototypen des neuen Ribbon erstellt und getestet. Zuerst waren es Papierprototypen, dann inaktive Webseiten und später erste Softwareprototypen. Alle wurden mit Kunden getestet.
Viele Tests wurden dabei remote durchgeführt um Zeit zu sparen. Zudem gab es "validation tests" — wahrscheinlich sind damit Langzeittests unter realen Bedingungen gemeint.
Die Rückmeldung von Kunden war, dass sie sich über die vielen neuen Funktionen in der Software freuen würden. Damit hat Autodesk die gleiche Erfahrung gemacht wie zuvor Jensen Harris in Office 2007: Eine sinnvolle Neuanordnung von Funktionen in Aufgabenbezogenen Gruppen, schafft eine Transparenz, die es den Kunden erlaubt, mehr Funktionen zu sehen und zu verwenden. — Denn bei beiden Applikationen wurden kaum neuen Feature eingeführt; sie wurden nur besser präsentiert.
Die Entscheidungen, welche Funktionen in welcher Größe im Ribbon dargestellt werden, wurde auch bei Autodesk auf Basis von Kundendaten getroffen. Im Video sieht man in Minute 2:35 verschiedene Diagramme, die die Nutzungshäufigkeit von Funktionen widerspiegeln. Auf Basis dieser Informationen konnte man entscheiden, welche Funktionen/Button wie groß dargestellt werden sollen.
Schritt 3: Finetunig auf Basis von statistischen Daten
Video 2: Das neue Interface in Aktion mit neuen Funktionen für Einsteiger und Experten.
Mit diesem Video bekommt man einen guten Eindruck von der Funktionsweise der neuen Ribbon-Oberfläche.
Zwei Dinge sind mir besonders aufgefallen:
Zu Einen wurde neuen Nutzern der Softwareeinstieg sehr viel leichter gemacht. Zum Beispiel sind die neue SuperTooltipps (mehr) ein tolles Hilfsmittel, um eine Funktion schnell zu verstehen und zu erlernen. Ebenso das Paradigma von Office2007, Effekte und Funktionen mit möglich hohem visuellen Feedback anzubieten. In diesem Fall betrifft das den Wechsel von reinen Text-Listen zu Vorschau+Text-Listen.
SuperTooltipps erklären über Text und Bild (Quelle)
Auf der anderen Seite fallen kleine Details auf, die das Autodesk-Interface von dem Office 2007-Interface unterscheiden. Zum Beispiel die Möglichkeit, das Ribbon in zwei Stufen zu verkleinern. Ein kluger Schritt, wie ich finde, da Autodesk im Vergleich zu den Officeprodukten eine größere Experten-Nutzerschaft hat, die mit solche Detailfunktionen gut klarkommen werden.
In RobiNZ CAD Weblog erfährt man von weiteren solcher Expertenfunktionen. So soll zum Beispiel möglich sein, die "Menüs" zu personalisieren. Diese Funktion wurde in Office2007 bewusst deaktiviert — für die Akzeptanz von AutoCAD durch seine Expertencommunity, kann sie jedoch durchaus von entscheidender Bedeutung sein. Auch, wenn dadurch die Software komplexer wird.
Fazit:
Das Ribbon scheint mir eine hervoragende Wahl für Autodesk/AutoCAD zu sein.
Es ist interessant zu lesen, wie stark der Entwicklungsprozess dem gleicht, den Jensen Harris für Office beschrieben hat.
Autodesk scheint es geschafft zu haben, die Nutzerschaft gut einzubinden und das Ribbon-Prinzip auf eine Exertensoftware anzuwenden.
Und zuletzt: Die Autodesk-UserExperience-Blogs mach einen guten Eindruck und werden jetzt abonniert. :)
2
6
