Zwei Ankündigungen: "Barrierefreies Internet" und uxHH am 3.7.

Zwei Ankündigungen möchte ich Euch nicht vorenthalten:

1. Am Mittwoch, 28.6. (wohl WM-frei :-)) findet von 16-18h eine Veranstaltung der Handelskammer zum Thema "Barrierefreies Internet" statt:
   Ohne es zu ahnen, sperren viele Firmen mit ihren Internetseiten und Online-Shops ganze Kundengruppen aus. Ihr Webdesign nimmt keine Rücksicht auf mobile oder ältere Internetnutzer und Menschen mit Behinderungen. Unübersichtliche Seiten, zu kleine Schriften und verwirrende Steuerelemente machen vielen Surfern das Leben schwer. Für mobile Endgeräte sind zahlreiche Internetseiten nicht geeignet. So stoßen viele Internetnutzer auf unnötige Barrieren. Wir zeigen Ihnen, dass sich Barrierefreiheit und ein attraktives, benutzerfreundliches Webdesign nicht ausschließen und sich ein barrierefreier Internetauftritt letztlich rechnet.
   Veranstaltungsort ist die Handelskammer HH, Adolphplatz 1, 20457 HH (das ist direkt am Rathausmarkt). Mehr Infos und Anmeldung (bis morgen, 21.6.!) gibt es auch als PDF, inklusive der Namen der ReferentInnen.
2. Am Montag, 3.7., findet der monatliche User Experience Roundtable HH statt - dankenswerter Weise wieder einmal bei SirValUse (und wie man dort hinkommt). Der Abend dreht sich um das neue MS Office 2007. Eingeladen ist für 19 Uhr; der Vortrag beginnt um 19:30h. Wir freuen uns über Besuch!
   

Vortrag: Multi-tasking in the Workplace: Examining the Nature of Fragmented Work

Am kommenden Montag, 19.6., wird Frau Prof. Dr. Gloria Mark von der University of California in Irvine einen Vortrag halten über "Multi-tasking in the Workplace: Examining the Nature of Fragmented Work". Es liegen ja inzwischen ausreichend Studien vor, die zeigen, dass Information Workers alle paar Minuten durch äußere Reize in ihrer Arbeit gestört werden und die Tätigkeit so hoch fragmentiert ist. Prof. Mark wird Lösungsvorschläge vorstellen, wie mit diesem Sachverhalt umgegangen werden kann, so dass die Produktivität der Mitarbeiter erhalten bleibt. Aus der Ankündigung:

Most current designs of information technology are based on the notion of supporting distinct tasks such as document production, email usage, and voice communication. In this talk I will present empirical results that challenge this idea and suggest instead that people organize their work in terms of much larger thematically connected units of work. I will discuss results from fieldwork observations of 36 information workers whose activities were timed to the second, over three days. The results show that workers experience a high level of fragmentation in their work, irrespective of their organizational role. People averaged about three minutes on a task before switching tasks or being interrupted. People interrupted themselves almost as often as they were interrupted from external sources.

I introduce the concept of working spheres to explain the inherent way in which individuals conceptualize and organize their basic units of work. Working spheres are also fragmented: people worked in an average of 12 different working spheres and switched working spheres about every 10.5 minutes. Most interrupted working spheres are resumed, but only after people first work in more than two others. Collocated workers worked longer than distributed workers before switching, but experienced more interruptions, which I attribute to a higher awareness of their colleagues' natural breaking points in the task. I conclude with a discussion of implications for information technology design: IT needs to support people in maintaining continuity of their work, in light of such frequent task switching.

Ort & Zeit:
Montag, 19. Juni 2006 um 17 Uhr c.t.
Vogt-Kölln-Straße 30, Konrad-Zuse-Hörsaal, Gebäude B

UxHH vom 6.6.2006: Mark Hurst Live bei uns in HH

