mashup blog.

Mashups programmieren - oder "the making of velyoo.com"

blog(at)velyoo(dot)com (Marco Hassler) — Sun, 27 Jan 2008 13:33:50 GMT

Schon einige Male haben wir in diesem Blog berichtet, wie bestimmte Teile von velyoo.com programmiert wurden. Nun gibts ähnliche Erläuterungen und noch viel mehr auch in Buchform. Im letzte Woche im O'Reilly-Verlag erschienenen Buch Mashups programmieren wird auf rund 75 Seiten auf die technische Architektur und die Programmierung von Teilen von velyoo.com eingegangen - und einige interessante Geheimnisse zur Plattform und zur Funktionsweise gelüftet.

Neben Programmieranleitungen für ein Mashups wie velyoo.com wird im Hauptteil des Buches von den Co-Autoren Denny Carl, Joern Clausen und Anatol Zund eine Einführung in die Mashup-Welt, Programmiersprachen und Services gegeben sowie anhand von einigen weiteren sehr interessante Mashup-Beispielen erläutert, wie man selbst einen Mashup erstellen kann. 'Mashups programmieren' ist bei Amazon.de oder im Buchhandel erhältlich.

Relief Karten-Layers für Google Maps

blog(at)velyoo(dot)com (Marco Hassler) — Mon, 10 Dec 2007 21:08:11 GMT

Bemerkenswertes Kartenmaterial kommt in der Maps-Anwendung maps-for-free.com daher:

Auf der Site werden Layer mit Relief-Karten für Google Maps dargestellt und grad in einer ziemlich spannenden Beispielintegration präsentiert. Das weltweit verfügbare Relief lässt Höhen und Tiefen auf den sonst eher zweidimensionalen Kartenansichten hervortreten. Insbesondere interessant: Der Relief Layer ist unter der Creative Commons Licence lizenzierbar und bietet sich daher für den eigenen Mashup auch an. Einbaututorial und Kartenkacheln liegen der Mashup-Site bei.

Google Mapplets - Mashup direkt auf Google Maps

blog(at)velyoo(dot)com (Marco Hassler) — Wed, 08 Aug 2007 15:26:07 GMT

Google hat kürzlich seine Mapplets in die Google MyMaps live geschaltet, nachdem der Preview für Entwickler schon einige Wochen verfügbar war. Mapplets sind kleine Gadgets, welche personalisiert ein Overlay auf die Google Maps erlauben und für jedermann auf Google-Server zum Download bereitgestellt werden können. Damit werden Mashups sozusagen innerhalb der Google Maps möglich, was insbesondere interessant ist, um einen Mashup einer breiten Menge an Nutzern zugänglich zu machen.

Zum Beispiel lassen sich so Wohnungsinserate in die Google Maps hineinrendern. Mittlerweile sind schon über hundert solcher Mapplets verfügbar. Velyoo hat natürlich auch ein entsprechendes Mapplet, welches sich hier zum Download findet.

Google maps und die dritte Dimension

blog(at)velyoo(dot)com (Marco Hassler) — Sat, 07 Jul 2007 19:33:26 GMT

Von Google Earth ist man sich die Dreidimensionale Ansicht von Kartendaten ja mittlerweile gewohnt. Google maps kennt man bislang aber nur zweidimensional. Interessanter wird das ganze, wenn man Höhen-Informationen auch in Google Maps reinbringt. Heywhatsthis mischt in einem Mashup Höheninformationen mit den Google Maps Karte und bringt damit die dritte Dimension interessant ins Spiel:

Ausgehend von einem Ort auf der Karte - z.B. einem Berggifpel - lässt sich eine Panorama-Ansicht des Höhenprofils generieren. Soweit noch mässig spektaktulär bzw. visuell noch nicht ganz ausgereift aber schon mal ganz gut.

So richtig interessant wirds dann aber, wenn man sich auf der Google Karte jene Bereiche einzeichnen lässt, welche von dem Blickpunkt aus sichtbar sind - so im Stile von z.B. welche Berggipfel sehe ich von Gipfel xy aus denn überhaupt?

