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

Alle Funken für das Thema 37signals:

Mit Nebenprodukten Geld verdienen

In klassischen Berufen werden schon seit langem Nebenprodukte weitervermarktet und zu Produkten gemacht um sie zu verkaufen.

Jason Fried von 37signals fragt in seinem Vortrag auf der Konferenz fowa (und jetzt auch in seinem Weblog), warum Firmen mit digitalen Produkten nicht ebenfalls gezielt ihre Nebenprodukte vermarkten und verkaufen.

Aus seinem Vortrag:

Beispiel Holzindustrie: Die Holzindustrie hat anfangs nur Holz geschlagen um Häuser zu bauen, später dann das Sägemehl etc. als Produkte zusätzlich verkauft.

Beispiel 37signals selbst: Anfangs haben sie nur ihre Webapps entwickelt. Das Nebenprodukt war Wissen, das sie jetzt vermarkten und Ruby on Rails. Dann haben sie gebloggt, das Nebenprodukt waren ihre Bücher, die daraus entstanden sind. Ebenso ihre Workshops, mit denen sie ihre Konferenzvorträge auf Nebenproduktniveau gehoben haben.

Beispiel Kochbücher: Ein Sternekoch schreibt auch ein Buch über seine Arbeit ohne Angst zu haben, dass andere ihm seine Arbeit klauen und ein Sternerestaurant nebenan aufmachen… — genauso sehen sie es.

Plausible Gedanken und gute Vergleiche mit alten und bekannten Geschäftsmodellen.


Jason Fried Talk FOWA Maimi from Carsonified on Vimeo.

Wie immer sind die Kommentare und dort genannten Beispiele von Lesern des oben verlinkten signal-vs-noise-Blogs auch lesenswert. Wer statt dessen Jason noch länger zusehen und hören möchte: Es gibt ein 2. Video mit dem Fragen-Antwort-Teil. In diesen letzten 15 Minuten geht Jason noch auf andere Themen ein.

gutes und schlechtes vom iPhone-Interface

Gut: Jason von 37signals beschreibt ein nettes Feature vom iPhone: „iPhone tells you where someone is calling from".
In der Call-History kann man irgend etwas machen um die Vorwahl in den eigentlichen Namen der Stadt/Region übersetzen zu lassen. Klingt praktisch!

iphone vorwahl übersetzen

Schlecht: shofr stößt die alte Diskussion an, bis zu welchem Grad ein Interface konsistent sein muss. Oder gilt eher, dass man den konkreten Screen optimiert?
Im Gegensatz zu den ersten beiden bashing-like Kommentaren kann ich shofrs Position nachvollziehen. Ob jedoch die Schwelle zwischen Konsistenz und „Optimierung im Detail" wirklich schlecht gewählt wurde, kann ich ohne iPhone-Test nicht sagen.

iphone button-inkonsistenz

Gibt es weitere iPhone-Interface/-UserExperience-Artikel, die man kennen sollte?

[tags]iphone, apple, interfacedesign, userexperience, 37signals, mobile, mobil[/tags]

5 interessante Interfaceschnipsel aus dem neuen Backpack

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.

backpack drop page
(aus dem Video MOV)

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

backpack new-links

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):

backpack drag and drop

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).

backpack page title
(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.

backpack move

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.

[tags]37signals, raskin, openid, interaktion, drag-and-drop, webapplikation, interfacedesign, continuity,klm, blank-slate [/tags]

Warum verstecken wir alle den Datepicker?

Ich fühle mich schon ein bisschen vorgeführt, wenn ich im 37signals-Produktblog eine so einfache und bisher unerreicht schnelle Lösung für das schnelle Eingeben von Datumwerten sehe:

Den Datepicker-Kalender einfach nicht verstecken sondern immer anzeigen… — genial einfach :-).

datumsauswahl in basecamp

Warum sieht man das eigentlich zum ersten Mal? Sicher auch, weil kaum ein Interface so reduziert konzipiert wird, wie bei 37signals. Dann kann man es sich auch mal leisten, für eines der wichtigen Formularelemente etwas mehr Platz zu nutzen.

