Realtime web

Editor's Notes

• #2: Das ist ein Management-Talk. Erwartet also kein Niveau. \n
• #3: Mit diesem Bild könnte man denken, das wäre ein Vortrag über Frauen in der Informatik. Ist es aber nicht.\nZur Einstimmung ein Bild von den beiden Protagonisten, die erst bei den Rich Internet Applications, und nun beim Real Time Web eine grosse Rolle spielen. \nDass wir ITler tatsächlich mal mit dem identischen Toolset wie die Raumpflege arbeiten hätte vermutlich keiner erwartet.\nDer Begriff AJAX wurde 2005 geprägt, und steht für Asynchronous JavaScript and XML. Die Technik gab es schon deutlich vorher. Wenn man die Entwickler fragt, haben sie _alle_ seit 1996 bereits mit xmlHTTPRequest gearbeitet, nur heimlich. Ich auch :-).\n
• #4: Google Suggest war das erste, das tatsächlich draussen war, vermutlich erinnern sich noch einige an die erste Reaktion „Warum kommt da ein Ergebnis bevor ich mit tippen fertig bin? \nDer endgültige Business-Nutzen war hier aber noch nicht abzusehen - aber autocomplete/ suggest ist heute eine Standardfunktion für Suchmasken und Filter.\n
• #5: Mit Google Mail begann der eigentliche Hype. Was vorher als technische Spielerei abgetan wurde, wurde plötzlich zu einer massentauglichen Technologie, die neue Massstäbe im Bereich Usability setzt. Das Zeitalter, in dem viele Nutzer aus Sicherheitsgründen JavaScript global deaktivieren und das BSI vom Einsatz abrät ist vorbei, ab jetzt wird Javascript zwingend vorausgesetzt.\n
• #6: Comet wurde nur ein Jahr nach AJAX, also 2006, als Begriff geprägt. Es handelt sich nicht um eine Akronym - sondern nur um die größte Konkurrenzmarke zu Ajax im Waschmittelbereich in den USA. Comet ermöglicht die Kommunikation vom Server zum Client, also das, was 10 Jahre mal Push-Technologie genannt wurde. \nNetscape hatte bereits 1995 ein Feature eingeführt, dass das nachliefern von neuer Information vom Server implementiert hat - das konnte sich nicht durchsetzen, nicht zuletzt, weil Microsoft dieses Feature im Gegensatz zu allen anderen Browsern bis heute nicht unterstützt.\n
• #7: Hier haben wir den Google Suggest von Comet und das klassische Beispiel für Realtime Web. Twitter bewegt sich in Echtzeit. \nDie Information, dass jetzt noch X neue Nachrichten da sind, wird unmittelbar über COMET / PUSH an den Client geliefert.\n
• #8: Das Google Mail von Comet heisst Facebook. Hier wurde nicht nur durch neue Meldungen wie bei Twitter, sondern auch durch den Chat und die Status-Icons in der linken oberen Ecke viel Funktionalität mit Ajax bedient. \n
• #9: Das Google Mail von Comet heisst Facebook. Hier wurde nicht nur durch neue Meldungen wie bei Twitter, sondern auch durch den Chat und die Status-Icons in der linken oberen Ecke viel Funktionalität mit Ajax bedient. \n
• #10: Das Google Mail von Comet heisst Facebook. Hier wurde nicht nur durch neue Meldungen wie bei Twitter, sondern auch durch den Chat und die Status-Icons in der linken oberen Ecke viel Funktionalität mit Ajax bedient. \n
• #11: Diese Echtzeitigkeit der Kommunikation wirkt sich inzwischen schon auf alle anderen Bereiche aus.\nSeit 3 Monaten ist die Real Time Search auch Bestandteil der Google-Suche in Deutschland. Und wie man sieht, hat auch Bing nachgezogen.\nUnd Google versucht sich mit Google Buzz - und dem Kauf von 4square - auch aktiv im Realtime-Geschäft zu positionieren.\n\n
• #12: Am besten Tag von 2009 - dem 14. Dezember - hat Amazon 9.5 Millionen Produkte verkauft. \nFür jedes bei Amazon bestellte Produkt gibt es 4 Facebook-Updates und 3 Tweets. \n
• #13: Warum ist Facebook und Twitter so attraktiv? \nHier gibt es zwei Paradigmen-Wechsel.\nIm Gegensatz zum „alten Web“ wird nicht nur Content angeboten, sondern auch Kontext. \nDie Informationen sind für mich relevant, weil sie mich sozial betreffen weil ich selbst nach ihnen gesucht oder gefiltert habe, und weil sie echtzeitig \nkommen. \nDieser Kontext kann von mir und meiner Applikation direkt genutzt werden - in Form der Facebook Applikationen. Ich bekomme praktisch alle Information - sogar die der Freunde der Nutzer meiner Applikation - frei haus, und kann darauf reagieren.\n\n
• #14: Und noch ein zweiter Wechsel zeigt sich: vorher habe ich nach dem Inhalt selbst gesucht, und habe dann auf ihn navigiert. \nJetzt stehe ich im Stream, dh. die Inhalte kommen vorgefertigt und für mich zugeschnitten dann auf mich zu, wenn sie passieren. \nIn Facebook und Twitter ist das wichtigste Element der Nachrichtenstream.\nUnd, wie gesagt, ich kann direkt darauf mit meiner Applikation reagieren.\n
• #15: Ich hatte am anfang gesagt, dass ist ein Managementtalk. Jetzt sind wir da, wo die Buzzwords kommen.\nEs gibt viele Beispiele, wie sich diese neuen Fähigkeiten auswirken werden. Im Real Time Customer Service bekommt der Kunde direkt online per Chat hilfe, wenn er eine Frage hat. \nBei Real Time Meinungen sehe ich die letzten Kritiken zum Pizzalieferdienst bei mir um die Ecke, wie bei Bringbutler zu sehen. \nReal Time Targeted Marketing erlaubt auf Basis der Lagerbestände, der geographischen Adresse des Kunden und seinem aktuellen Warenkorb gezielt Werbung zu schalten. \nSAP zeigt mit seinem Gravity, wie man das ganze benutzt - in Real Time Collaboration werden Business-Diagramm in Echtzeit gemeinsam erstellt. \nEin Shop kann in Echtzeit Gruppenkäuft organisieren oder bewerben, und hierfür Rabatte einräumen - oder parallel zu Werbekampagnen im Fernsehen Werbung schalten. \nBishin zur Selbstbezüglichkeit: die Trends auf Twitter werden gemessen und gezielt beworben. \nWas sich genau wie und vor allem wann durchsetzen wird ist nicht klar - das musste auch Google mit Google Wave akzeptieren.\nAber es gibt noch einen anderen Bereich, in dem Realtime eine Rolle spielt: \n
• #16: Die älteren Anwesenden können sich vermutlich noch an eine Zeit erinnern, als Handys noch zum telefonieren genutzt wurden. \nWer sich heute im Fernsehen eine Handy-Werbung anschaut, bekommt etwas ganz anderes zu sehen: die Facebook, Twitter und Google-Maps-Applikation. \nMobile bietet noch mehr Kontext: Location-Based Services erlauben eine direkte Adressierung aufgrund des Ortes des Nutzers. \nDer Mobile Status hört nicht mit Geodaten auf. Aktuelle Fotos, oder etwa eingescannte Barcodes, mein Telefonbuch, die Musik auf meinem Handy und ähnliches erzeugen noch mehr kontext.\n
• #17: Und mobile Geräte bringen noch einen Unterschied: ab jetzt ist man immer online und erreichbar. \nDienste wie Aka-aki melden sich per Push mit gezielten Informationen zu meiner Geo-Position. Ich bin aber nur dann erreichbar, wenn mich etwas erreicht, dass in meinem Stream relevant ist.\nWie bei allen neuen Technologien sind die First Adopter schon mit dabei - Aka Aki ist schwul dominiert. \nIch weiss nicht, ob es bereits einen Adult friend finder fuckability radar gibt, wenn nicht, ist das eine reine zeitfrage. \nÜberleitung: aber was hat das mit Web zu tun?\n
• #18: Der mobile Client ist nicht der Browser, sondern die App. das hat mehrere Gründe\na) für den Nutzer ist das Deployment aus dem Appstore einfacher als der Bookmark im mobilen Browser\nb) die Passwort-Eingabe ist mühsam, man will nicht jedes mal über den Bildschirm einen Login eingeben\nDas heisst aber nicht, dass es sich hier nicht um eine Web-Anwendung handelt - im Gegenteil, Tools wie Titanium oder PhoneGap und auch die Aktivitäten der Hersteller von mobilen Devices zeigen einen deutlichen Trend zur Konvergenz. Die IPhone oder Android-App der Zukunft ist eine Web-Applikation\n\n
• #19: \n
• #20: Jetzt kommt es mal zum Development. \n
• #21: Aber mal konkret: Was passiert, wenn unser Chef Realtime web von uns will? \n
• #22: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #23: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #24: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #25: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #26: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #27: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #28: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #29: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #30: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #31: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #32: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #33: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #34: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #35: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #36: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #37: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #38: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #39: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #40: 2000 hätten wir das über ein regelmässiges Polling gelöst ... \n
• #41: \n
• #42: \n
• #43: \n
• #44: \n
• #45: \n
• #46: \n
• #47: \n
• #48: \n
• #49: \n
• #50: \n
• #51: \n
• #52: \n
• #53: \n
• #54: \n
• #55: \n
• #56: In beiden Fällen haben wir mit klassischen Web-Applikationen ein Problem. \n
• #57: Nodejs: JavaScriptV8-Engine von Google -> FAST\nMonolithisch, schön zu programmieren.\n
• #58: CometD: Alt, Python, von den Dojo-Jungs\n
• #59: \n
• #60: \n
• #61: Die Schnittstelle von PHP zum XMPP kann direkt über XMPP - aber durchaus auch durch einen Rest-Service erfolgen.\n
• #62: XMPP kann eigentlich alles transportieren. \nBayeux ist _deutlich_ einfacher\n
• #63: \n
• #64: Websockets sind von den Bayeux-Protokollen inspiriert. \nDurch die Anforderungen an die Client- und Serverwelt wird es aber noch einen Moment dauern, bis sie sich in der Breite durchsetzen. \n
• #65: \n
• #66: \n