Archive for September 2006

h1

XING Handzeichen – jetzt haben auch wir Menschen unser Erkennungszeichen

28. September 2006

Vulkanier

Menschen

xing1 xing2 Nachdem wir von Mister Spock Wissen, welches das Handzeichen der Vulkanier ist (\ || || – siehe Foto links), haben wir Menschen nun auch endlich unser eigenes Erkennungszeichen (X).
Gratuliere Lars, tolles Video!!
Are you XING?

xing3

Advertisements
h1

Teil 3 – Zusammenfassung: GETTING REAL von 37signals – Tipps/Ideen/Trends

25. September 2006

Teil 1 der ZusammenfassungTeil 2 der Zusammenfassung

Nachdem ich im Teil 1 die Themen „Die Startlinie“, „Schlank bleiben“ und „Prioritäten“ und Teil 2 die Themen „Selektion der Funktionalitäten“, „Prozesse“, „Organisation“ und die „Stellenbesetzung“ zusammengefasst und ergänzt habe, geht es nun im Teil 3 um „Interface Design“, „Code“, „Worte“, „Preise und Anmeldungen“, „Promotion“, „Support“ und die „Nach der Einführung“. Somit bin ich tatsächlich in 3 Teilen mit der Zusammenfassung durchgekommen.

Eventuell werde ich dann noch einen weiteren Artikel bloggen, der die 3 Teile wieder zusammenfasst – die Zusammenfassung, der Zusammenfassung.

Inzwischen hatte ich etliche Diskussionen zum Thema „Getting Real“ – vor allem wie realistisch die Konzepte in diversen Situation anwendbar sind. Vielleicht erstelle ich Präsentation der Highlights – wäre doch ein spannender Vortrag!?

IF YOU WOULD LIKE AN ENGLISH TRANSLATED VERSION OF THIS SUMMARY – LET ME KNOW

Also, auf ein letztes Mal zum Thema „Getting Real“. Wiederum möglichst kurz & knapp und doch anregend genug, um auch wirklich auszuprobieren und/oder anzuwenden.

Interface Design

  • INTERFACE FIRST – Designe zuerst das Benutzerinterface, bevor du mit dem Programmieren startest. Das Programmieren ist nicht die schwierigste Aufgabe, jedoch die teuerste und am schwierigsten zu ändern. Zudem ist das Benutzerinterface das Produkt – das was du dem Benutzer verkaufst. Ein bestehendes Benutzerinterface motiviert auch die Mitarbeiter, weil sie sehen wohin die Reise geht. Dabei hilft dies auch zur Aufwandschätzung und beim Entscheid der geeigneten Architektur und den zu verwendenden Technologien.
  • EPICENTER DESIGN – Starte mit dem Herz des Benutzerinterfaces – ignoriere die Extremitäten wie Navigation, Kopf- und Fusszeile, Logo, etc und fokussieren dich auf den eigentlichen Inhalt. Dies hilft auch den Dialog zwischen Designer und Programmierer zu fördern und diese auf den Hauptteil zu fokussieren.
  • THREE STATE SOLUTION – Beachte nicht nur den Normalbetrieb, sondern achte auf das Verhalten der Applikation im Falle eines Fehlers und vor allem auch wie die Applikation aussieht, wenn sie noch keine Daten enthält. Am Anfang hat die Applikation keine Daten und so wird der Benutzer seine ersten Erfahrungen sammeln – also wenn deine Applikation „leer“ nicht toll aussieht, dann wird der Benutzer diese auch nicht toll finden. Am Anfang können dabei auch Wizards, Tutorials, Hilfstexte, Beispiel Screenshots, Erklärungen oder vorabgefüllte Beispieldaten helfen. Überleg dir welche Fragen der Benutzer am Anfang hat und beantworte diese.
  • GET DEFENSIVE – Baue deine Applikation auch für den Fall das Etwas schief geht – wenn etwas schief gehen kann, dann geht es schief 😉
  • CONTEXT OVER CONSISTENCY – Es ist wichtiger im richtigen Kontext zu sein, als „nur“ konsistent zu sein. Das heisst sich zu überlegen, was für Elemente, Texte, etc. in den verschiedenen Situationen Sinn machen und nicht nur aus Prinzip überall das Gleiche zu machen. Gib und zeig dem Benutzer was er gerade braucht.
  • COPYWRITING IS INTERFACE DESIGN – Es kommt auf jeden Buchstaben an. Sprich die Sprache deiner Benutzer. Formuliere dich kurz und präzise. Gutes Schreiben ist gutes Design.
  • ONE INTERFACE – Baue administrative Funktionen ins allgemeine Benutzerinterface ein. Kein separater Administrationsbereich. Zwei Benutzerinterfaces zu warten ist aufwendig und das Eine oder Andere wird darunter leiden. So weniger Screens, umso besser. Nicht zu viele Aktionen auf einer Seite. Verstecke Funktionen (wie Administrationsaufgaben) oder mach diese kleiner. Stell in den Vordergrund, was der Benutzer regelmässig braucht.

