Inside.meinberlin.de

Einige unter Euch haben sicherlich bemerkt, dass beim auf unserem Portal keine Seitenwechsel stattfinden. Es wird tatsächlich nur eine einzige Seite geladen. In ihr finden dynamisch Veränderungen statt. Browser können das schon ganz gut, leider speichern sie diese Veränderungen nicht in ihrer History. Das Ergebnis ist, dass Ihr, sobald Ihr den Backbutton Eures Browsers drückt, meinberlin verlasst - egal, wieviele Seiten Ihr auf dem Portal schon angeklickt habt.
Um das zu verhindern, haben wir eine einfache Historyfunktion integriert, die auch Änderungen auf einer Seite in die History des Browsers speichert. Brian Dillard hat diese Funktion erweitert und bietet einen Ausblick auf nächste Versionen, die Ihr sicher in unserer nächsten Release, die "Hellersdorf" heißen wird, testen könnt.
Wir sind gespannt.
Leider haben wir nicht geschafft, Brians Historyfunktion in unsere nächste Release einzubauen. Schließlich wollen wir Freitag schon online sein.

Das Päckchen für die Lichtenberg-Release ist längst geschnürt, da veröffentlicht google die OpenSocial-Api. Sie ermöglicht, auf nahezu alle Funktioen eines Portals zugreifen zu können und so quasi MetaPortale zu schaffen. Nach der Neighbourhood-Welle werden möglicherweise Meta-Portale das nächste BigThing sein. Inzwischen ist wahrscheinlich jeder an fünf unterschiedlichen Portalen angemeldet und verliert langsam den Überblick über Facebook, Myspace, Xing, SudiVZ und wie sie alle heißen. Meta-Portale werden dem User aus einer Oberfläche heraus ermöglichen, seine Identität in allen Portalen bequem und gleichzeitig zu ändern. Außerdem wird es so möglich sein, alle Freunde portaübergreifend verwalten zu können.
Für unsere Novemberrelease kommt diese Api leider zu spät, aber möglicherweise können wir sie schon in die nächse Release (Hellersdorf) integrieren.

Wie hier beschrieben, setzen wir im Firefox das firebug-Plugin ein, um die zahlreichen Ajax-Calls und die Qualität unseres Javascript-Codes überprüfen zu können. Seit Tagen nun zeigt das Firebug-Häkchen grün.
Alles gut?
Eher nicht.
Scheint wohl ein Firebugbug zu sein.
Jetzt heißt es, aufmerksam den Code durchzugehen.

(Das linke grüne Häkchen ist übrigens der html-Validator)

Die google-API bringt uns viele schöne Funktionen. So müssen wir die Entfernung zwischen zwei Punkten nicht mehr mit einer Formel ausrechnen, die, weil sie die Erdkrümmung berücksichtigt, schon ziemlich komplex ist, wir müssen uns nicht darum sorgen, dass unsere Applikation in irgendeinem Browser schlecht läuft oder schlecht aussieht. Die Google-API passt die Karte an, wenn User ihr Browserfenster verändern und sie lässt User ganz einfach Pins verschieben.

Das ist schon viel mehr, als man jemals von ein paar Zeilen Javascript für möglich gehalten hätte. Jetzt bietet Google noch die Routenberechnung. Und damit wir Entwickler auch dieses Feature noch freudestrahlend in unsere Applikation übernehmen, machen es die Google-Entwickler schmackhaft mit einem Spiel.

Gebt dazu am Besten in das Eingabefeld unter der Karte einen Ort ein, an dem Ihr Euch auskennt, zB. Berlin, Germany.
Drückt dann auf den Knopf "Start new Game", es erscheinen ein grüner (Start) und ein roter Pushpin (Ziel). Klickt auf den grünen Pushpin und dann, auf dem kürzesten Weg, die Straße entlang zum roten Pushpin. Ein Klick auf ihn beendet das Spiel. Auf der Karte wird nun die von Google berechnete Route und die Abweichung der beiden Strecken angezeigt.
Oberhalb der Karte wird die Abweichung zusätzlich berechnet.

Beeindruckend, wie gut sich ein Amerikanisches Javascript in meinem Kiez auskennt. Dafür kenne ich aber die schönere Strecke.

Was hat Dresden, was Hamburg und Berlin nicht haben?
Genau.
Birdseyefotos. Microsoft lässt mit den Bildern von Berlin auf sich warten. Immerhin jährt sich der versprochene Termin demnächst. Bleibt uns Zeit, die API weiter zu testen, besser zu implementieren und zu optimieren. Und täglich auf live.com nachzusehen, wo unsere Bilder bleiben.

Wer sich übrigens in Dresden die wirklich schönen Birdseyebilder ansieht und dann über die Suche nach Berlin wechselt stellt fest, dass die Zoomfunktionen immer wieder Fehler verursachen. So scheint es für Berlin plötzlich 19 Zoomlevel zu geben und beim Zoomen wechselt die Karte immer auf ein leeres Birdseye-Grid. Dabei ließe sich dieser Fehler ganz leicht über eine Variable Birdseye beheben, die über die Map-Event-Listener

VEMap.AttachEvent("onobliqueenter", start_be);

und

VEMap.AttachEvent("onobliqueleave", stop_be);

true bzw. false gesetzt wird.
Das Ganze könnte dann so aussehen:

function start_be() {
if (Birdseye==false)rebuiltZoomslider(true);
Birdseye=true;
}
function stop_be() {
if (Birdseye==true)rebuiltZoomslider(false);
Birdseye=false;
}
function rebuiltZoomslider(be) {
if (be)changeZoomTo(19); else changeZoomTo(17);
}

Hier macht es Microsoft aber nicht nur den eigenen Entwicklern schwer. Auch über die API ist es ohne Programmieraufwand nicht möglich zu verhindern, dass der User über den höchsten Zoomlevel hinaus zoomen kann und so diese unschönen grauen Kacheln erhält.
Hier muss Microsoft nachlegen. Und wenn sie schon dabei sind, sollten Sie uns Entwickler die minimale und maximale Zoomstufe festlegen lassen.

Seit vielleicht einer Woche benutze ich jetzt den Safari-Browser unter Windows XP. Ich mag seine Geschwindigkeit und die Art, wie er Formular-Elemente darstellt. Was mir aber vor allen Dingen auffällt: Die Virtual Earth API funktioniert überhaupt nicht im Safari. local.live.com zeigt nur ein verschobenes Suchfeld. Keine Karte. Während doch google-maps in keinem Browser schneller laufen. Das gilt sicher auch für den Safari auf dem iPhone.