Unsere Idee von Interfaces – bagpicker

logo

Ich habe lange gegrübelt, ob bagpicker eine Erwähnung auf codingfreaks Wert ist. Ich glaube ja. Allein die Tatsache, dass ich .NET-Entwickler aus Leidenschaft bin und trotzdem PHP und MySQL nehmen musste hat aber gereicht, um hier eine kleine Leidensgeschichte zu erzählen.

Wir haben lange dran gearbeitet und sind jetzt soweit, die Beta von bagpicker.de veröffentlichen zu können. Die Seite soll keine weitere Web-2.0-Community nach der Device „Klick Dich rein und verrate uns und den anderen möglichst viel über Dich!“ sein. Wir setzen vielmehr auf eine inspirierend einfache Oberfläche, gute Benutzerführung und vor allem ein Win-Win-Angebot, also das, was die Web-2.0-Paradigmen eigentlich predigen.

Prinzip

Die bagpicker-Community besteht aus baggern und pickern. Ein bagger ist jemand, der bereits ein Flugticket hat und dann merkt, dass er zuviel Gepäck im Koffer hat oder haben wird. Ein picker wiederum ist jemand, der weniger Gewicht mitnehmen wird, als er dürfte. Unsere Idee ist, diese beiden zusammen zu führen.

Beide können sich unabhängig voneinander zu bestimmten Flügen anmelden und geben dabei das jeweils gewünschte/mögliche Mehrgewicht an. Findet die Seite dabei Übereinstimmungen, werden beide automatische zusammen geführt.

Haben sich ein bagger und ein picker gefunden, entsteht automatisch ein sog. bagpicking. Beide Drucken sich einfach einen eineindeutigen Zettel aus, zeigen sich diesen am Flughafen und checken dann gemeinsam ein. Der Trick: Die Fluggesellschaften berechnen das durchschnittliche Pro-Kopf-Gewicht beider Eincheckender zusammen. Übertrifft dies die (meist 20kg hohe) Grenze nicht, muss keiner nachzahlen.

Wir übernehmen zwar keine Garantie, sehen aber auch nach tiefer gehenden Recherchen hohe Erfolgschancen in dem Modell. Der picker geht kein Risiko ein, weil er sich in einem öffentlichen Bereich mit dem bagger trifft und dessen Gepäck auf den Namen des baggers selbst eingecheckt wird.

Nach erfolgtem Checkin kann der bagger sich irgendwie beim picker bedanken (Geschenk, Kaffee, Geld), muss es aber nicht. Beide können sofort getrennter Wege gehen und gut.

Mehr zum Prinzip haben wir unter einer Subpage von bagpicker dargestellt (wie wir denken auch ganz lustig…).

Probleme, Probleme, Probleme

Zunächst habe ich bagpicker als MVC2-Anwendung entwickelt. Dahinter stand eine per Entity Framework angebundene SQL-Server-2008 R2 Datenbank. Außerdem gehörte eine Schnittstelle zum kostenpflichtigen Dienst FlightStats dazu, die eigentlich einen Life-Zugriff auf die Flugdaten erlauben sollte, doch dazu später.

Alles funktionierte einwandfrei und ließ sich aufgrund von MVC sauber testen. Ein Traum! Die optischen Anpassungen wurden komplett per CSS über das MVC-Gerüst gesetzt und alles war, wie es sein sollte. Bis zu dem Moment, als mir klar wurde, dass man in Deutschland keinen wirklich bezahlbaren Hoster für Shared-ASP.NET-4.0-Seiten inkl. SQL-Server 2008 bekommt. Keine Chance. Hätte ich ein paar Milliönchen über, würde ich selbst einen eröffnen, aber eigentlich könnte ich mir dann ja auch einen eigenen dedizierten Server leisten – ein Teufelskreis!