Code

  • LESS SOFTWARE – Weniger Software ist mehr. Halte deinen Code so einfach als möglich. Die Komplexität steigt mit der Menge Code exponentiell. Jede Änderung hat kaskadierende Folgen. Wiederum gilt 80/20 mit 20% Aufwand 80% des Problems lösen. Versuche nicht die Zukunft zu lesen, sondern löse die Probleme von heute – etwas philosophisch, doch durchaus anwendbar im Falle von Softwareentwicklung. Vorausschauen kann nicht Schaden, doch sich einfach nicht verrückt machen lassen. Eine Gute Idee ist auch die Programmierer ein Gegenangebot machen zu lassen – die Umsetzung deines Vorschlags dauert 3 Tage und ich hätte eine Idee das Problem in einem Tag zu lösen (80/20).
  • OPTIMIZE FOR HAPPINESS – Wähle Werkzeuge, die dein Team motivieren und mit denen sie gerne arbeiten. Glückliche Mitarbeiter machen die richtigen Sachen.
  • CODE SPEAKS – Wenn es zu lange dauert etwas zu implementieren, dann gibt es wahrscheinlich einen Weg es einfacher zu lösen. Vielleicht entspricht die einfachere und kürzere Lösung nicht 100% der Originalanforderung, doch wiederum gilt 80/20. Höre auf deine Programmierer und nimm ihre Bedenken ernst (gilt nicht nur für Programmierer!). Gib Ihnen Zeit ein „wirkliches“ Problem zu lösen.
  • OPEN DOORS – Verteile Informationen in die weite Welt und „öffne“ den Zugang zu deiner Applikation – Stichwort RSS, API. RSS Feeds eignen sich Kunden zu informieren, ohne dass diese deine Seite besuchen müssen. APIs geben Anderen die Gelegenheit deine Applikation zu erweitern – oft sind diese Add-ons sehr wertvoll.
  • MANAGE DEPT – Obwohl du schnell zu einer Umsetzung kommen solltest darfst du deine Altlasten/Schulden nicht vergessen. Von Zeit zu Zeit muss der Code gewartet werden und Schulden abgebaut werden. Plane für diese Aktivitäten auch Zeit ein.