Und als obs noch nicht genug wäre, lässt sich auch noch ein Höhenprofil auf der Karte einfach zusammenklicken oder per Google Mapplet (Mapplet namens Elevation Contours) Höhenkurven auf der Karte einblenden. Man male sich selbst aus, was man mit diesen Höheninformationen noch alles erstellen kann...

Differenzierungsmerkmale von Mashups – Beispiel Visual Search

blog(at)velyoo(dot)com (Marco Hassler) — Thu, 07 Dec 2006 18:45:59 GMT

Wie bereits früher ausgeführt, ist eine der grösseren Herausforderungen bei Mashups der nachhaltige Geschäftsnutzen. Die Gefahr liegt dabei insbesondere darin, dass neue Konkurrenten oder die Anbeiter der Originaldaten einen gut funktionierenden Mashup einfach kopieren bzw. nachbauen. Dies ist verhältnismässig einfach möglich, wenn ein Mashup nur die üblichen Web 2.0 Features einsetzt. Ein richtiges Differenzierungsmerkmal besteht erst, wenn beim mashen eine schwer kopierbare Technologie eingesetzt wird (welche zudem auch noch Kundennutzen stiftet, welche die Originalplattformen nicht haben). Am ehesten zu finden sind solche Technologien im Information Retrieval Bereich (d.h. z.B. Suche nach Produkten etc.). Kartenapplikationen, in welchen Produkte nach einer Suchstrategie – nämlich Lokalität – gefunden werden können, waren bis vor kurzem eine solche Technologie. Dann kam Google mit Google Maps, womit eine Differenzierung wiederum extrem schwierig wird. Beispiele, wie eine solche Technologie aber auch aussehen kann liefert like.com: Mal abgesehen davon, dass Artikel von verschiedenen Shops wie Amazon und Zappos gemashed werden, setzt like eine selbst entwickelte Visual Search Engine ein. Diese sucht ausgehend von einem Beispielprodukt nach visuell ähnlichen Produkten – grad bei Kleidern eine relativ nützliche Funktion. Und vor allem von der allgemeinen Mashup-Crowd in nächster Zeit kaum zu imitieren.

Mashups für Dummies

blog(at)velyoo(dot)com (Marco Hassler) — Sun, 12 Nov 2006 21:21:50 GMT

Soweit, dass es so ein Buch bräuchte, sind wir zum Glück noch nicht. Dieser Image Cover Maker ist aber auch so eine Art Mashup (Cover- und Text-Mashup :-) ).

Geschaeftsmodelle fuer Web 2.0 Unternehmen

blog(at)velyoo(dot)com (Marco Hassler) — Sun, 15 Oct 2006 17:23:43 GMT

In Zeiten wo Firmen ohne erkennbares Revenue-Modell wie YouTube für 1.6 Mrd. $ über die Ladentheke gehen, mag es dem einen oder anderen, der sich auch 2001 schon mit Internet auseinandergesetzt hat, etwas flau in der Magengegend werden. Nicht nur dass Marktforschungsunternehmen wie Gartner Web 2.0 Themen gerade hypen (siehe Hype-Cycle mit Mashups an der Spitze), auch Medien und Investoren sind wieder auf den noch fahrenden Zug aufgesprungen. Bezeichnend hierfür sind Artikel wie jener von CNN, wo angeblich $100 Mio. in verschiedene Web 2.0 Unternehmen investiert werden sollen. Willkommen beim Bubble 2.0?

Wie schon 2001 gibt es allerdings auch im Hype Unternehmen, welche dem Bubble trotzen und den Sprung über das Tal der Tränen hinaus schaffen werden – dazumal waren es die eBays und Amazons. Unternehmen, bei welchen ein nachhaltiges Revenue-Model dahintersteckt. Ähnliche Überlegungen sollte man sich heute bei Web 2.0 Unternehmen anstellen, um die Erfolgsaussichten einer Geschäftsidee zu bewerten. Drei wesentliche Faktoren sind im Folgenden kurz diskutiert.

Revenue Model