Ich habe natürlich sofort nach einer MVC-Alternative gesucht und landete schnell bei Ruby-on-Rails. So schnell, wie ich da landete, war ich auch wieder weg! Die Tools sind entweder kostenpflichtig oder aufwendig zu konfigurieren, im Zweifelsfall auch beides! Ich gebe ja zu, dass VS auch nicht billig ist, aber dafür ist es nahezu perfekt, wenn man es denn mal hat.

Egal, jedenfalls war Ruby nichts für mich.

Da ich keine Zeit hatte, ein paar Monate mit theoretischen Erwägungen zu verbringen, stampfte ich .NET in den Boden und wandte mich meiner noch vertrauten PHP-MySQL-Welt zu. Das Datenmodell war nicht so schwer zu kopieren, doch welch ein Rückfall insgesamt: Kein Entitity-Framework mehr, nichts mit echter Vererbung, keine Properties, keine Code-Generatoren. Ich setzte nun Adobe Dreamweaver ein, weil es meiner Meinung nach den saubersten Code-Editor für PHP/HTML hat und baute mir alles from scratch zusammen. Die Anwendung ist natürlich nur pro Forma in Ebenen unterteilt. Meine einzige Ebene neben der UI besteht in PHP-Klassen, die auch schon voneinander erben, aber das wars.

Ein weiterer Rückschritt war außerdem das Dremteam MySQL, phpMyAdmin und MySQL Workbench. Letzterem sollte man meiner Meinung nach den Namensteil „Workbench“ offiziell entziehen, aber das ist nur meine bescheidene Meinung als jemand, der das Mangement Studio kennt. Warum gelingt eigentlich der Open-Source-Gemeinde immer die beste Performance aber die schlechteste GUI-Unterstützung? Ist das ein Fluch, oder so?!?

Datenlieferanten haben die Macht

Irgendwo hatte ich mal gelesen, dass wer heute die Daten besitzt, auch die Macht hat. Ich hatte das bis zu diesem Projekt nur bedingt verstanden. Der Anbietet FlightStats ist irgendein SpinOff irgendeines Dateninhabers von Datenbanken, die die offiziellen Flugdaten enthalten. Laut FlightStats kann man diese für einen Monat im vorraus abfragen. Für einen Account für den man ca. 500 $ hinlegt (das ist schon der Maxi-Account) bekommt man nun ein Kontingent von 50.000 Anfragen für 6 Monate. Je nachdem, ob die Anfragen oder die 6 Monate zuerst ausgeschöpft sind, muss man dann nachkaufen.

Folgende Rechnung relativiert die Daten schnell, wenn man weiß, dass es ca. 1300 Fluggesellschaften gibt, die pro Tag insgesamt ca. 80.000 Flüge weltweit abwickeln (Fracht- und Passagierflüge zusammen) und FlightStats immer nur Flüge pro Fluggesellschaft ausliefert, also niemals alle Flüge eines Tages auf einmal:

1300 Anfragen pro Tag x 30 Tage = 39.000 Anfragen/Monat = 468.000 Anfragen/Jahr = 5.000 €/Jahr

Selbst wenn wir als kostenloses Portal das gemacht hätten und wir waren wirklich kurz davor!! Jetzt kam es knüppeldick. Nachdem wir eine herrliche Funktion eingebaut hatten, die uns für ein Datum und eine beliebige Flugnummer die Daten des Fluges herausgab (Abflug,Ankunft, Zeiten usw.) mussten wir feststellen, dass der WebService von FlightStats sporadisch keine Flüge für Tage, die mehr als 3 Tage in der Zukunft lagen lieferte. Eine Katastrophe! FlightStats sagt selbt, dass es nur für die jweils nächsten 30 Tage liefert und damit hatten wir uns abgefunden, aber auch das klappt nicht zuverlässig.

Nach einigen Recherchen fiel uns plötzlich dieser Online-Artikel in die Hände und ließ uns aufhorchen. Aha, google hats also auch gemerkt, dass dieser Markt ziemlich dicht ist. Leider haben die Jungs aber noch keine entsprechende API draußen. Also auch nichts. Aber dann: Ein Artikel in der c’t über den neuen Windows Azure Data Market. Aber auch hier kamen wir nicht weiter, da noch kein Flugdatenservice im Bereich „Transportation“ zu finden war.