Words / „Worte“

  • THERE’S NOTHING FUNCTIONAL ABOUT A FUNCTIONAL SPEC – Schreibe keine funktionale Spezifikation, denn es sind Fantasien. Alle fühlen sich mit einbezogen, doch helfen tut es nicht. Bin nicht ganz gleicher Meinung. Einverstanden, dass dies für ein „kleines“ Team funktioniert und solange kein Auftragsverhältnis besteht. In grösseren Firmen müssen unbedingt diverse Teams/Einheiten miteinbezogen werden – und wenn die Spec an sich nicht viel bringt, dann hilft es wenigstens den Dialog zu fördern – ein grosse Herausforderung für viele grossen Firmen. Oft wird sich diese durch diesen Prozess bewusst, wie uneinig sich die verschiedenen Einheiten sind und die grossen Differenzen können angegangen werden. Ebenfalls bin ich der Meinung das komplexe Anforderungen spezifiziert werden sollen. Zudem wird anhand der Spec der Testplan erstellt. Ohne dokumentierte Anforderungen, kein vernünftiges Testkonzept. Funktionale Specs zwingen uns Entscheidungen zu treffen, die in diesem frühen Stadium Mangels Informationen noch gar nicht getroffen werden können. Auch hier bin ich nicht gleicher Meinung. Spezifiziere was sich spezifizieren lässt – unklare Punkte oder solche die mehr Informationen brauchen einfach offen lassen und zu gegebener Zeit entscheiden (oder in SCRUM-Sprache: in einem nächsten Sprint). Klar gibt es bei Specs immer wieder Änderungen, doch diese können mit einem Änderungsprozess definiert werden, der garantiert, dass das Ganze nicht aus dem Ruder läuft. Ich glaube bei diesem Punkte sehen die 37signalers das Leben ein bisschen zu einfach… Hingegen finde ich die Idee mit der „Ein-Seiten Spec“ sehr gut – eine Seite die kurz und bündig das Projekt umschreibt.
  • DON’T DO DEAD DOCUMENTS – Eliminiere unnötige Papierarbeit – eigentlich klar, denn eigentlich sollte ja gar nix unnötiges kreiert werden – somit muss auch nix eliminiert werden 😉
  • TELL ME A QUICK STORY – Schreibe eine Geschichte und verliere dich nicht in Details
  • USE REAL WORDS – Arbeite immer mit „echten“ Texten und nicht mit Platzhalter. Echte Texte zeigen dir wie gross ein Feld sein muss, wie Tabellen sich verändern und wie deine Applikation wirklich aussieht.
  • PERSONIFY YOUR PRODUCT – Personifiziere dein Produkt und stell dir vor es sei eine Person, die 24 Stunden am Tag mit dem Benutzer spricht.

Pricing and Signup / „Bepreisung und Registration“

  • FREE SAMPLES – Gib etwas gratis ab. Zum Beispiel ein Teil deiner Software – eine Light Version.
  • EASY ON, EASY OFF – Der Registrationsprozess sollte möglichst einfach sein (evtl. Demoversion ohne Kreditkarten Informationen). Falls sich ein Benutzer abmelden möchte, dann mach ihm/ihr das Leben nicht unnötig schwer, sondern gestalte auch diesen Prozess möglichst einfach. Erlaube es solchen Benutzern auch ihre Daten mitzunehmen.
  • SILLY RABBIT, TRICKS ARE FOR KIDS – Vermeide längere und/oder bindende Verträge. Versuche nicht durch einen Trick mehr Geld zu bekommen, sondern verdiene dein Geld.
  • A SOFTER BULLET – Vorab über schlechte Nachrichten für den Nutzer informieren (z.B. Preiserhöhung) und Gnadenfrist einplanen.

Promotion / „Werbung“

  • HOLLYWOOD LAUNCH – Lanciere deine Applikationen mit einem Hype. Erst ein Teaser (ein paar Hinweise, Logo und E-Mail Adressen sammeln), dann eine Vorabversion (erster Einblick in Funktionalitäten, ein Blick hinter die Bühne, Betatesters identifizieren) und dann die offizielle Lancierung. Und dann vor allem Momentum beibehalten – immer wieder etwas Neues.
  • A POWERFUL PROMO SITE – Baue eine Werbeseite, die das Produkt den Benutzern präsentiert – Guided Tour, Screenshot, Case Studies, Testimonial, Forum, Blog (siehe auch nächster Punkt), etc.
  • RIDE THE BLOG WAVE- Bloggen kann effektiver sein als Werbung und es ist vor allem günstiger!
  • SOLICIT EARLY – Früh anfangen E-Mail Adressen von Interessierten sammeln, die dann bei der Lancierung gleich informiert werden können.
  • PROMOTE THROUGH EDUCATION – Teile dein Wissen mit der Welt. Leute die du ausbildest werden deine Evangelisten. Tipps & Tricks aufschalten und an Konferenzen teilnehmen. Interviews geben und Artikel für Magazine oder ein Buch schreiben. Lehren erhöht Karma und zahlt sich für die Zukunft aus. „Talking leads to Passion“ – Kathy Sierra
  • FEATURE FOOD – Neue Funktionen sind eine gute Gelegenheit um Begeisterung und/oder Aufmerksamkeit zu erzeugen. Interessensgruppen lieben es über neue Funktionen zu debattieren und schreiben.
  • TRACK YOUR LOGS – Du musst deine Benutzer kennen und solltest Wissen wer wie über dich und deine Applikation spricht. Kommentiere Blogeinträge und Bedanke dich für Kommentare in deinem Blog. Auch auf negative Kritik reagieren ist wertvoll.
  • INLINE UPSELL – Mach Werbung in deiner Applikation für Upgrades und mache es dem Benutzer möglichst einfach auf eine teurere Version deiner Applikation umzuschalten. Existierende Kunden eignen sich sehr gut um weitere Verkäufe zu machen – nicht scheu sein.
  • NAME HOOK – Gib deiner Applikation einen Namen, der sich einfach merken lässt. Nicht ewig suchen und überlegen, sondern einen einfachen, kurzen, einprägsamen Namen wählen und loslassen.