Werbung allein ist kein nachhaltiges Business Modell. Dies musste auch Google feststellen und versucht fieberhaft mit diversen Enterprise Solutions (für Maps, Search Appliance etc.) andere verlässlichere Finanzquellen anzuzapfen. Bei Web 2.0 Unternehmen ist bislang das einfachste und am häufigsten praktizierte „Revenue-Modell“ ebenfalls Werbung – bzw. die Integration von Google Adsense Anzeigen in die eigene Site. Die Nachhaltigkeit dieses Modells wird allerdings schon relativ rasch fraglich: Um mit Adsense-Auszahlungen ein Unternehmen finanzieren zu können, müsste schon extrem viel Traffic vorhanden sein – dann würden aber andere Werbemodelle besser rentieren als Adsense. Zudem ist hier die Abhängigkeit von Google extrem gross und bei genauerem Studium der AGBs von Google wird auch ziemlich klar, wer am ganz langen Hebel sitzt.

Wenn nicht Werbung, dann müsste das Revenue Model auf Verkauf von irgendwelchen Leistungen basieren. Generell ist im Internet der Verkauf von Leistungen an Endkunden aber immer noch heikel. Nicht nur, dass Endkunden erwarten, dass Information und Dienstleistungen im Internet grundsätzlich kostenlos sind – Im Geschäft mit Endkunden wirken immer auch Debitoren-Risiken aufs Geschäftsmodell ein. Erfolgsversprechender sind da B2B-Modelle – für den Kunden ist der Dienst kostenlos, bezahlt wird er durch anbietende Drittfirmen (Bsp. Google-Suche ist für Endbenuter kostenlos und wird über Adwords von Dritt-Unternehmen finanziert). Und ebenfalls eine alte Weisheit: Am Goldrausch am meisten verdient haben seit je die Werkzeughersteller.

Differenzierung oder Kostenführerschaft

Schaut man sich die Positionierung von aktuellen Web 2.0 Unternehmen an, ist bei einigen die Aussage “Zwischen Stühlen und Bänken“ ziemlich treffend – insbesondere dann wenn „Popularity first, revenue model later“ oben drauf geschrieben steht. Dass es eine kritische Masse an Usern braucht, damit ein Geschäftsmodell funktionieren kann, ist hinlänglich bekannt – insbesondere wenn es wie bei Web 2.0 Themen viel um gemeinsam erarbeitete Inhalte und den ganzen erweiterten Community-Gedanken geht. Dennoch, nicht alles was viele Leute lustig und interessant finden, hat auch ein Geschäftsmodell dahinter. Und das müsste man sich vielleicht überlegen, bevor man Investitionen zur Steigerung der Popularität tätigt. Ein Unternehmen, das sein Angebot auf dem Massenmarkt anbietet (Popularity), müsste sich eigentlich über Kostenführerschaft anstatt Differenzierung positionieren. Kostenführerschaft würde implizieren, dass das Unternehmen ein starkes Gewicht auf Kostenkontrolle, Kostensenkungskultur, Verfahrensinnovation und klar gegliederte Organisation und Verantwortlichkeiten legen müsste. Bei welchem Web 2.0 Unternehmen ist dies wohl so?

Wettbewerbsbetrachtungen

Gemäss Porter – einer Koryphäe im Gebiet der Wertschöpfungsstrategie – bestimmen zwei Faktoren die Gewinnchancen in einem Geschäft: Die generelle Attraktivität der Branche und die Position der Wettbewerber innerhalb einer Branche. Nimmt man mal die Attraktivität der Branche nun mal als gegeben und schaut sich die potenziellen Konkurrenten innerhalb der Web 2.0 Welt an, lässt sich für die fünf Wettbewerbskräfte folgendes sagen:

Potenzielle neue Konkurrenten: Die Gefahr von potenziellen neuen Konkurrenten ist für ein Web 2.0 Unternehmen als ziemlich gross einzustufen, da die Eintrittshürden im Web 2.0 Umfeld sehr klein sind. Mit etwas Fleiss kann sich heute praktisch jede Studentengruppe eine Web 2.0 Site bauen, der Kapitalbedarf ist minim, und die Differenzierung klein. Das einzige Differenzierungsmerkmal von Web 2.0 Unternehmen ist meistens das Interface. Und AJAX als Interface-Element ist dabei weder wirklich massentauglich, noch stellt es dank offenem Quellcode in irgendeiner Form eine Eintrittsbarriere dar.