Gestern Abend trafen sich die Hamburger UX-Leute bei Tribal DDB, um etwas über Good Experience zu lernen. Good Experience ist ein Projekt von Mark Hurst, Gründer und Leiter der Consulting-Firma Creative Good (NYC). Marks Fokus liegt darauf, gute Nutzungserfahrungen / Nutzungserlebenisse zu fördern. Sein Good Experience Newsletter ist immer wieder vergnüglich zu lesen, und seine Sammlung kaputter User Experiences bei ThisIsBroken.com führt auch immer wieder vor Augen, an welchen Stellen das große Ganze bei der Entwicklung aus den Augen verloren wurde. Seit 2003 veranstaltet er in New York die so genannten GEL-Konferenzen ("Good Experience Live"); dieses Jahr (am 1.9.) wird es auch die erste europäische GEL geben (die euroGEL in Kopenhagen).

Wir sahen uns gestern zunächst ein paar Video-Mitschnitte von der letzten GEL an und schalteten dann Mark live aus New York dazu (was auch mittels iChat relativ gut funktionierte, nachdem wir rausgefunden hatten, wie man meine Digicam dazu überreden konnte, nicht immer automatisch in Standby zu gehen). Mark kam sehr enthusiastisch rüber - jemand, der von einer Mission getrieben wird. Die Mission heißt: Gute Nutzungserlebnisse ermöglichen, Entwicklung ganzheitlich angehen, aus guten Nutzungserfahrungen lernen, sich begeistern lassen und diese Begeisterung in eigene Projekte tragen. Sympathisch macht ihn auch, dass er darauf besteht, kein Guru zu sein und keiner sein zu wollen - und dass er keinen Zirkus veranstalten will mit eingeflogenen Mehr-oder-weniger-Gurus à la Nielsen, Norman, Spool. Gegenüber den Europäern ist das für ihn auch ein Zeichen des Respekts - amerkanische Gurus einzufliegen, die dann den Europäern erklären, wie man gutes Design macht, erscheint ihm unangemessen.

Natürlich rührte er die Werbetrommel für seine euroGel, betonte aber auch, dass dies für ihn ein not-for-profit-Unternehmen sei. Wenn die Begeisterung gestern während der Videokonferenz sich eher in Grenzen zu halten schien, so täuschte dies - wie sich anschließend beim Bierchen zeigte, waren die meisten doch angefixt, und einige überlegen jetzt, wie sich eine Teilnahme doch noch ermöglichen lassen könnte :-) Also, vormerken: 1.9.2006, 8-18h, Kopenhagen (ggf. gibt es auch schon Veranstaltungen vom 31.8.). Von Hamburg kostet der Flug mit SAS hin und zurück 168€, die Teilnahme schlägt mit 500€ zu Buche.

Ach: auf der Charlie-Todd-Website "ImprovEverywhere" findet sich auch eine Beschreibung der Aktion "Look up more", wovon wir gestern leider nur einen Ausschnitt sehen konnten.

Auf der Suche nach dem optimalen Prototyping-Tool

Ein Diskussionsbeitrag bei OpenBC bringt mich dazu, meine Erfahrungen mit verschiedenen Prototyping-Tools und -Ansätzen einmal zusammenzufassen. Schließlich ist Prototyping ein zentrales Tätigkeitsfelder von Interaktionsdesignern, Information Architects und anderen Personen im Software-Entwicklungsprozess.

Wozu Prototyping?

Warum macht man sich die Mühe überhaupt? Der Sinn von Prototyping liegt darin, Verhalten von digitalen Artefakten zu simulieren, ohne dass tatsächlich Entwicklungsaufwände anfallen. Dahinter steht die Erkenntnis, dass Änderungen umso teurer werden, je später im Entwicklungsprozess sie realisiert werden - und jeder, der einmal in der Software-Entwicklung gearbeitet hat, weiß, dass Änderungen unumgänglich sind und sich fast zwangsläufig ergeben. Die Änderungswünsche ergeben sich i.d.R. dann, wenn man ein Design (egal, auf welcher Entwicklungsstufe) mit dem Projektteam durchspricht. Daraus lassen sich die Anforderungen an einen optimalen Prototyp ableiten:

• schnell (mit geringem Aufwand) zu erstellen
• leicht zu ändern
• nah an der späteren Realität
• kommunizierbar (d.h. in einem Dateiformat, das von den Mitgliedern des Projektteams zumindest geöffnet, besser auch annotiert werden kann)

Spätestens mit interaktiveren Produkten à la Web2.0 wird auch eine neue Denke beim Prototypenbau notwendig – das Denken in statischen Seiten ist nicht mehr zielführend, weil Seiten oder auch nur Elemente von Seiten je nach Systemzustand (z.B.: Nutzer ist unbekannt / bekannt, aber nicht angemeldet / authentifiziert) oder nach Nutzeraktion (Nutzer hat eine Aktion erfolgreich abgeschlossen / beim Ausführen einer Aktion ist ein Problem aufgetreten) ganz unterschiedlich aussehen können. Sinnvoll ist hier, das möglichst modulare Design, das später ja auch technologisch so realisiert wird, schon im Prototyping einzuführen. Dann hat man als Interaktionsdesigner alle Freiheiten, Module auf Ereignisse in anderen Moduln reagieren zu lassen oder unbeeinflusst weiter ihre Arbeit zu versehen. Daraus leitet sich ab: ein modulares Herangehen muss vom Tool unterstützt werden.

Arten von Prototyping

Je nach Aufgabenstellung unterscheidet man horizontale und vertikale Prototypen (immer unter der Voraussetzung, dass man über eine begrenzte Menge Zeit verfügt). Horizontale Prototypen bilden z.B. eine Website oder eine Anwendung in ihrer ganzen Breite ab, zeigen aber, wenn man in die Tiefe geht, praktisch keine Funktionalität. Vertikale Prototypen zeigen oft nur ganz grobe Illustrationen weiter Bereiche einer Site oder Anwendung, gehen aber in einem bestimmten Bereich sehr weit und sehr konkret in die Tiefe.

Wenn es z.B. darum geht, einen Prototypen zu erstellen für einen Usability Test einer bestimmten Funktion, so wird man einen vertikalen Prototyp bauen, der diese Funktion vollständig darstellt, und alle Randgebiete werden eher kursorisch dargestellt. Will man dagegen z.B. das Navigationsverhalten über die ganze Site erforschen, baut man eher einen horizontalen Prototypen mit sehr reduzierter Funktionalität in der Tiefe.

Grundsätzlich kann man Prototyping elektronisch oder auch mit Papier durchführen. Papierprototypen haben eine Reihe von Vorteilen - sie sind schnell erstellt, lassen sich häufig im Interview mit Testteilnehmern direkt ändern, und aufgrund ihrer gewollten Unfertigkeit laden sie dazu ein, sich spielerisch mit ihnen auseinander zu setzen. In sehr frühen Projektphasen sind sie außerordentlich hilfreich, gerade wenn man z.B. noch dabei ist, die Requirements festzuzurren. Ein großer Nachteil von Papierprototypen liegt aber darin, dass man wiederkehrende Module auch so häufig basteln muss, wie sie auftreten; und eine Weitergabe oder auch nur Dokumentation ist eher schwierig.

Elektronische Prototypen dagegen wirken häufig schon fertiger. Das kann sich auch als Nachteil erweisen, wenn es Testteilnehmer davon abhält, Änderungswünsche vorzubringen, weil sie glauben, eine Lösung sei schon weit fortgeschritten. Eine direkte Interaktion der Teilnehmer mit den Elementen der Prototypen ist auch nicht möglich. Dafür können Module (mehr oder weniger) realisiert werden, und die Weitergabe der Designs ans Projektteam und die Dokumentation funktionieren problemlos.