Support

  • FEEL THE PAIN – Mauern/Hürden zwischen Support und Entwicklung entfernen. Diese sollen voneinander Wissen und Lernen. Kundensupport nicht auslagern. Und falls trotzdem nötig, möglichst für einen regen Austausch sorgen.
  • ZERO TRAINING – Baue die Hilfe und Fragen und Antworten gerade in das Produkt mit ein. Die Applikation sollte falls möglich kein Benutzerhandbuch und keine Schulung brauchen (ausser du willst mit Schulung Geld verdienen ;-)).
  • ANSWER QUICK – Supportanfragen sofort beantworten. Somit kannst du dich von Mitbewerbern differenzieren. Auch wenn die Antwort noch nicht perfekt ist – sag etwas.
  • TOUGH LOVE – Sei bereit Nein zu sagen. Nein zu neuen Anforderungen. Als Entwicklungsfirma muss man sein Produkt mögen und wenn man etwas mag füllt man es nicht mit Müll 🙂
  • IN FINE FORUM – Stelle ein Forum und/oder einen Chat zur Verfügung, damit sich die Benutzer gegenseitig helfen können.
  • PUBLICIZE YOUR SCREWUPS – Schlechte Nachrichten sofort mitteilen. Gute Nachrichten dürfen sich hingegen gerne in die Länge ziehen. Eine gute Stimmung kann man künstlich verlängern.

POST-LAUNCH / „Nach der Lancierung“

  • ONE MONTH TUNEUP – 30 Tage nach der Lancierung am Besten einen grösseren Update machen. Dies zeigt Momentum und dass du deinen Benutzern zuhören kannst. Diese Strategie erlaubt es auch, sich bei der Lancierung um das Wesentlichste zu kümmern und das weniger Wichtige dann im Update nachzuschieben.
  • KEEP THE POST COMING – Zeig das dein Produkt lebt z.B. mit einem Entwicklerblog. Zudem erlaubt ein Blog sich menschlich zu zeigen – die Köpfe hinter der Applikation und ihre Meinungen. Im Blog können auch Fragen & Antworten, Tipps & Tricks, usw. gepostet werden.
  • BETTER, NOT BETA – Lass das „Beta“ sein. Beta sagt, dass du eigentlich noch nicht bereit bist und entschuldigt im Vornherein für alle Fehler – will das der Benutzer? Private Betas sind ok, öffentliche Unsinn. Zeige Verantwortung für das was du lancierst. Google ist schuld 😉
  • ALL BUGS ARE NOT CREATED EQUAL – Priorisiere Fehler und ignoriere vor allem auch Unkritische. Jede Software hat Fehler. Sei jedoch ehrlich betreffend den Fehlern.
  • RIDE OUT THE STORM – „When you rock the boat, there will be waves“. Wo man sich bewegt gibt es auch Wellen. Nach einer Lancierung braucht es Geduld, ruhig sitzen bleiben, zuschauen, die Wellen etwas glätten lassen und dann agieren. Negative Reaktionen sind oft lauter als positive – das heisst aber nicht, dass du gleich reagieren musst. Die Masse liebt vielleicht deine Änderung, bleibt aber ruhig…
  • KEEP UP WITH THE JONESES – Informiere dich über deine Mitbewerber. In der Hitze des Gefechtes wird dieser Punkt oft vernachlässigt. Nicht nur du musst Wissen was deine Mitbewerber macht, sondern deine Partner/Kunden wollen es auch Wissen.
  • BEWARE THE BLOAT MONSTER  – Durchdachter und reifer heisst nicht nur Wachstum und komplizierter. Nicht nur wachsen um des Wachsens willen. Desktop Software muss immer wieder neue Funktionen haben, damit sich neue Versionen verkaufen lassen – nicht so bei Web-Applikationen. Ausser Desktop Software wird mit einem anderen Lizenzmodel vertrieben (z.B. wiederkehrende Lizenzgebühren).
  • GO WITH THE FLOW – Sei offen für Veränderungen und bereit neue Pfade zu verfolgen. Halte Ausblick nach den grössten Wellen und reite diese. Ja, Lance – ride the wave 😉