Nebenbei: Meine eigenen Ideen mit JavaScript-Spielchen die textbasierte Eingabe zu beschleunigen, habe ich leider immernoch nirgends umgesetzt zu sehen. Das wäre im Übrigen auch der wichtige Verbesserungsschritt, den ich jetzt im Basecamp-Interface sehe: Den „Due: June 12, 2007"-Text durch ein Inputfeld zu ersetzen, in dass man auch per Hand Daten reinschreiben/-pasten kann.

Und wenn man dafür keinen Platz hat?

Auch dann kann man die Klick-Arbeit und -Zeit noch reduzieren. Yahoo hat nämlich ebenfalls mit einer Quasi-Konvention gebrochen und zeigt die Datumsauswahl nicht „OnClick auf Button" sondern „OnFocus in Textfeld" an. Wieder einen Klick und damit 10.000 $ pro Jahr gespart, wie Jacob Nielsen sagen würde ;-).

datepicker bei yahoo yui

Im Übrigen ist der Yahoo-Kalender auch sonst sehr gut optimiert und damit sogar dem OpenSource-Quasi-Standard vorzuziehen.

PS: Zum Schluss noch etwas Visuelles und Technisches für Interessierte.

[tags]javascript, gui, benutzereingabe, datum, interaktion, interfacedesign, optimierung, 37signals[/tags]

37signals stellt Highrise vor

Update 07-03-20: Highrise wurde heute freigeschaltet — bisher ohne Erwähnung im svn-Blog, dafür aber mit just-in-time-Kundenservice.
Es lohnt sich, die Highrise-Webiste anzuschauen. Neu im Vergleich zu den bisherigen 37signals-Produkten sind die Scenarien/Beispiele, der ausführliche FAQ-Bereich und das direkt zentral verlinkte Forum. Offensichtlich will 37signals die Zahl der Kunden-Rückfragen so gering wie möglich halten (trotzdem der Hilfe-eMail-Link auf der Startseite).
Wem die Screenshots aus der Tour nicht ausreichen, dem empfehle ich die Highrise-Screenshotssammlung bei Flickr.

Seit ein paar Wochen stellen die Jungs von 37signals getreu ihrer Philosophie „Hollywood Launch" ihre neuste Software Highrise vor. Es geht um ein Tool zur Verwaltung von Kontakten und allem, was an Wissen mit ihnen verbunden ist.

Die Preview-Artikel sind nicht lang und empfehlen sich zu lesen aus Sicht des Interface-Design, des Applikations-Konzepts und auch im Vergleich zum oben erwähnten Getting-Real-Buch.

Sehr schön beispielsweise die Interface-Lösung für die Zuweisung von Rechten in Preview 2.

Screen aus Preview 4:
highrise

Paper Prototyping-Artikelsammlung

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.

alistapart.com/articles/paperprototypingPaper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces
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? ;-)

„Scrum" für bessere Softwareprojekte

Dieser Google Tech Talks „Scrum" vom 5. September lag jetzt lange auf meinem Desktop — zu Recht, denn er ist sehr gut.

Worum es geht, beschreibt Google und Ken Schwaber besser selbst:

Scrum is an amazingly simple process that causes many, many changes when it is implemented. This seminar presents the basic framework of Scrum and some of the implementation issues associated with it.

Ken Schwaber co-developed the Agile process, Scrum. He is a founder of the Agile Alliance and Scrum Alliance, and signatory to the Agile Manifesto. Ken has been a software developer for over thirty years. He is an active advocate and evangelist for Agile processes.

Angenehm finde ich, dass Schwaber zu Beginn in seiner kleinen Historie klar formuliert, woher dieses Methodenset kommt und Credits ausspricht, wo er kann. Im Gegensatz zum Beispiel zu 37signals deren Ideen ich an einigen Stellen des Videos wiederfinde, die aber kaum auf Inspirationsquellen verweisen.

[tag]video,elearning,organisation,beruf,projektmanagement,management,37signals,google,agile[/tag]