Verhandlungsmacht der Lieferanten: Angenommen ein Mashup integriert Daten über eine API von einem Lieferanten wie Google oder eBay, dann kann man schon sagen, dass die Verhandlungsmacht der Lieferanten geradezu ungeheuerlich ist. Denn was Daten-Lieferanten so alles in den zu akzeptierenden AGBs niederschreiben ist so ziemlich einseitig. Und da es nur ein eBay, ein Amazon und ein Google gibt, ist die Situation relativ klar: wer nicht akzeptiert, bekommt keine Daten mehr – auch keine besonders gute Ausgangslage für ein langfristiges Geschäftsmodell.

Verhandlungsmacht der Abnehmer: Abhängig davon, ob Webuser oder Drittunternehmer Abnehmer der Leistungen sind, ist die Verhandlungsmacht derer ebenfalls kritisch zu beurteilen. Ist das Revenue-Modell z.B wiederum lediglich auf ein Abnehmer ausgelegt (z.B. bei Verwendung von Google Adsense), ist die Abhängigkeit und Verhandlungsmacht des Abnehmers entsprechend gross. Funktioniert ein Angebot am Markt, ist sogar die Reintegration der Leistung durch den Abnehmer ein Gefahrenpotenzial (Bsp.: Mashups, welche Flickr-Fotos auf Yahoo Maps integrieren kommen bei Benutzern gut an; als Konzequenz beitet Flickr nun seit kurzem direkt eine Kartenintegration der Fotos an, Mashup-Site wird überflüssig). Sind Webuser Abnehmer einer Leistung, ist die Verhandlungsmacht weniger konzentriert. Dadurch, dass jedoch eine Website nur in beschränktem Mass eine Bindung zu einem User erzielen kann und die Switching costs meist relativ tief sind, tun sich die Probleme wieder an anderer Stelle auf.

Bedrohung durch Ersatzdienste und Grad der Rivalität unter Etablierten

Die beiden anderen Porter’schen Wettbewerbskräfte (Substitutionsanbieter und Wettbewerber in der Branche) kann man aufgrund der Jugend, dem starken Wachstum und der schnellen technologischen Entwicklung der Branche aktuell noch als untergeordnet betrachten. Zweifellos wird allerdings die Rivalität steigen, sobald die Reifephase erreicht ist. Je mehr Geld in Web 2.0 Unternehmen investiert wird und je grössere Akquisitionen getätigt werden (Beispiel YouTube), desto höher sind die Erwartungen und desto härter wird auch hier der Kampf werden. Gut wenn man sich dann schon vorher überlegt hat, wie man sein Geld machen will.

Web 2.0 also alles Bubble 2.0?

Wohl nicht. Entscheidend ist, genau Überlegungen dieser Art zu machen, bevor man blind Web 2.0 hyped. Einige Lösungsansätze von Web 2.0 bringen dem Endnutzer effektiv einen Zusatznutzen und beinhalten damit auch das Potenzial, dass sich Geld verdienen lässt. Wer oben zwischen den Zeilen liest, mag den einen oder anderen erfolgsversprechenden Ansatz für ein Web 2.0 Business herauslesen – mehr muss jeder für sich selbst beurteilen. Sicher ist, es bleibt dynamisch.

Velyoo bei programmableweb.com

blog(at)velyoo(dot)com (Marco Hassler) — Wed, 16 Aug 2006 05:11:58 GMT

Programmableweb.com ist die Adresse im Internet, um sich einen Überblick über die verschiedenen Mashups im Web sowie integrierbare APIs zu verschaffen. Derzeit sind dort über 900, vor allem amerikanische Mashups verzeichnet - und für interessierte unbedingt empfehlenswert. velyoo.com wurde kürzlich dort aufgenommen und mit fünf Sternen bewertet - thank you guys.

Mashups ganz zuoberst auf Gartners Hype Cycle

blog(at)velyoo(dot)com (Marco Hassler) — Tue, 15 Aug 2006 04:01:42 GMT