Also los, es war noch nie so einfach & günstig Ideen umzusetzen. Mit der richtigen Idee, der Leidenschaft, etwas Zeit, den richtigen Fähigkeiten und vor allem den richtigen Leuten steht dir nichts mehr im Wege! Nutze die Chance – lass mich Wissen, falls du etwas auf die Beine stellen willst – helfe gerne wo ich kann… Der Erfolg wird abhängig von einer exzellenten Umsetzung sein – die Idee ist das Eine, die richtige Umsetzung das Andere (und noch viel Wichtigere!). Such dazu Leute die die Leidenschaft mit dir teilen. Die richtigen Leute werden den Erfolg ausmachen!!!

Teil 1 der ZusammenfassungTeil 2 der Zusammenfassung

h1

ResizR – eine Erfolgsgeschichte!

21. September 2006

resizrLord Lance hat am 09.09.06 eine kleine, nette Applikation ins Netz gestellt, die es erlaubt ein lokales Bild oder ein Bild aus dem Internet zu verkleinern oder zu vergrössern – der ResizR. Die Software an sich ist sehr sehr sehr klein und überhaupt nicht aufwendig – der grösste Aufwand war das Design des Benutzerinterfaces. In ein paar Nachtschichten als Betatester und Ideen-Challenger habe ich die (kurze!) Entwicklung hautnah miterlebt. Die Idee war dem Benutzer eine einfache und alltägliche Funktion zur Verfügung zu stellen und siehe da – das Teil geht ab wie blöd – über 8’000 Visits im Tag – auf der Titelseite von Digg – in den Topeinträgen von Delicous und Technorati. Lance hat den Besucheransturm dokumentiert [1] [2]. Gratulation! Eine Paradebeispiel für Web 2.0 und den viralen Effekt – Wahnsinn! Faszinierend wie einfach es eigentlich ist eine grosse Masse zu begeistern und die entsprechende Aufmerksamkeit zu generieren. Eine gute Idee und eine entsprechende Disziplin und Effizienz beim Ausführen – siehe auch Getting Real (Prozesse – Done).

h1

Microsoft Profitabilität – Das sollte man sich leisten können ;-)

14. September 2006

microsoft-profit

h1

Jemanden von seiner Idee überzeugen – Vorsprechen bei Venture Capitalists

11. September 2006