Auch HTML eignet sich sehr gut zum Erstellen von interaktiven Prototypen - wenn man entsprechend versiert ist und / oder über die richtigen Tools zur Bearbeitung verfügt. Ein schönes Beispiel dafür ist Adobe GoLive (ehemals GoLive Cyberstudio – those were the days …). GoLive ermöglicht das Arbeiten mit Objekten und wiederkehrenden Elementen, die außerhalb der Seite definiert werden können. Damit ist es auch schon relativ entwicklungs- und zielsystemnah. Ein Nachteil dieser Nähe kann darin liegen, dass der Prototyp dann als Ausgangspunkt für die Entwicklung des eigentlichen Systems herangezogen wird. Davon sollte unter allen Umständen abgesehen werden, sonst entsteht das, was Alan Cooper "Narbengewebe" nennt: Code, der nicht aus einem Guss ist, der wieder und wieder angepasst wurde und nicht mehr elegant und schon gar nicht mehr wartbar ist.

Auch, wenn man Tools wie Adobe GoLive (oder Dreamweaver) nicht zur Verfügung hat, kann man natürlich mit HTML Prototypen bauen – das ist dann aber entsprechend aufwändiger. Dann benötigt man entweder eine Umgebung, die mit Moduln umgehen kann (und ist dann eigentlich schon mitten in der Entwicklung), oder man baut hässliche Frickel-Lösungen mit Frames in Frames zusammen, um einzelne Seiten wie Module erscheinen zu lassen. Beides ist suboptimal für den Zweck, ein schnelles Prototyping zu ermöglichen.

Ich werde im folgenden nur auf die elektronischen Prototyping-Tools eingehen.

Prototyping mit elektronischen Tools

Microsoft PowerPoint

Das wahrscheinlich meist genutzte Prototyping-Tool ist Microsoft PowerPoint. Auf praktisch allen Büro-PCs installiert, bringt es den unschlagbaren Vorteil mit sich, dass alle einmal erstellte Prototypen einsehen können - aber auch Änderungen möglich sind. Das führt zu einem anderen Punkt: der Ownerschaft. Ein Prototyp muss einer Person gehören, und nur diese Person nimmt Änderungen am Prototyp vor. Auch, wenn das nach viel Last auf einer einzelnen Person klingt, kann nur so sichergestellt werden, dass der Prototyp in sich konsistent bleibt und den Diskussionsstand wiederspiegelt. (Ggf. kann hiervon eine Ausnahme gemacht werden, wenn sehr strikte Designrichtlinien gelten, diese allen beteiligten Personen bekannt sind und deren Einhaltung auch top-down eingefordert werden kann.)

PowerPoint ermöglicht ein schnelles Zusammenstecken von Elementen und ein sehr grobes erstes Elemente-Zurechtschieben. Elemente können auch miteinander verlinkt werden, so dass man Interaktivität zu einem gewissen Grad simulieren kann. Spätestens, wenn man aber mit einem ausgearbeiteten PowerPoint-Prototypen bei der Entwicklung war und einen ersten Blick auf ein mögliches Ergebnis bekommt, wird aber klar, warum PowerPoint zum Prototypenbau ungeeignet ist: die Maße stimmen hinten und vorne nicht. Auf einen 1024x768-Screen bekommt man deutlich mehr Inhalt, als auf einer PowerPoint-Folie darstellbar (und dann noch les- und bearbeitbar) ist. Außerdem verleitet PowerPoint durch seine Skalierungsfunktionen dazu, Elemente, die partout nicht passen, eben passend zu machen - nur dass dieser Screen dann eben nicht mehr realisierbar ist.

Ein weiterer eklatanter Nachteil von PowerPoint ist die fehlenden Modularisierbarkeit. PowerPoint kennt nur Copy & Paste - und wenn man einmal ein Element auf 40 Folien verteilt hat und es dann überall ändern und wieder ändern muss, merkt man, dass hier etwas Wichtiges vergessen wurde bzw. PowerPoint eben nicht das Tool der Wahl ist. Fazit: außer für ganz grobe Ideen-Visualierungen ungeeignet.