In regelmässigen Abständen platziert der IT Marktforschungs-Spezialist Gartner aufkommende Technologien auf einem sogenannten Hype Cycle. Idee dahinter ist, dass eine Technologie x-Jahre nach einem ersten Hype zu einer beständigen Technologie wird (Bsp. Bluetooth-Hype Ende der Neunziger, 4-5 Jahre später als Standardtechnologie in praktisch jedem Handy vertreten). Interessanterweise rangieren auf dem eben kürzlich publizierten, aktuellen Hype Cycle von Gartner Mashups ganz oben auf dem Peak des Cycles. Es kann demzufolge nur noch ein paar Jahre gehen, bis man Mashups wirklich brauchen kann :-)

Google Maps: Grosse Anzahl Markers optimal in Map laden

blog(at)velyoo(dot)com (Marco Hassler) — Sun, 13 Aug 2006 15:18:05 GMT

200-300 geografische Punkte mittels Google maps API in eine Map zu laden, ist die Standardaufgabe bei jeder Google Maps integration und stellt keine besondere Herausforderung mehr dar: Sämtliche Punkte bzw. Markers können initial mit addOverlays() geladen werden. Verschiebt der Benutzer den Kartensausschnitt oder Zoomt er aus, sind sämtliche Markers bereits im Hintergrund vorhanden und werden sofort dargestellt. Dies funktioniert soweit gut und stabil für eine fixe und kleine Anzahl Markers, wie z.B. bei dieser Verkehrsunfall-Map.

Was aber, wenn nun die Anzahl Marker grösser ist, z.B. für den Fall dass man sämtliche Ortschaften der Schweiz mit einem Marker versehen möchte oder Artikel von eBay oder ricardo auf einer Map positionieren möchte. Hierfür können die Marker nicht mehr alle auf einmal initial geladen werden – die Ladezeit wäre einerseits zu lange, anderseits funktioniert Google Map ab 400-500 geladenen Markers derart langsam (Maus blockiert bis hin zu Browerabsturz), dass es kaum mehr usable ist. Die Lösung hierfür heisst dynamisches Laden der Markers entsprechend dem angezeigten Kartenausschnitt. Ist für die Marker-Daten eine XML-Schnittstelle verfügbar, welche als Parameter die Eckpunkte des angezeigten Kartenausschnitts entgegennimmt, ist auch dies relativ einfach zu realisieren. Das AJAX-konforme Laden der Marker funktioniert dann durch Übergabe eines URL-Strings an das Google Maps Objekt GDownloadUrl, z.B:

strFeedUrl = http://www.mydomain.com/api.xml?sw= “ + map.getBounds().getSouthWest() + “&ne= + map.getBounds().getNorthEast();

Soweit so einfach – und wahrscheinlich auch schon in zig Google maps so gelöst. Die grössere Herausforderung kommt aber noch: Das Nachladen von Markers sobald der Benutzer den Kartenausschnitt verschiebt oder auszoomt. Da vorhin ja nur die Markers innerhalb des Kartenausschnitts geladen wurden, sind beim Verschieben Teile des neuen Kartenausschnitts noch Marker-los. Um diese wiederum dynamisch nachzuladen, haben wir uns folgende Ansätze angeschaut:

1. Überschreiben: Das einfachste ist, die Markers einfach innerhalb des neuen Kartenausschnitts mit addOverlays() dazuzufügen. Falls der Kartenausschnitt bereits Markers enthielt (vom vorhergehenden Ausschnitt), werden von Google Maps an den identischen Stellen zusätzlicher Marker über die bestelhenden positioniert. Visuell stellen diese übereinander gelegten Markers kein Problem dar und erscheinen als ein Marker (ausser dass der Schatten immer dunkler wird…). Jedoch summiert sich die Anzahl der Markers so sehr schnell, dass die Karte wieder nach einigen Verschiebungen kaum benutzbar wird (z.B. bei 50 Markers auf einem Ausschnitt sind nach 10 Verschiebungen effektiv schon ca. 500 der Map hinzugefügt).

2. Verzögertes Laden: O’Reilly schlägt in Google Maps Hacks (übrigens empfehlenswert) bei grösseren Mengen Markers vor, diese nicht umgehend beim Verschieben nachzuladen, sondern das Laden der Markers zeitverzögert zur letzten Kartenverschiebung zu laden (z.B. 2 Sekunden mittels setTimeout() verzögert). Dies ist sehr hilfreich, wenn der Benutzer mehrfach hintereinander kleine Verschiebungen des Ausschnitts macht, löst aber das Grundproblem der sich addierenden Anzahl Markers eigentlich nicht.