Letztlich also folgende Entscheidung: Die User geben die Flugnummer per Hand ein und wir suchen die entsprechenden Übereinstimmungen so raus. Ist nicht schön, eine bereits funktionierende Ajax-basierte Suche mit so viel Komfort abzuschalten, aber hey: Wer die Daten hat, die Macht! Bei solchen Geschichten muss ich dann schon über so einen Giganten, wie google lächeln, der mal eben 700 Mio. für eine andere Datenkrake zückt. Die machen das einfach, aber, sie stellen es den Entwicklern dann wenigstens frei zur Verfügung. Ich weiß auch, dass google durchaus zwiespältig betrachtet werden kann, aber die anderen Daten-Horte sind nicht besser!

Gegen die Datensammler

Natürlich hätten wir mit dem Projekt die nächste Community mit Tonnen von Daten erstellen können. Wir wollten aber bewusst ein Gegengewicht zu Facebook & Co bilden, ohne diese zu verdammen (wir linken sie und sind froh, dass es sie gibt :-)). Viele kleinere Seiten folgen aber dem Trend unserer Meinung nach völlig unsinnig. Sie wollen immer wieder die gleichen Daten von ihren Usern wissen und widersprechen dem obersten Prinzip der Datensparsamkeit in jeder Hinsicht.

Bei bagpicker reicht zum einen die E-Mail-Adresse und ein Kennwort. Mehr gibt man nie von sich preis. Man kann es gar nicht. Andere User sehen niemals die E-Mail-Adressen, es sei denn, der anderte sendet sie bei einem erfolgten Kontakt per Nachricht freiwillig zu. Wenn wir nichts rausgeben, müssen wir auch nichts absichern, haben wir gedacht.

Design und Technik

Eine Sache, die wir mit bagpicker von Anfang an zeigen wollten war, wie wir uns gutes Interface-Design vorstellen. Wir (1 Developer und 1 Designer) haben also unsere privaten Nächte damit verbracht, Dremweaver, MySQL, Flash, Photoshop, Illustrator und InDesign auszuquetschen und dann alles richtig per HTML, CSS und JavaScript zu vernähen. Die Seite nutzt selbst keinerlei Flash oder sonstige Plugins und will auch noch nichts mit HTML5 zu tun haben. Das kommt später.

Uns war wichtig, das Design möglichst logisch und stringent zu halten. Der User soll nicht überfrachtet werden und zu einer Zeit nur das sehen, was er auch braucht. Ein paar kleine Gags am Rande sollen unseren „Freiheitsgrad“ zeigen: Es ist unsere Seite, also machen wir, was uns Spaß macht. Öffnet man die Seite das erste Mal, sollte man mal ein paar Sekunden nichts tun und auf den oberen Bereich achten. Wir haben einem unserer Maskottchen ein wenig Auslauf verschafft :-) .

Technisch probieren wir vieles auf Basis von jQuery/JavaScript und CSS aus. Hier können wir nur sagen, dass es zwar immer einfacher wird, gute Layouts umzusetzen, dass die Browesermacken aber auch zu immer größeren Problemen führen. Wir haben trotzdem drumherum programmiert und versuchen, möglichst viele Browser abzudecken.

Fazit

Es gibt eine schöne Traumwelt. Man kann dort Windows-Programmierer eigene Inernetseiten erstellen und im Web betreiben. Man kann alle möglichen Daten in alle möglichen Datenbanken stellen und alles miteinander verbinden. Aber das hat entweder einen heftigen Preis oder geht halt nicht mit Windows-Mitteln. In den USA ist so etwas ohne Probleme möglich, aber da sind die Ressentiments auch nicht so groß und der Markt ist breiter. Egal, wir haben es online und sind auch so happy. Guckt’s Euch einfach an und sagt es weiter! Wir brauchen vor allem User :-)!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.