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.
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.
Gleichnis: So wie es in einer Stadt gute und schlechte Menschen gibt und man eine Stadt nach dem Aufbau nicht allein lassen darf, sondern eine Polizei, Müllabfuhr und Regeln braucht, braucht auch eine Website mit Kommentaren (u.ä.) Regeln und Moderation um die Deppen stillzustellen und die genialen zu bestärken, mehr zu schreiben.
Welche Rollen haben Journalisten in der Zukunft? — Informationen filtern und zusammenführen (Relevanz schaffen), Informationen anreichern, Lehrer sein, Enabler sein, indem sie Plattformen zur Verfügung stellen. – Jedenfalls ein ganz anderer Schwerpunkt als „Autor/Schreiber"
„Sie (eine Firma) müssen herausfinden, was Sie am besten können – und den Rest verlinken."
Das Web ist ein großes Socialnetwork in dem man sich über Links miteinander unterhält.
PS: Mario, bitte lade die Videos auch weiterhin bei YouTube und bei Sevenloard hoch! Das ist doch schon komisch, dort nur alte Folgen zu sehen…
Robert Basic denkt in seinem Beitrag „neues Web, neues Glück: who is who" darüber nach, welche Web2.0-Dienste/-Startups es seit 2005 zu etwas gebracht haben, welche auf der Schwelle stehen und welche sich noch beweisen müssen…
Ein interessanter Artikel, der IMO den Stand der Dinge präzise zusammenfasst!
Vorab: Dieses Posting habe ich schon im März in einem internen Blog geschrieben und füge es jetzt der Vollständigkeit und einfachen Verlinkung wegen zu den flyingsparks hinzu.
Auf der Future Of Webdesign-Konferenz letztes Jahr sprach Cal Henderson (Flickr) über die 10 Punkte, die Flickr erfolgreich macht.
Sein 40-Minuten-Vortrag (MP3) gibt einen sehr interessanten Einblick in die Hintergründe, die Flickr zu einem der erfolgreichsten Fotodienste im Web gemacht hat.
Hier, was Willison aus Hendersons Vortrag zum Thema Clean URLs notiert hat:
Core principle: there’s no reason to expose the guts of our application any more. Expose the logical structure instead. The core to this on Unix is to use mod_rewrite and Apache. URLs are not filenames – they don’t have to point to something on the filesystem. mod_rewrite lets you translate incoming URLs to whatever you need for the thing to work.
Power geeks navigate by hacking the URL. Guessability matters. Downside: you might forget to link to things as the application designer!
When Flickr started, made some bad URL decisions (e.g. link to the actual photo file). Originally was flickr.com/photos/12.jpg – really hard to scale.
You have to support the old style URLs for ever. Lesson learnt the difficult way.
Und außerdem sei das Thema API noch hervorgehoben:
Meine Stichworte aus dem Vortrag (ca 11. Minute)
Ursprünglich gebaut, weil man für AJAX-Interfaces ohnehin bestimmte Anfragen ständig brauchte.
Einer der ersten die eine API veröffentlicht haben
Read-Only — schon ein sehr wertvoller Dienst (maschinenlesbare Ausgabe)
Flickr entwickelt sich zu einem Datenspeicher für Fotos; andere bauen die Ausgabekanäle und Interfaces drumherum (TJ: vgl. auch Facebook etc)
Beispiel: Das Spiel namens Faster (oder so), das auf der API aufbaut, wäre von Flickr nie gebaut worden, weil es nicht dem Kern der Netzapplikation entspricht, nicht skalieren würde und zu teuer im Support ist. Bei dem Spiel werden Fotos gezeigt und man muss den zugehörigen Tag erraten. Aber da Flickr die API zur Verfügung stellt, haben sich Leute gefunden, die es gebaut haben “but its really cool” und Flickr profitiert von der generierten Aufmerksamkeit und den gesteigerten Sign-Ups
Denkfehler: Keine API zur Verfügung zu stellen bedeutet nicht, dass Leute nicht probieren werden, an die Daten zu kommen. Sie werden jedoch wesentlich unangenehmere Wege wählen und beispielsweise die Website grabben…
Mit einer API hat man selbst Kontroll über die Anfrage und bestärkt Leute, selbst etwas auszuprobieren…
Die ursprüngliche URL http://www.webuser.co.uk/carsonworkshops/CalHenderson.mp3 ist leider nicht mehr verfügbar. Ich habe mein Backup bei mir bereit gestellt.
Ich habe zum ersten Mal von ihm gehört. Der Videostream ist aber recht interessant. Insbesondere, da ich zur Zeit „Getting Real, the book" lese.
An einigen Stellen ähneln sich die Aussagen von GettingReal und Guy Kawasyki. Insgesamt finde ich das GettingReal-Buch jedoch noch treffender.
Guy K. geht an einigen Stellen eher in Beispielen auf bestehende Probleme ein. GettingReal beschreibt die Philosophie mit der man die Probleme umschifft…
Unten folgen noch ein paar Stichworte aus dem Vortrag den ich übrigens nur im Internet Explorer angucken konnte…