3. Löschen und neu Laden: Die bei Google Maps Implementationen meist gesehene Lösung ist, nach jedem Verschieben und Zoomen sämtliche Markers mit clearOverlays() zu löschen und jene des aktuellen Kartenausschnitts neu zu zeichnen. Dies funktioniert zwar stabil (z.B. auf Smagoo), ist aber aus folgenden Gründen suboptimal: a) Bereits geladene Markers zeigen ein kurzes Flackern, da sie zuerst entfernt und dann wieder angezeigt werden. b) Das Datenvolumen, welches im Hintergrund transferiert wird, ist grösser (da immer wieder sämtliche Punkte des Ausschnitts geladen werden) – für den Benutzer tritt eine spürbare Ladeverzögerung auf. c) Verschiebt der Benutzer einen Ausschnitt wieder zurück auf einen Bereich, der bereits vorhin geladen war, sind die ursprünglichen Markers weg und werden nur zeitverzögert wieder nachgeladen.

4. Markers mit ID: Wenn jeder Marker mit einer ID versehen wird, kann beim Nachladen von Markers überprüft werden, ob dieser auf der map noch fehlt – und nur dann der Map hinzugefügt werden. Dies dürfte einfach funktionieren, wenn die IDs ein drei- oder maximal vierstelliger Integerwert sind, so dass z.B. direkt mit arrLoaded[intId] == true ? überprüft oder gesetzt werden kann, ob der Marker geladen ist. Ist keine solche ID vorhanden (wie z.B. bei velyoo für eBay-Arikeln, wo die ID eine zwölfstellige Zahl ist) muss die performance-aufwändiger durch loopen des Arrays gelöst werden, was ebenfalls bei grösseren Markerzahlen unpraktikabel wird: Um in einem Loop 500 geladene Artikel mit 100 neuen zu vergleichen sind bis zu 50'000 Iterationen notwendig.

5. Nachladen des Kartenausschnitt-Deltas: Für velyoo haben wir schlussendlich diese – aus meiner Sicht optimale Variante – entwickelt. Dabei wird beim Verschieben der Karte die Differenz der beiden Flächen vor dem Verschieben und nach dem Verschieben (oder Zoomen) ermittelt. Die Fläche ist in folgender Grafik gelb dargestellt:

Dieses Delta lässt sich wiederum in drei Rechtecke (bzw. bei Zoom vier) unterteilen, welche einfach analog dem gesamten Kartenausschnitt geladen werden können. Eine neue Schwierigkeit tut sich allerdings auf, weil man so die bereits geladenen Kartenausschnitte über mehrere Verschiebungen hinweg speichern muss. Je nach Richtung der Verschiebung können dabei Flächen entstehen, welche die Speicherung der geladenen Markers bzw. Berechnung der zu ladenden Markers sehr schwierig wird. Folgende Illustration soll diese Schwierigkeit aufzeigen (grau = geladene Ausschnitte, weiss = ungeladen, gelb = für aktuellen Ausschnitt nachzuladen):

Rein programmiertechnisch wär die Speicherung und Berechnung zwar möglich, wesentlich einfache ist allerdings folgende Näherungslösung, welche den Zweck ebenfalls erfüllt: Anstatt das exakte Delta von Kartenausschnitten zu laden, wird das Delta so vergrössert, dass wiederum ein einfach speicherbares Rechteck entsteht. Dadurch werden zwar etwas mehr Bereiche als gerade benötigt in die Karte geladen. Bei einem üblichen Verschiebevorgang, der sich rund um den Initialpunkt bewegt, sind die zusätzlichen Daten jedoch meist geringfügig, die dadurch verursachte Ladeverzögerung vernachlässigbar.

(grau = geladene Daten, rot = neuer Kartenausschnitt, gelb = zu ladende Daten in der Vereinfachung). Dieser Mechanismus ist bei velyoo z.B. unter im Bike Marktplatz implementiert. Javascript-Funktionen, in welchen obige Erläuterungen umgesetzt sind, finden sich unter http://www.velyoo.com/res/mapHelpers.js.