Denim

Denim ist ein innovatives Tool für frühe Stadien des Definitionsprozesses. Auf unterschiedlichen Detaillierungsebenen kann man Seiten und ihre Verlinkungen definieren, auch eine gewisse Interaktivität simulieren. Die Steuerung erfolgt über Gesten, gern auch unter Verwendung eines Grafiktabletts. Runde Kontextmenüs stellen eine schnelle Bedienung sicher. Das komplett in Java geschriebene Tool liegt für Mac OS X, andere *nixe und Windows vor. Leider hat es einen ganz gravierenden Nachteil: Es läuft nicht wirklich stabil. Darüber hinaus frisst es ab einer gewissen Datei- bzw. Website-Größe in ungeahnter Form Systemressourcen, und die eingebaute HTML-Export-Funktion funktioniert eben nur teilweise und produziert Code, der seltsamer Weise nur im Internet Explorer läuft. Ein Export nach PDF (oder auch nur ein ordentlicher Ausdruck) ist praktisch unmöglich. Daher: verspricht, ein sehr innovatives hervorragendes Tool zu werden, aber ist leider noch nicht fertig.


Apple Interface Builder

Wer die Developer Tools von Mac OS X zur Verfügung hat (d.h. jeder, der Original-Mac OS X-CDs besitzt), kann mit dem Interface Builder ganz hervorragende Simulationen von User Interfaces für Mac OS X erzeugen. Was heißt "Simulationen": das sind tatsächliche UIs, nur noch ohne Logik und Datenstrukturen. Vorbildlich eingearbeitet sind die Führungslinien, die sich automatisch zeigen, wenn man Elemente auf Fläche platzieren möchte, so dass die Platzierung mit der jeweils aktuellen Version der Apple Human Interface Guidelines übereinstimmt. Die Nachteile dieser Lösung liegen darin, dass sie nur fürs Applikations-Design gedacht ist (und nur das wirklich gut unterstützt), nur auf dem Mac läuft und lediglich in ein proprietäres .nib-Format sichern kann.


Microsoft Visio

Microsoft Visio ist eigentlich ein Tool zum Erstellen von Diagrammen aller Art. Für diese Aufgabe ist es hervorragend geeignet, und ich setze es auch für Flussdiagramme aller Art sehr gern ein. Gern wird Visio auch eingesetzt, um Screen-Designs zu konzipieren. Gegenüber PowerPoint hat es den Vorteil, dass die Darstellung viel realitätsnäher ausfällt und man ein Gefühl dafür entwickeln kann, wieviel Inhalt wirklich auf eine Seite passt. Ein modulares Arbeiten ist seit Visio 2003 möglich, indem man Dateien in Dateien platziert (siehe diesen sehr hilfreichen Artikel bei BoxesAndArrows). Auch die Stencils kann man nutzen für wiederkehrende Elemente. Leider verwendet Visio ein proprietäres Dateiformat und kann zwar in alle möglichen Zeichen- und Bildformate exportieren, aber richtig elegant wird es nicht. (Sinngemäß gilt dies auch für OmniGraffle von der Omni Group. Leider kann OmniGraffle aber keine anderen OmniGraffle-Dateien platzieren. OmniGraffle ist nur für den Mac verfügbar; Visio gibt es dafür nur für Windows.)


Adobe Photoshop