Heidi Rozen (Mobius Venture Capital) erklärt in 3 min. 39 sec. auf was man achten soll, wenn man jemanden (in ihrem Beispiel ein Venture Capitalist) von seiner Idee überzeugen will:

  • Glaubwürdigkeit aufbauen – früher hatte ich und heute tue ich. Der Zuhörer muss einen logischen Zusammenhang sehen zwischen dem was man gemacht hat und wo man Erfahrungen gesammelt hat und dem was man heute verkaufen will.
  • Die Idee verständlich rüberbringen – ein Mehrwert muss klar ersichtlich und für alle verständlich sein (Achtung: Wer sind meine Zuhörer?).
  • In Kürze die Idee auf den Punkt bringen – Oft bleibt nicht viel Zeit. Üben die Idee innert kürzester Zeit klar zu formulieren (elevator pitch). Falls mehr Zeit bleibt, kann man immer noch ausholen.
  • Meeting kontrollieren – klare Struktur, Vorbereitung und Agenda hilft stehts die Kontrolle zu haben. Nicht dass das Meeting vorbei ist und die Idee noch gar nicht rübergekommen ist. Freundlich aber bestimmt.
h1

Did you know und Net Neutrality

11. September 2006

Bin heute auf folgendes Video gestossen: Did you know?. Es passt hervorragend zu meinen aktuellen Tätigkeiten und zeigt ein paar eindrückliche Zahlen und Fakten zu Themen wie Technologie, China, Klassenzimmer, etc. – Now you know!

Und wenn wir doch gleich bei China, Internet, Technologie sind, hier der Aufruf von Tim Berners-Lee zur Netzneutralität.

h1

Games – die Faszination von Spielewelten

8. September 2006

Unter dem Namen „Dream Machines“ hat das Wired Magazin im April 2006 einen Artikel rund ums Games und deren Faszination publiziert. Spiele (und dazu gehören auch Computerspiele – Games) sind doch etwas wunderbares – nachdenken, wagen, knobeln, unterhalten, kooperieren, ausprobieren, kommunizieren, erleben, helfen, etc.

Macht Spielen Sinn? Jeder muss selbst entscheiden, ob er einen Teil seiner Freizeit mit dem Spielen und/oder Gamen verbringen möchte (jawohl, auch Erwachsene!!). Dabei gibt es eine einfache Testmethode (funktioniert bei fast allem ;-)): Wie fühle ich mich nach dem Spielen? Wenn es sich gut anfühlt und da es niemandem schadet -> los! Dann muss es doch etwas Gutes sein!

Meine persönliche Rangliste der Unterhaltungsmedien: 1) Spielen (z.B. Brettspiele) 2) Gamen (Computerspiele) 3) Buch lesen 4) Fernsehen. Auffallend ist dabei der absteigende Anteil der Interaktion… Zufall?

Im Zusammenhang mit meiner Arbeit interessiert mich vor allem die Kombination aus Spielen und Lernen – ein magisches Duo!

Nachfolgend ein paar Stichworte/Zitate aus dem oben erwähnten Artikel:

  • Schon als kleine Kinder spielen wir – dabei lernen wir!
  • Spiele ermöglichen die Fantasie auszuleben.
  • Je grösser die Kindern werden, desto komplizierter werden die Spiele und werden mit neuen Regeln und Zielen erweitert.
  • Die neue Generation von Kindern wächst heute oft mit Games auf – dabei lesen sie keine Anleitungen, sondern probieren einfach aus – trial and error.
  • Bei Spielen stellen wir Hypothesen aus, wir experimentieren und analysieren – dies im Gegensatz zur linearen Lernweise der vorherigen Generationen
  • Durch diese andere Denkweise sollte sich auch die Art und Weise ändern, wie wir in der Schule lernen. z.B. sinnvolle Einbindung von Technologie im Klassenzimmer!
  • Nicht nur zu sehen – selber Spielen! Es ist etwas ganz anderes zu zuschauen oder selber zu spielen – die Faszination ist oft nur nachvollzienbar, wenn man selber probiert und mitfiebert.
  • Spiele erlauben uns gefahrlos Optionen auszuprobieren – jeder kann seinen eigenen Weg gehen.
  • Aktuelle Spiele erlauben es uns eigene Welten zu kreieren und mit diesen zu interagieren – wir schreiben eine eigene Geschichte
  • Games vereinen sämtliche Aspekte der Unterhaltungsmedien – Geschichten erzählen – Musik hören – Video schauen – Herausforderungen suchen und annehmen – Kommunkation und vor allem Interaktion mit anderen Menschen!