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

37signals hat eine neue Version von Backpack veröffentlicht (Preview-Artikel 1, 2, 3) und es gibt fünf Dinge, die man aus Interface- und Konzept-Sicht einmal bewusst wahrgenommen haben sollte:

Der (neue) "Blank Slate"

Blank Slate nennt 37signals in ihrem Buch den Zustand einer Seite, in dem noch keine Informationen eingetragen wurden. In der Vergangenheit, haben sie häufig mit Demo-Content als Screenshot gearbeitet, jetzt wird — grafisch schön oder zumindest auffällig umgesetzt — auf die Neues-Element-Links hingewiesen.

(aus dem Video MOV)

In dem älteren Hilfe-Video über Tags (MOV) sieht man, wie diese Funktion vorher gelöst war:

Das verbesserte und erweiterte Drag & Drop

Man kann Seitenelemente jetzt per Drag & Drop auf der Seite aber auch zwischen Seiten und in neue Seiten verschieben. Das Interaktionsverhalten ist dabei sehr gut im Detail umgesetzt: Die Bewegung des markierten Elements, das Highlighting der Zielseite, der Hilfetext OnMouseOver, der Ladebalken beim Verschieben, …

Besser als der Screenshot, ist das Video (MOV):

Die optimierte "Give this page a name"-Funktion (neue Seite)

Typisch für 37signals und ihr Bestreben, die Arbeit so einfach wie möglich zu machen, ist das Verhalten beim Erstellen einer neuen Seite: Der Title ist direkt im Edit-Modus, es gibt kein eigenes Label sonder der Inhalt dient als Beschreibung, ist aber direkt markiert, so dass man direkt seinen Titel eintippen kann und mit Enter die Erstellung abschließt.
Genau das meint Raskin, wenn er in seinem Buch von der Minimierung von Interaktionsschritten spricht (Stichwort KLM).

(auch aus dem Video)

Die richtig versteckten Funktionen Edit, Move, Delete und Rename

Nicht wirklich neu aber gut gemacht: Basecamp versteckt die Bearbeiten-Funktionen für seine Seiten-Elemente so lange, bis der Benutzer mit der Maus über ein Element fährt.

Sehr gut sieht man das in dem Demo-Video (MOV) über das Verschieben.

Der große Vorteil: Die Backpack-Seiten sind im Standard-Zustand sehr übersichtlich, es kann auf eine eigene Admin-Umgebung verzichtet werden (getreu dem Motto "one interface") und der Benutzer muss nur eine Interaktionsmetapher lernen: Die bearbeiten-Funktionen im Content-Bereich stehen onmouseover links neben der Überschrift.

Einziger Schönheitsfehler: Die Funktionen sollten meine Meinung nach auch dann erscheinen, wenn man mit der Maus links von der Überschrift ist. Im Video sieht man, dass bei vielen Verschiebe-Aktionen, ständig die ungewohnte Umweg-Bewegung über die Überschrift gemacht werden musste.

Das Thema OpenID und Open Bar

Dem Thema sollte man eigentlich einen ganzen Post widmen, weil 37signals mit ihrer OpenBar eine gute und sehr schön anschaulich-praktische Integration von openID umgesetzt haben. Kurz gesagt: Sie nutzen openID als (externe) single-sign-on-Lösung für ihre Produkte und beginnen ihre bis dahin mäßig vernetzen Einzelprodukte über die OpenBar zu verknüpfen.

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? ;-)

Nach dem Artikel "Jugend: lerne schreiben", setzte ich die Reihe heute mit einem Zitat aus dem "A List Apart"-Artikel "Calling All Designers: Learn to Write!" fort :-)

User experience isn't just visual design
It's time we designers stop thinking of ourselves as merely pixel people, and start thinking of ourselves as the creators of experiences. And when it comes to experience on the web, there's no better way to create it than to write, and write well. …

Ein lesenswerter Artikel den Derek Powazek geschrieben hat. Er hat absolut Recht und befindet sich in guter Gesellschaft mit diesen Aussagen.

Zuletzt ist mir bei der Diplomrechere in dem Buch "Design for Community" (wie ich gerade feststelle von Derek geschrieben) erneut ein Kapitel aufgefallen. Zusammengefasst heißt es dort:

Der Ton ist ein zentrales Gestaltungselement einer Webcommunity. Wie man die Leute begrüßt, wie man die Willkommensemail formuliert,… prägt die Stimmung der Gemeinschaft.
Corporate Communication aus Webcommunity-Sicht.

Oder nehmen wir das Kapitel "Copywriting is Interface Design" aus dem Getting-Real-Buch

Copywriting is interface design. Great interfaces are written.
If you think every pixel, every icon, every typeface matters,
then you also need to believe every letter matters. (…)

Do you label a button Submit or Save or Update or New or
Create? That's copywriting. Do you write three sentences or
five? (…) All of this matters.

Zu guter letzt scheibt Eric Karjaluoto schon vor ein paar Wochen "Designers must write"

I believe that my true job description would begin with this phrase, "Write and respond to email." That's what I do all day. I send notes to designers, clients, and suppliers, and then I task manage the fallout from these messages. (…) You guessed it, my email application. Although I may not open Photoshop on a given day, my email application is never inactive.

Fazit: Kern der Designkompetenz ist sicher Probleme zu definieren und sie zu visualisieren. Dabei darf jedoch eines nicht vergessen werden — und das wollen all diese Artikel aus ganz unterschiedlichen Blickwinkeln sagen:

Auch visuelle Kommunikation kommt fast nie ohne Wort aus. Wir reduzieren sie häufig (und hoffentlich) auf ein Minimum und geben Ihnen damit gleichzeitig eine ganz besondere Bedeutung. Also müssen die paar Worte, die übrig bleiben, perfekt sein…

[tag]schreiben, fh, design, interfacedesign, lernen[/tag]