Die Königin der Bildbearbeitungsprogramme wird auch gern zu Prototyping-Zwecken eingesetzt. Durch die Möglichkeit, Elemente in Ebenen (und Ebenen in Koffern …) zusammenzufassen, kann hier auch eine gewisse Modularität simuliert werden. Allerdings verleiten die fantastischen Möglichkeiten von Photoshop doch dazu, den Prototyp grafisch weiter auszugestalten, als eigentlich notwendig ist. Am Ende steht dann ein schon recht fertiges Design, das dann aber nicht mehr schnell änderbar ist und u.U. Testteilnehmer beeindruckt bis einschüchtert, so dass sie ihre Kommentare nicht mehr abgeben, weil alles "so fertig" aussieht. Photoshop kann in eine große Anzahl von Formaten exportieren. Als nachteilig zeigt sich hier, dass die grafisch aufwändig gestalteten Interfaces häufig große Dateien verursachen, was den Austausch der Daten erschwert. Will man dann, um die Dateigröße zu verringern, auf gifs oder jpegs ausweichen, benötigt man wieder ein Tool wie PowerPoint, um eine Reihenfolge sicherzustellen und einen Zusammenhang zu stiften, oder man muss eine Namenskonvention für die Dateinamen einführen und einhalten. M.E. ist Photoshop daher zum Prototypen-Bau nur bedingt geeignet.


Adobe Illustrator

Wie in dem BoxesAndArrows-Artikel beschrieben, ist Adobe Illustrator neben Visio das einzige Grafik-Programm, das in der Lage ist, ein modulares Prototyping zu unterstützen. Elemente baut man in Dateien, die man dann (als PDFs) in anderen Dateien platziert. Ändert man dann etwas an den Elementen, spiegeln sich diese Änderungen im Handumdrehen in den Hauptdateien wieder. Fertige Stände können nach PDF exportiert werden; der Adobe Reader dürfte inzwischen auch auf praktisch allen Systemen als installiert vorausgesetzt werden. Hat man dann noch den Acrobat zur Verfügung, kann man zum einen die Seiten zusammenbauen zu zusammenhängenden Präsentationen, zum anderen – wenn man genug Zeit hat – auch Verlinkungen einbauen, so dass eine gewisse Interaktivität simuliert werden kann. Ein Nachteil bei Illustrator liegt nach wie vor (auch in der CS2-Version) darin, dass es von Haus aus nicht mit mehrseitigen Dokumenten umgehen kann (Freehand hatte dieses Feature schon ... ich weiß es nicht mehr). Hier schafft das PlugIn MultiPage von HotDoor Abhilfe. So wird es dann möglich, komplette Sets von Views in einer Datei zusammenzuhalten, die Module auszulagern und einzeln zu pflegen und dann mit Acrobat die Exporte zu optimieren. Wenn man dann noch InDesign zur Verfügung hat, kann man die fertigen Views (oder auch die Module) auch in InDesign platzieren und die Design-Kommentare direkt dort vornehmen – so wird die Wertschöpfungskette von Prototyping bis Design-Dokumentation versorgt. Nachteilig an Illustrator ist sicherlich die Einarbeitungszeit, die man benötigt, wenn man sich ein vektorbasiertes Zeichenprogramm dieser Komplexität aneignen möchte.


Axure RP

Axure RP Pro 4 verspricht, ein sehr interessantes Tool zu sein – inkl. Integration in Word und HTML-Export. Da ich noch nicht damit gearbeitet habe, kann ich noch keine Aussage zu seiner Eignung treffen. Ich werde es mir dieser Tage einmal ansehen und dann entsprechend berichten.


Fazit

Meine persönlich produktivste Prototyping-Umgebung stellt zurzeit Adobe Illustrator dar, ggf. in Kombination mit Acrobat: Schnell, nah genug, aber nicht zu nah am Endergebnis, modular (d.h. unterstützt schnelle Änderungen), exportiert in ein allgemein verständliches Format (PDF), das – entsprechende Tools wie z.B. Acrobat Elements vorausgesetzt - auch annotiert werden kann. Dadurch, dass Illustrator-Lizenzen nicht mit jedem Büro-PC ausgegeben werden, ist auch sichergestellt, dass die Ownerschaft des Prototypen bei einer überschaubaren Anzahl von Menschen bleibt, bei denen die Fäden zusammenlaufen.