Apple und der kommende Untergang auf dem Smartphone-Markt.

Die heutige Apple-Keynote habe ich nicht live verfolgt, sondern auf die Ergebnisse gewartet. Keynotes sind Geschmackssache, Apple-Keynotes habe ich zumindest mal so lange verfolgt, wie ich Apple-Aktien hatte. Die habe ich seit einer Weile nicht mehr und okay, ich will nicht schimpfen, der Gewinn beim Verkauf war beträchtlich.

Nach den ständigen Gerüchten der letzten Monate, dass Apple angeblich ein Billig-iPhone plane, um damit der Billigkonkurrenz mit Android-Betriebssystem Paroli zu bieten, horchte ich dann heute trotzdem genauer hin. Das iPhone 5C hätte das Potential, tatsächlich mit iOS und als billiges Gerät den Markt untenherum aufzurollen, in dem viele Hersteller mit Android tollen, teilweise auch mit recht emotionsarmen Geräten. Und vor allem hätte Apple die Chance, in Märkte hineinzukommen, die sich das metallene Original schlicht nicht leisten können.

Und was macht Apple? Sie verkacken es so, wie man es nur verkacken kann.

Denn: Der Plastikbomber in Form des iPhone 5C wird, so wie es derzeit aussieht, in allen Ausbaustufen (16 und 32 GB) gerade einmal 100 Euro billiger sein, als die des iPhone 5S, also dem iPhone-Flaggschiff. Und damit kostet das billigste iPhone 5C mit 16 GB Speicherausstattung immer noch knackige 599 Euro. Bei Google gibt es für 599 Euro das Google Nexus 4 (199 Euro) und das Google Nexus 7-Tablet (229 Euro) und man hat am Ende noch 171 Euro übrig.

Und selbst so Oberklasse-Gerätschaften wie das Samsung Galaxy S4 kosten derzeit etwas über 300 Euro. Will man es luxuriös, konkurriert der iPhone-Plastikbomber preislich zum Beispiel mit dem kommenden Android-Flagschiff Sony Xperia Z1, das ebenfalls in der 600-Euro-Klasse einsteigen wird, aber bei weitem besser ausgestattet ist.

Mit 599 Euro Einstiegspreis für das billigste iPhone hat Apple ein klares Statement gestellt. Das Segment der günstigen und mittelpreisigen Smartphones will man nicht betreten und diese Segmente weiterhin Android überlassen. Das schon jetzt über eine Milliarde aktivierte Geräte zählt und jeden Tag eine Million mehr. Dass iOS daran arbeitet, nächsten Monat die Hürde der 700 Millionen Aktivierungen zu reißen, ist da kein hoffnungsvolles Signal, sondern eine Kapitulation.

Synchronisation von Kontakten zwischen iPhone und Google Contacts via CardDAV.

Seit einiger Zeit gibt es im Funktionsumfang von normalen Google-Konten einen kleinen Einschnitt in Sachen Funktionsumfang. Dieser Einschnitt betrifft die Synchronisation von Daten zwischen dem Google Kalender und Adressbuch zu iPhone und/oder iPad. Konnte man nämlich Kalender und Adressbuch bei allen Konten bis dato per ActiveSync synchronisieren (dass unter iOS „Microsoft Exchange“ heißt und auf Seiten von Google „Google Sync“), so ist das seit 30. Januar 2013 nur noch für Google-Konten möglich, bei denen bis zu diesem Datum Google Sync mindestens einmal eingerichtet wurde. Mit allen Google-Konten, die nach dem 30. Januar 2013 mit iPhone/iPad Kontakte und Kalender synchronisieren sollen, ist dieser Weg nun versperrt.

Aber: Es gibt Alternativen. Und zwar sehr gute, weil nämlich mit offenen Protokollen.

Kalender synchronisieren

Dazu sei an dieser Stelle nicht viele Worte verloren, weil ich hierzu vor einiger Zeit schon mal einen sehr umfangreichen Artikel geschrieben habe, der den Installationsweg ausführlich beschreibt:

Aber jetzt: Kontakte synchronisieren via CardDAV

Das CardDAV-Protokoll gehört ebenfalls zur Familie der WebDAV-Protokolle und ist speziell auf die Synchronisation von Kontaktdatenbanken ausgerichtet. Die Synchronisationsmechanismen sind dabei ähnlich zu CalDAV bei Kalendersynchronisationen, grundsätzlich ist CardDAV aber ein eigenes und auch relativ neues Protokoll. So neu, dass es beim iPhone bzw. im iOS-Betriebssystem von Anfang an gar nicht im Funktionsumfang war. Erst ab iOS 5 wurde CardDAV standardmäßig in iOS implementiert und ist seitdem auch verfügbar. Die Einrichtung einer CardDAV-Verbindung zum eigenen Google-Konto ist dabei relativ simpel und auf keinen Fall schwerer, als bisher mit Google Sync.

Der Startpunkt auf dem iPhone sind, wie immer, die Einstellungen und dort der Punkt “Mail, Kontakte, Kalender”. Hier geht es auf “Account hinzufügen …”. Der nächste Schirm zeigt die möglichen Synchronisationstechnologien dazu an:

iOS Synchronisationsauswahl

Alle DAV-Protokolle finden sich im letzten Menüpunkt, der etwas stillos unter dem Wort „Andere“ versteckt ist. Deshalb bitte hier drauf tippen, um zum nächsten Schirm zu kommen:

iOS Auswahl der DAV-Protokolle zur Synchronisation

Hier geht es nun richtig los, unter „Kontakte“ findet sich die Auswahlmöglichkeit zur Einrichtung eines CardDAV-Accounts. Bitte diesen Menüpunkt antippen und dann geht es schon darum, die eigenen Zugangsdaten zu hinterlegen:

iOS Einrichtung CardDAV

Die vorzunehmenden Einstellungen sind weitgehend selbsterklärend, deshalb nur im Schnelldurchlauf:

  • Account: Muss selbstverständlich aktiviert werden, hier lässt sich später aber dann auch vorübergehend die Synchronisation anhalten, falls das mal notwendig sein sollte.
  • Server: Ist die Gegenstelle, mit dem das iPhone-Gerät Verbindung zur Synchronisation aufnehmen soll. Das ist tatsächlich einfach nur „google.com“.
  • Benutzername: Das ist der Google-Kontoname, also im Normalfall die eigene Gmail- bzw. Googlemail-Adresse.
  • Kennwort: Selbsterklärend.
  • Beschreibung: Das ist eine Beschreibung, die frei gewählt werden kann. Bei mehreren konfigurierten Konten auf dem iOS-Gerät macht eine eindeutliche Beschreibung durchaus Sinn…

Wir gehen jetzt aber noch nicht zurück (und drücken natürlich auch nicht auf „Account löschen“), sondern wählen noch den Menüpunkt „Erweiterte Einstellungen“ für einen Kontrollblick aus. Der dortige Schirm sieht folgendermaßen aus:

iOS CardDAV Erweiterte Einstellungen

Hier geht es um die Verschlüsselung der CardDAV-Übertragung. SSL sollte hier aktiviert werden, der Standard-Port hierzu ist 443.

Nach dieser Überprüfung oben auf den Pfeil nach links „Google Contacts“ (oder wie auch immer die Beschreibung lautet) tippen, um zum vorherigen Schirm zurückzukommen. Dort dann nochmal auf den an der gleichen Stelle positionierten Pfeil tippen, der da lautet „Zurück“. Danach geht es nämlich nicht sofort zurück, sondern dann wird zunächst der Account geprüft. Hat alles seine Ordnung, erscheinen hinter allen Eingabefeldern kleine Häkchen und der Synchronisationsaccount ist erfolgreich eingerichtet.

Bitte dann einfach wieder zurück auf den Home-Bildschirm und mit einem Tippser auf die Kontakte-App gleich mal austesten, ob nun die ersten Adressen aus dem Google-Konto – sofern dort welche hinterlegt sind – eintrudeln.

Der Weg der Synchronisation

Ein spannendes Thema kommt an dieser Stelle: Hat man nämlich bisher Google Contacts nicht genutzt und sein Adressbuch ausschließlich auf dem iPhone gepflegt, dann passiert auch nichts. iOS synchronisiert ein lokales Adressbuch nicht ohne weiteres mit einem Adressbuch, das mit einem externen Dienst synchronisiert wird.

Damit also eventuell auf dem iPhone vorhandene Adressbestände ins Google-Contacts-Adressbuch kommen, müssen diese dorthin einmalig übertragen werden. Am einfachsten funktioniert das mit der iOS-App namens „My Contacts Backup“, die das Adressbuch auf iPhone/iPad als CSV-Datei exportieren kann. Diese kann man sich dann bequem per E-Mail an das eigene E-Mail-Postfach schicken lassen.

Hat man dann diese CSV-Datei, lässt sich diese auf der Website von Google Contacts unter https://www.google.com/contacts/ (ggf. zunächst anmelden) importieren. Auf der Hauptseite gibt es oben mittig angeordnet einen Button namens „Mehr“ und in diesem Untermenü dann den Menüpunkt „Importieren“. Dort dann einfach die oben generierte CSV-Datei importieren und schon nach einigen Augenblicken stehen die exportierten Adressen in Google Contacts zur Verfügung.

Hilfe! Alles doppelt!

Tatsächlich kann es zunächst passieren, dass nach der ersten Synchronisation im iOS-Adressbuch alle Kontakte doppelt auftauchen. Insbesondere dann, wenn wie im letzten Absatz der bisher lokal verwaltete Adressbestand in Google Contacts importiert wurde. iOS verwaltet alle Adressbücher strikt getrennt voneinander, also damit auch das lokale Adressbuch getrennt vom Adressbuch, das nun per CardDAV synchronisiert wird. Dass es hier mitunter dann Dubletten gibt, juckt iOS herzlich wenig.

Meine Empfehlung ist da ganz klar: Wer jetzt sein Adressbuch mit CardDAV synchronisiert und auch die lokalen Kontakte in Google Contacts importiert hat, auch nur noch mit diesem Adressbuch arbeiten und die lokalen Kontakte ersatzlos löschen. Sie gehen ja, wenn sie in Google Contacts importiert wurden, nicht verloren, sondern werden jetzt eben über die Google Cloud synchronisiert und das macht technisch gesehen keinen Nachteil aus. Denn der Zugriff auf einen synchronisierten Adressbestand ist selbst dann möglich, wenn das iOS-Gerät vorübergehend z.B. keine Verbindung haben sollte. Eine eventuell notwendige Synchronisierung erfolgt immer dann, wenn eine Netzverbindung besteht.

Also: Wenn es tatsächlich Dubletten in Ihrem Adressbestand gibt, dann ist die Vorgehensweise folgende (Bitte machen Sie dennoch unbedingt sicherheitshalber ein Backup mit der obig empfohlenen App):

  1. Schalten Sie vorübergehend die Synchronisation mit allen fernen Adressbüchern aus, sofern welche vorhanden und diese aktiv sind. Das können Sie bequem in den Einstellungen der einzelnen Adressbuchsynchronisationen tun, in dem sie den Schieber vorübergehend auf den „Off-Zustand“ schieben (siehe oben).
  2. Wenn Sie dann alle Adressbuchsynchronisationen ausgeschaltet haben, gehen Sie in die Kontakte-App und sehen hier dann logischerweise nur noch die Adressen, die tatsächlich lokal auf dem iOS-Gerät liegen. Wenn das dann tatsächlich die eine Hälfte der Dubletten ist, können Sie alle die lokalen Adressen hier getrost löschen.

Und wie lege ich nun neue Kontakte an?

Das ist jetzt nämlich echter Komfort: Es ist egal, wo Sie neue Kontakte anlegen – ob nun im iPhone, auf dem iPad (falls es auch mit Google Contacts synchronisiert), auf der Website von Google Contacts oder mit einem anderen Programm oder Gerät, das mit Google Contacts synchronisiert – sie haben nur noch eine Adressdatenbank und das ist die bei Google Contacts.

Sie machen es jetzt also wie die Profis mit dem Adressbuch – in der Cloud. Und wenn Ihnen aus irgendeinem Grund das iPhone abhandenkommt (sie es von der Ferne aus natürlich sperren), ist Ihnen wenigstens nicht Ihr Adressbuch abhanden gekommen, denn das liegt eben nun in der Cloud.

iOS und Google Sync nur noch bis Ende Januar.

Da die Artikel zum Thema Google Sync und iPhone in meinem Blog die mit Abstand am häufigsten aufgerufenen Artikel sind, hier doch nochmal ein wichtiger Hinweis für alle, die zukünftig ihr iPhone oder iPod per Google Sync mit ihren Kalendern und Adressbüchern in ihrem Google-Account synchronisieren möchten. Denn Google Sync steht auf der Abschussliste bei Google und für viele Nutzer ist Google Sync ab 30. Januar 2013 nur noch Geschichte.

Google Sync und der technische Hintergrund

Das Ende von Google Sync ist relativ einfach zu erklären, wenn man sich anschaut, was dahintersteckt: Eine Synchronisierungstechnologie namens ActiveSync von Microsoft. Und dazu ist dann ein kleiner Exkurs recht interessant:

ActiveSync hat eine recht lange Geschichte und hat seine Wurzeln im Mobilbetriebssystem Windows Mobile und der Möglichkeit zur Synchronisieren von Smartphone-Inhalten mit Windows-Betriebssystemen ab Windows 95 und NT 4. Für diese Anforderung wurde ActiveSync entwickelt und das war schon zu den Zeiten, als Windows Mobile mit dem einst allmächtigen Betriebssystem PalmOS von US Robotics konkurrierte, revolutionär. Denn während Palm-Geräte im am PC angeschlossenen Zustand nur dann synchronisierten, wenn die Synchronisierung am Gerät oder an der Dockingstation (die „Cradle“) die Synchronisierung explizit der Knopfdruck gestartet wurde, erledigten Windows-Mobile-Gerätschaften die initiale Autorisierung direkt nach dem Anstecken an den PC und synchronisierten während der Verbindung permanent, selbstständig und zuverlässig. Wurde in Outlook ein neuer Termin eingetragen, erschien dieser Termin im gleichen Moment auch im angeschlossenen Windows-Mobile-Gerät. ActiveSync machte es möglich und nicht zuletzt diese Technologie war ein wichtiges Abgrenzungskriterium zur Palm-Welt.

Aufgebohrt wurde ActiveSync dann später, in dem das Protokoll als Basis für die Synchronisierung zwischen Windows-Mobile-Geräten und dem Microsoft-Exchange-Server diente und fortan Exchange ActiveSync hieß. Das Prinzip der Echtzeitsynchronisierung blieb, lediglich der Übertragungsweg und die Gegenstation änderte sich. Nicht mehr der Bürorechner auf dem Schreibtisch war das andere Ende, sondern der Exchange-Server des Unternehmens, der dann die zu synchronisierten Inhalte direkt mit dem Postfach des Nutzers synchronisierte.

Und obwohl ja Microsoft verschrieen ist als ein Unternehmen, das rücksichtslos seine eigenen Standards entwickelt und verbreitet – ActiveSync hatte schon sehr früh eine relativ offene Lizenzierungspolitik und konnte von Herstellern von Personal Digital Assistants, später dann Smartphones, aber auch Herstellern von Mailsystemen und Betreibern von Maildiensten (kostenpflichtig) lizenziert werden. Das hatte natürlich einen Hintergrund, denn neben den Einnahmen durch die Lizenzierung war durch den Einsatz von ActiveSync potentiell das jeweilige Produkt auch fähig zum Kontakt mit Windows-Mobile-Gerätschaften oder auf der anderen Seite mit dem Exchange-Server.

Und da ergaben sich dann die seltsamsten Allianzen. Während z.B. RIM mit dem Blackberry und dem dazugehörigen Protokoll sowohl Endgeräte als auch Synchronisierungssoftware mit dem Mailsystem aus einer Hand liefert, können z.B. iPhone und Android-Geräte per ActiveSync mit dem Exchange-Server synchronisieren. Vorteil: Diese Synchronisierung kostet den Nutzer nichts, während bei Blackberry lange Zeit der Synchronisierungsdienst Geld kostete und zwar nicht zu knapp. Dass also ActiveSync so zuverlässig funktioniert und für Hersteller von Smartphones recht freizügig lizenziert werden kann, ist mit einer der Gründe, warum Microsoft lange Zeit die eigene Mobilbetriebssystemstrategie hat schleifen lassen und es hat ihnen zumindest im Business-Bereich nicht sonderlich viel finanziellen Schaden beschert. Das Lehrgeld in der Smartphone-Jungsteinzeit haben tatsächlich andere bezahlt.

Google und ActiveSync

Auch Google gehört zu den ActiveSync-Lizenznehmern und das wiederum aufgrund einiger Umstände:

  1. Google benötigt ActiveSync im hauseigenen Mobilbetriebssystem Android, um Android-Handys mit der Exchange-Welt synchronisieren lassen zu können.
  2. Google muss seine eigenen Kalender- und Kontaktedienste mit Schnittstellen zu ActiveSync ausstatten, um Smartphones mit anderen Betriebssystemen als Android eine Synchronisierung zu ermöglichen. Dies gilt insbesondere für das iPhone, denn obwohl das iPhone direkt (ohne ActiveSync) mit Google Mail synchronisieren kann, wird ActiveSync wiederum zum Synchronisieren von Kalender und Kontakten benötigt, da das iPhone hier keine eigenen Schnittstellen zu den Google-Diensten hat (warum auch immer).

Punkt 2 muss man sich ob des Irrsinns auf der Zunge zergehen lassen – weil Apple und Google zu doof sind, iOS und Google-Dienste vollständig miteinander synchronisieren lassen zu können, muss ausgerechnet ein lizenzpflichtiges Microsoft-Protokoll den Lückenfüller machen.

Und weil genau das Kostenthema der ActiveSync-Lizenzierung für die (kostenlos nutzbaren) Google-Dienste eine Rolle spielen dürfte, ist ActiveSync nun wohl bei der Synchronisierung der Google-Accounts auf der Abschussliste. Immerhin gibt es aber einige begrenzende Ausnahmen für das Ende:

  • Wird ein Google-Account bis zum 30. Januar 2013 noch mit ActiveSync synchronisiert, bleibt diese Möglichkeit für diesen Account auch darüber hinaus noch erhalten. Das Ende gilt also ab 30. Januar 2013 nur für bis dato noch nicht per ActiveSync synchronisierende Google-Accounts. Inwiefern es bis zu diesem Datum tatsächlich aktiv genutzt werden muss oder ob die Nutzung irgendwann in der Vergangenheit schon ausreicht, wird sich zeigen.
  • Ebenfalls nicht betroffen von dem Ende sind Google-Accounts, die innerhalb der inzwischen auch kostenpflichtigen Google Apps angelegt sind. Google-Apps-Accounts werden also auch weiterhin per ActiveSync synchronisieren können und wer da noch das Glück hatte, in der vergangenen Kostenlos-Zeit einen Google-Apps-Account einzurichten, lebt immer noch komplett kostenlos.

Die kostenlosen Protokollalternativen zum Synchronisieren

Google beendet das Synchronisieren mit ActiveSync vor allem auch deshalb, weil es inzwischen kostenlose Protokolle zum Synchronisieren gibt, die auch hinreichend zuverlässig sind. Für das Synchronisieren von Kalender ist dies das CalDAV-Protokoll und für das Synchronisieren von Kontakten das CardDAV-Protokoll. Beide Protokolle sind (inzwischen offizielle) IETF-Standards und im Falle von CardDAV eine beschwerliche Geburt hinter sich.

Das ist auch einigermaßen nachvollziehbar, denn ein einheitlicher, herstellerübergreifender Standard liegt zunächst einmal nicht im Interesse der Hersteller von eigenen, proprietären Protokollen und da lange Zeit die Motivation an echten freien Protokollen fehlte, dauerte es auch dementsprechend, bis beide Protokolle jeweils die Hürden genommen hatten, um als IETF-Standard zu gelten – zumal alle involvierten Hersteller innerhalb der IETF auch an der Standardisierung beteiligt waren. Das Wort „Sabotage“ will niemand in den Mund nehmen, aber IETF-Standardisierung ist mitunter auch interessant für Beobachter, die sich für Rudelbildungen im Tierreich interessieren.

Was zu tun ist … Empfehlungen

Also, grundsätzlich: ActiveSync muss niemand unbedingt einsetzen, der auch CalDAV und CardDAV einsetzen kann. Beide Protokolle sind gleichwertig funktional, wenn es um die Synchronisierung von Kalender- und Kontaktdatenbanken geht. Selbstverständlich ist ActiveSync deutlich mächtiger, allerdings richten sich viele Funktionen von ActiveSync vornehmlich an Unternehmen, die z.B. in einer Exchange-Infrastruktur alle Arten von Clients – vom Windows-Rechner mit Outlook bis zum iPhone – synchronisieren und zentral verwalten müssen.

Innerhalb von Google-Diensten ist ActiveSync bzw. der eigene Name „Google Sync“ immer als bisher mehr oder weniger notwendige Alternative zu verstehen. Es besteht also kein Grund zur Panik und auch nicht zu übermäßiger Hektik in Sachen Synchronisierungen zum Google-Konto einrichten. Wer bis zum 30. Januar 2013 Google Sync bzw. ActiveSync nicht einsetzt, wird es auch danach nicht vermissen, den selbst das iPhone, die Ausgeburt an Apple-Scheuklappentum in Sachen offenen Standards, unterstützt CalDAV und CardDAV

Zu erledigende Aufgaben für Besim

Das inzwischen gewachsene Sammelsurium an Blog-Artikeln, die sich mit der Synchronisierung zwischen Google-Konto und iPhone beschäftigen, aktualisieren. Die Artikel, die Google Sync erklären, werden mit Hinweisen darauf versehen, dass Google Sync nicht mehr bei allen Arten Google-Accounts funktioniert, der Artikel zu CalDAV so überarbeitet, dass es wieder als Empfehlung gilt und ein Artikel zu CardDAV neu geschrieben, das ich bisher großflächig ausklammerte, weil die CardDAV-Unterstützung von Google vor zwei Jahren, als ich das erste und bis dato letzte Mal in dieser Konstellation mit CardDAV experimentierte, schlicht unmöglich war.

Manchmal hilft die wohltuende Wirkung der Zeit doch, dass Hersteller sich ihren Möglichkeiten zur Interoperabilität bewusst werden.

Obama 2012 – Der Wandel von der App zur Web-App.

Eigentlich sollte dieser Artikel eine Fragestellung erörtern. Nämlich die, ob es in einem Wahlkampf sinnvoll ist, eine eigene Smartphone-App zu haben oder ob man lieber auf eine Web-App setzt, also eine Website, die funktional und optisch auf Smartphones so aussieht, als ob sie eine App wäre. Die Wahlkampf-Website so eine Web-App-fähige Website, die in einem responsive Webdesign erstellt ist und deren Ansicht sich der Bildschirmgröße des anzeigenden Gerätes anpasst.

Begonnen wurde die Obama-2012-Kampagne 2011 auch mit einer eigenen App für Smartphones, genauer gesagt für das iOS-Betriebssystem von iPhone und iPad. Als ich nun darüber bloggen wollte, stellte sich heraus, dass diese App schon seit längerer Zeit nicht mehr zur Verfügung steht. Und der Grund dazu ist herzlich einfach: Es gibt keine Notwendigkeit dafür.

Historische Ansichten in die Obama-2012-App.

Die Obama-2012-App als besonderes Highlight zu bezeichnen, wäre vermessen. Vom Prinzip her ist das Konzept das eines betriebseigenen Kiosks und keine der Inhalte, die in dieser App abgerufen werden können, sind wirklich exklusiv, da sie auch auf der Wahlkampf-Website zu finden sind. Die Startseite der App verweist schon auf alle Bereiche in der App:

„Latest News“ führt auf einen Nachrichtenbereich, der exakt dieselben Nachrichten enthält, wie auf dem offiziellen Wahlkampf-Weblog. Mit einem Tippser auf eine Nachricht lässt sich diese dann lesen:

Die Rubrik „Photos & Videos“ stellt auf einem Bildschirm eine Übersicht über Bilder und Videos im Wahlkampf zusammen:

Während die Videos recht anschaubar sind, sind die Fotos reine Makulator und eigentlich unansehnlich, weil völlig pixelig. Zudem fehlt jegliche Sortierung, so dass diese Bilderwand nicht viel mehr als Show ist:

Interessanter, aber auch nicht wirklich weltbewegend neu ist die Rubrik „Events“, die, wenn man der App in den Einstellungen den aktuellen Standort in Form des US-ZIP-Codes spendiert hat, passend zum aktuellen Ort die nächsten Events anzeigt. In meinem Beispiel wohnte ich z.B. im beschaulichen Honolulu auf Hawaii. Mit einem Tippser auf die Stecknadel lassen sich nähere Informationen zum jeweiligen Event anzeigen:

Dinge, die gegen und für eine App sprechen.

Tatsächlich war es eine gute Entscheidung, diese App nicht wirklich in den Wahlkampf mitzunehmen und schon nach wenigen Monaten einzustampfen, bevor wirklich Befürworter und Wähler mit dieser App enttäuscht werden könnten. Denn der Mehrwert gegenüber einer mobil gut erreichbaren Seite ist nahe Null. Mit einer Ausnahme, weshalb diese App vermutlich einst auch entwickelt wurde: Der Push-Service von iOS, der für die Verteilung der Nachrichten eingesetzt wurde. Mit dem Push-Service wurde wohl die Idee verfolgt, bei Neuigkeiten direkt über den Push-Service den Besitzer des iOS-Gerätes zu informieren.

Rein faktisch gesehen ist das aber nicht notwendig, weil neue Nachrichten im Wahlkampf-Weblog auch über die Twitter-Kanäle von Barack Obama angekündigt werden und hier mit vielen Twitter-Clients und dem Konfigurieren von bestimmten Regeln ein Push-Service einsetzen lässt. Oder auch über Facebook oder über gutes, altes Syndizieren via RSS-Feed.

Dass bei Barack Obama dennoch nicht auf ein Home-Symbol verzichtet werden muss, lässt sich anschaulich beobachten, wenn die Wahlkampf-Website mit Safari unter iOS (iPad und iPhone) aufgerufen wird. Tippt man dort (iOS 6) auf das Weiterleiten-Symbol, erscheint folgendes Menü und da ist der mittlere Button genau die gewünschte Ansage:

Bei solchen Apps darf man einen Punkt nicht verheimlichen: Wo App draufsteht, ist meist nicht viel mehr drin, als ein Webbrowser. Das gilt auch für die einstige Obama-2012-App und für viele andere Apps für SmartPhones, die lediglich aus Prestigegründen in Form einer App daherkommen, hinter den Kulissen aber die meisten Inhalte online aus dem Web beziehen.

Eine Web-App bzw. ein Widget ist die einzig konsequente Antwort für solche Informationsdienste, da so mit gängigen Technologien wie HTML 5, JavaScript und dem Document Object Model (DOM) ein wirklich plattformübergreifendes Angebot geschaffen werden kann, das auf allen gängigen Smartphone-Umgebungen von Hause aus läuft.

Mitt Romney geht App.

Das Team um Mitt Romney fährt nach wie vor eine App-Strategie und ist sogar mit zwei eigenen Apps im iOS-AppStore vertreten:

Die App „Romney-Ryan“.

Diese App ist die offizielle App und stellt sich wohl als Antwort auf die einstige „Obama-2012-App“ dar. Und leidet genau unter den Krankheiten, die funktionsarme Apps von Hause aus haben – außer Prestige liefert die Apps nur Inhalte, die auf der Wahlkampf-Website von Mitt Romney sowieso zu finden sind:

Die Frage, warum das Team Romney auf Apps setzt, hat wohl mehrere Gründe und zeigt sehr schön, dass auch beim Verständnis in Sachen Mobile Computing das Team Romney nicht ansatzweise die gängigen Möglichkeiten ausschöpft:

  • Eine App gilt als schick und modern, während eine Website als „zu normal“ gilt – zumindest bei Menschen, die Smartphones und Mobile Computing vornehmlich als Statussymbol ansehen und weniger für echte Kommunikation. Das Herunterladen einer App aus dem AppStore und das Erscheinen eines eigenen App-Symbols auf dem iPhone-Home-Bildschirm ist nun einmal auch eine Art von Marketing.
  • Zur Informationsvermittlung sind zwar Web-Apps gegenüber echten Apps weitgehend ebenbürtig, allerdings nur bei kommunikativen Anwendungen. Spiele und Anwendungen, die auf besondere Hardware eines Smartphones setzen wie z.B. die Kamera sind (derzeit zumindest) nur als App realisierbar. So hat ausgerechnet die ansonsten sinnfreie „With Mitt“-App durchaus ihre Berechtigung, weil die Kamera- und Bildbearbeitungsfunktion derzeit nur in einer App zu realisieren ist.

Die Nachteile der App-Strategie finden sich im Team Romney auch gleich und zwar alle zusammen:

  • Die Wahlkampf-Website ist nicht mit einem responsive Webdesign erstellt und kennt nur eine Bildschirmgröße. Für mobile Webbrowser ist daher eine Weiche im HTML-Code eingebaut, die diese dann auf einen Server namens m.mittromney.com“ schickt, auf der explizit eine mobile Website gehostet wird, die allerdings reichlich umständlich zu bedienen ist.
  • Eine App funktioniert natürlich nur auf der Plattform, für die sie entwickelt wurde. Im Falle der Romney-Apps gibt es nur Versionen für iOS-Betriebssysteme und z.B. nicht für Android. Zwar können andere Betriebssysteme über dort installierte Webbrowser dennoch auf die mobilen Websites zugreifen, allerdings ist eine App-Strategie, die nur auf einzelne Plattformen zielt, eben nur eine unvollständige App-Strategie.

Die App „With Romney“.

Diese App ist nicht sonderlich ernstgemeint (hoffentlich zumindest!) und dient zur Erzeugung von „Unterstützerplakaten“ aus eigenen Fotos. So kann der iPhone-Besitzer oder auch das zum Besitzer korrespondierende Haustier seine innige Zuneigung zu Mitt Romney mitteilen:

Ob so eine Nonsens-App, die sehr an die Idee mit dem „Hope“-Plakaten im Wahlkampf von Barack Obama im Jahr 2008 erinnert, tatsächlich neue Wählerschichten erschließt, darf bezweifelt werden. Eine eh schon schlechte Smartphone-Strategie wird dadurch jedenfalls nicht automatisch besser.


Alle Teile meines Dossiers zu Obama 2012 unter dem Stichwort „Obama 2012“.

Die mobile Halbherzigkeit von Apple Safari in Sachen FTP.

Ich habe mehr oder weniger aus Jux und Dollerei gerade einmal probiert, ob der Mobile Safari, der Webbrowser auf iOS-Gerätschaften, FTP beherrscht. Und tatsächlich, ich war sehr gut beraten, die ansonsten eigentlich schon prädestine, museale Ausstattung des Mobile Safari nicht in einer Wette dazu zu nutzen, eine Gegenwette abzuschließen. Denn tatsächlich beherrscht der Mobile Safari FTP. Allerdings, und da bleibt sich Apple treu, so bescheuert schlecht, dass es doch schon wieder alle Vorurteile erfüllt.

Als Webbrowser FTP zu können, ist leichter gesagt, als getan. Denn im Gegensatz zum Web ist FTP vor allem eine Geschichte, die für gewöhnlich passwortgeschützt passiert. Hier mal mein Setup:

Meine Fritzbox hat einen angeschlossenen USB-Stick, das ich als Speicherlaufwerk einsetze. Mit der VPN-Funktionalität der Fritzbox habe ich auf diese Weise eine ziemlich praktische Home-Cloud, die ich aus dem Internet problemlos erreichen kann – per VPN und innerhalb meines LAN dann per SMB („Windows Netzwerk) oder auch per FTP. Im Webbrowser gebe ich für diesen Zugriff einfach ein:

ftp://fritz.box/

Normale Webbrowser probieren den FTP-Zugriff und bekommen dann von meiner Fritzbox die Rückmeldung, dass der FTP-Zugriff nicht anonym erfolgen kann, sondern Zugangsdaten erforderlich ist. Normale Webbrowser kennen dieses Verhalten und fordern den Benutzer mit einem Passworteingabefeld auf, Zugangsdaten einzugeben, mit denen dann der FTP-Zugriff nochmals durchgeführt werden kann, nun eben mit Authentifizierung.

Für Apple scheint dies völlig neu zu sein. Denn gebe ich einfach die obige Adresse ein, fragt mich der Mobile Safari nicht etwa nach Zugangsdaten, sondern lässt mich im Regen stehen:

Keine Zugriffsrechte
Sie haben nicht die erforderlichen Zugriffsrechte, um „/“ anzuzeigen.

Darauf wäre ich gar nicht gekommen.

Allerdings sind wir ja nicht vollkommen blöd, sondern wissen ja, wie das URL-Schema funktioniert. Und das URL-Schema hat feste Regeln, wie man neben einer Adresse auch Zugangsdaten übermittelt:

ftp://benutzername:passwort@fritz.box

Und siehe da: So funktioniert das sogar im Mobile Safari, danach bin ich auf meinem Speicherlaufwerk und kann Dateien herunterladen.

Eine ganze Reihe von Nachteilen gibt es, allesamt Mobile-Safari-Schwächen:

  • Es wird nur FTP unterstützt, nicht die verschlüsselte Variante SFTP. Das ist freilich nur ein „weiches“ Problem, denn SFTP unterstützen auch andere Webbrowser nicht. Damit ist der FTP-Zugriff per Webbrowser immer eine Geschichte, die man, wenn es um sensible Daten geht, nur mit einer zusätzlichen Transportverschlüsselung machen sollte. Da der FTP-Zugriff zu meiner Homecloud nur innerhalb meines LAN funktioniert und ich vom Internet aus zwangsläufig ein VPN nach Hause benötige, ein in diesem Szenario vernachlässigbares Problem.
  • Mobile Safari kennt zwar das URL-Schema und die Art und Weise, wie in diesem Schema Zugangsdaten übermittelt werden, allerdings ist die Umsetzung halbherzig. Denn den obigen URL mit integriertem Passwort kann ich so nicht als Lesezeichen hinterlegen, sondern würde gern folgendes als URL verwenden:ftp://benutzername@fritz.boxMit diesem URL können nämlich alle anderen, FTP-fähigen Webbrowser etwas anfangen und fragen nur noch das Passwort ab, das für den Zugriff notwendig ist. Mobile Safari kann mit diesem URL nichts anfangen.
  • Sehr, sehr wichtig: Mobile Safari führt, so wie jeder andere Webbrowser auch, einen URL-Verlauf, in dem alle aufgerufenen URL der letzten Zeit gespeichert werden. Leider speichert Mobile Safari hierbei auch Adressen, in denen sich Benutzernamen und/oder Passwörter befinden. Um das zu verschmerzen, gibt es zwei Möglichkeiten. Das so genannte „private Surfen“ in den Safari-Einstellungen aktivieren oder an der gleichen Stelle den Verlauf löschen. Ist leider relativ umständlich, weil beide Dinge nicht direkt im Mobile Safari vorgenommen werden können, aber leider nicht unwichtig, wenn man sensible Zugangsdaten nicht im Verlauf herumspazieren möchte.

Nun gut, immerhin kann Mobile Safari FTP-Zugriff so auch mit Zugangsdaten, wenn auch auf eine ziemlich vorsintflutliche Weise. Schön sehen die Dateiauflistungen auch nicht aus, aber technisch funktioniert es und ich kann Inhalte aus meiner Homecloud auf iPhone/iPad herunterladen.

1.000 Tage.

1.000 Tage sind in etwa der Zeitraum, in denen Hersteller von Mobiltelefonen die Firmware von Smartphones pflegen. Dabei ist „pflegen“ ein sehr dehnbarer Begriff, bei dem sich die meisten Hersteller strikt darauf beschränken, aus der initial verteilten Firmware die Bugs herauszuoperieren und maximal nur sehr moderate Erweiterungen zu integrieren. Man will ja den Kunden nicht dadurch verlieren, dass er so zufrieden mit seinem Gerät wird, dass er kein neues Smartphone mehr kauft.

Zusammenprall der Welten

Tatsächlich leidet unter diesem Zusammenprall der Welten Google mit seinem Betriebssystem Android am meisten. Android hat einen vergleichsweise hohen Entwicklungsschub, was für Google typisch ist. Wird in ein Produkt von Google Energie hineingesetzt, dann hochkonzentriert und stark. Das ist für einen Software-Hersteller natürlich kein so wirklich großes Problem, denn Software-Herstellung verläuft deutlich weniger „schweinezyklisch“, wie Hardware-Herstellung. Ist ein Bug in der Software, wird er eben gefixt. Das Internet unterstützt dieses Paradigma zudem. Ein Software-Update ist heute – wenn überhaupt – nur noch einen Klick weit entfernt.

In Sachen Hardware-Fertigung sieht das alles noch ganz anders aus. Planung, Entwicklung, Kalkulation, Fertigung, Verkauf, Distribution sind alles Dinge, die aufeinander aufbauen, gehörige Vorbereitungen und gewaltigen Einsatz in Sachen Finanzierung und Personal bedeuten und jeder Schritt muss passen. Die Software des Smartphones ist der Teil eines solchen Spektakels, mit dem der Endanwender am meisten Spaß oder Ärger hat, dementsprechend konservativ gehen Hardware-Hersteller mit diesem Thema um. Diese konservative Vorgehensweise der Hardware-Hersteller ist dann auch das zentrale Problem von Android, denn es gibt keinen einheitlichen Rollout einer Android-Version. Und noch viel schlimmer ist, dass Interimsversionen, die vornehmlich Bugfixing als Ziel haben, ebenfalls teilweise stark verzögert auf Smartphones landen – wenn überhaupt.

Auch wenn die Android-Entwicklung und spätere Anpassung auf Smartphones eine Geschichte ist, die man eben nicht mal so nebenbei erledigt: Der Konsument hat dafür immer weniger Verständnis und so bald sich der (gern subjektive) Eindruck breitmacht, dass ein Mobiltelefon in Sachen Software nicht gut gepflegt ist, ist der Wechsel zu einem anderen Mobiltelefon tatsächlich nicht mehr weit. Und noch viel schlimmer: Hat sich so ein Eindruck beim Endkunden manifestiert, ist nicht nur der Smartphone-Hersteller in seinem Ruf hier beschädigt, sondern auch gleich noch Android.

Apple, ja Apple

Besitzer von iPod, iPhone und iPad sind es gewohnt, in regelmäßigen Abständen Firmware-Updates zu bekommen, die allesamt sitzen und praktisch keine Kompatibilitätsprobleme aufweisen. Das ist auch verhältnismäßig einfach zu bewerkstelligen, denn Apple baut hier eine Software auf die eigene Hardware und hat von der Hardware auch verhältnismäßig wenig Versionen zu berücksichtigen.

Aber auch hier gilt die 1.000-Tage-Regel und spätestens nach dem letzten Update der Firmware beginnt ein Smartphone, an Nutzen zu verlieren. Immer mehr Hersteller von Apps berücksichtigen alte Firmware-Versionen nicht mehr und von weiteren Entwicklungen sind natürlich auch die hauseigenen Apps wie Webbrowser und Mail-Programm betroffen. Damit könnte man ja noch leben, aber das größte Problem bei so einem definierten Ende des Produktzyklus sind später entdeckte Fehler und Bugs. Die fixt für so abgekündigte Produkte natürlich auch keiner mehr. Lost in Translation.

Entkoppelung von Hard- und Software

Wäre es nicht schön, wenn es mir egal sein könnte, ob Samsung für mein wunderbares Galaxy S2 zukünftig Softwareupdates liefert oder nicht? Immer ein Smartphone zu haben, das eine aktuelle Software so lange einsetzt, wie ich das möchte, unabhängig davon, ob Samsung nun den Support einstellt oder nicht? Traum? Ich persönlich glaube, dass die Zeiten der Koppelung von Hard- und Software auf Smartphones zukünftig eher Ausnahmen sein werden. Okay, Apple wird sich aus religiösen Gründen nicht davon trennen (können), die Software-Entwicklung aus der Hand zu geben, aber alle anderen Smartphone-Hersteller, die kein eigenes Betriebssystem einsetzen? Ein Traum, ein Smartphone mit entkoppelter Hard- und Software zu haben?

Nein, kein Traum, sondern Realität. Und wenn man es genau nimmt: Schon seit Jahren.

„Firmware-Cooking“

Dass bei Smartphones Software immer der Hardware hinterherhinkt, ist kein Phänomen, das erst mit Android auf die Welt kam. Windows Mobile hat daran in seiner Inkarnation in Version 5 und 6 ständig gekrankt. Der Hauptgrund war, dass Windows Mobile in Version 5 und 6 zwar ein leistungsfähiges, aber ein hoffnungslos veraltetes Betriebssystem war und quasi alles, was machbar war, dadurch verhagelte, dass es nur schwer zu bedienen war. Dazu kam ab Version 6 die aufkommende Touch-Bedienung, die vornehmlich HTC mit Windows Mobile zu implementieren versuchte und dazu eigene Software-Module beisteuern musste. So entstanden zwar hardware-technisch recht ausgereifte Geräte, die jedoch durch Windows Mobile unglaublich katastrophal zu bedienen waren.

Schon zu dieser Zeit, wir schreiben da den Zeitraum von 2005 bis 2007, gab es Menschen, die „eigene“ Firmware-Pakete „kochten“. Dazu nahmen sie bestehende Update-Pakete, extrahierten daraus die Treiber und gerätespezifischen Anpassungen und backten diese in offizielle Windows-Mobile-Distributionen ein. Natürlich alles hochgradig illegal und oft auch in zweifelhafter Qualität, aber Microsoft verstand bemerkenswert gut, dass diese halblegal-illegale Subwelt gar nicht schlecht war, denn immerhin benutzten sie Windows Mobile und kauften solche Geräte auch, so dass die Betriebssystemabgabe schon beim Kauf des Gerätes geleistet wurde. Die ganzen Köche, die in ihrer Freizeit Firmwares auf Basis von Windows Mobile backten, bekamen auffällig wenig Ärger von Microsoft und wurden, glaubt man Gerüchten, teilweise sogar direkt von Microsoft mit Insiderinformationen und internen Dokumentationen versorgt, um etwaige Fehler in der Do-it-yourself-Firmware auszumerzen.

Wenn man will, war dieses Hobbykochen der erste Schritt zu dem, wie ich mir die Smartphone-Welt zukünftig vorstelle.

Firmware als Abo-Modell

Ich bin inzwischen überzeugt davon, dass der Versuch von Smartphone-Herstellens, Hard- und Software weiterhin aus einer Hand anzubieten, zukünftig immer weniger funktionieren wird. Schon heute ist der Produktezyklus sehr hoch und während heute ein Hersteller ein Smartphone einer bestimmten Preisklasse neu verkauft, ist die nächste Generation in der konkreten Entwicklung und die übernächste in der Planung. Und auch schon heute kommt die Software-Entwicklung kaum noch nach, so dass die ersten Versionen einer Firmware oft genug noch Beta sind, wenn man sie knallhart nach gängigen Qualitätssicherungskriterien bewerten würde.

Im Gegenzug könnten sich Hersteller von Smartphones, wenn sie sich nur noch auf Hardware beschränken würden, wieder auf das beschränken, was sie eigentlich wirklich gut können – gute Hardware bauen. Vernünftige, ausgewogene Leistungsdaten und durchdachte Schnittstellen, sowohl zur Firmware, als eben auch über die Bedienelemente zum Benutzer.

Die Software wiederum ist in einem Abo-Modell bestens aufgehoben. Wer eine Basis-Firmware braucht, dem genügt vielleicht schon eine ganz einfache Firmware, die weitgehend nur das Telefonieren ermöglicht. Wer Wert auf ausgefeilte Funktionen und Feintuning legt, wird sich am ehesten auch darauf einlassen, für so eine Firmware Geld auf den Tisch zu legen, wenn denn eben auch sichergestellt ist, dass die Software mit dem Gerät funktioniert und im Idealfall auch harmoniert.

Utopie? Schwer zu sagen. Es müsste einfach mal ein Hersteller offensiv probieren. Dass man sich in der Hardware-Welt dem Thema nicht verschließt, beweisen SonyEricsson und Samsung, die dem bemerkenswerten CyanogenMod-Projekt, das für viele Geräte eine ausgereifte Android-Distribution zur Verfügung stellt, die jeweils aktuellen Smartphones zu Entwicklungszwecken zur Verfügung stellt. Der nächste, konsequente Schritt wäre die Monetarisierung eines solchen Vertriebsmodells als Firmware-Abo. Wer sich da als erster traut, wird – meiner Meinung nach – nicht enttäuscht werden.

Google Tasks auf iOS und Android.

Einer der Dinge, die mich  von Anfang an in Apples Mobilbetriebssystem iOS und auch in Android gestört haben, war eine fehlende ToDo-Verwaltung. Es ist mir unverständlich, wie man ansonsten alle PIM-Anwendungen wie Kalender, Kontakte, Notizzettel integrieren kann, dann aber eine simple ToDo-Verwaltung außen vor lässt.

Das Ergebnis auf beiden Plattformen ist dementsprechend desolat: Es blühen die Todo-Anwendungen von Drittanbietern und sie blühen in der Regel mehr schlecht als recht. Die eine Gruppe an solchen Apps macht es mit der Verwaltung entweder zu einfach oder viel zu kompliziert, die meisten Apps synchronisieren mit keinem gängigen Dienst und die wenigsten Apps sind kostenlos und im Gegenzug dafür sogar richtig unverschämt teuer. ToDo-Verwalten für 5 oder gar mehr Euro?

Meine private und geschäftliche ToDo-Verwaltung läuft unter Google Tasks, das von Google bis vor kurzem noch ziemlich stiefmütterlich behandelt wurde, inzwischen aber sogar eine offizielle API hat. Wenn man mit dem Umstand lebt, dass Google Tasks kein eigenes Webinterface hat und derzeit nur via Google Mail oder über ein Widget in iGoogle bedienbar ist, kann man damit ganz gut leben. Seine Klasse spielt Google Tasks schon allein dadurch aus, dass es extrem simpel ist und die Verschachtelung von Aufgaben einfach dadurch realisiert, in dem Aufgaben einfach „unter“ bestehende Aufgaben geschoben werden und mit frei definierbaren Aufgabenkategorien gearbeitet werden kann. An umfangreiche Priorisierungen hat man einfach keinen Gedanken verschwendet, das realisiert man einfach durch das Verschieben von Aufgaben nach oben oder nach unten oder vergibt Aufgaben einen festen Fälligkeitstermin. So einfach kann es gehen.

Wenn man Google Tasks mit einer iOS- oder Android-App synchronisieren will, fällt glücklicherweise der größte Teil der ToDo-Apps gleich durchs Raster – die meisten nutzen Google Tasks nicht zum synchronisieren. Das macht die Auswahl dann auch gleich leichter. Gelandet bin ich dann bei zwei Apps namens „GoTasks“. Witzigerweise heißt nämlich die beste App für die Synchronisierung von Google Tasks für iOS genauso wie die App für Android, obwohl beide Apps miteinander nichts zu tun haben und jede App von einem anderen Programmierer gepflegt wird, die dann wiederum aber beides Russen sind. Zufälle.

Beide Apps kosten nichts, beide sind werbefrei, beide funktionieren sowohl auf Smartphones, als auch auf Tablets und beide funktionieren zuverlässig, auch mit Google-Apps-Konten:

Einen kleinen Wermutstropfen gibt es lediglich für GoTasks für Android: Offenbar lässt sich die App nicht auf allen Android-Gerätschaften finden. Auf meinem Samsung Galaxy S2 mit Android 2.3.4 ist es nicht auffindbar und im Web-Market wird angezeigt, dass mein Gerät nicht kompatibel sei. Es funktioniert aber, wenn man die App schon vorher installiert hat, sie ist also soweit kompatibel. Falls jemand mit Android die App nicht findet, bitte einfach mal kurz melden.

E-Mail 2.0.

(Gleich eine Vorwarnung an den geneigten Leser: Ein technischer, spezieller Artikel zu Google Apps und E-Mail-Migration. Darf man gern bis zum Ende lesen, wenn man sich dafür interessiert, muss man aber nicht, wenn nicht. ;-))

Nachdem ich nach RSS-Reader, Kalender und Kontaktedatenbank alle mir wichtigen Organisationsdinge in die „Cloud“ bei Google eingebracht habe und das alles sogar zuverlässig mit dem iPhone synchronisiert, war es nun mehr als notwendig, dass das älteste Relikt meiner Online-Identität diesen Weg ebenfalls geht – die gute, alte E-Mail.

Bis dato habe ich E-Mails per IMAP abgerufen, sowohl auf dem PC, als auch auf dem Notebook und dem iPhone. Das ist insofern praktisch und brauchbar, weil ich E-Mails nicht überall herunterladen muss, sondern quasi in die Mailbox hineinschauen kann. Wirklich heruntergeladen habe ich E-Mails traditionell immer nur am heimischen PC, auf dem ich dann alle ein- und ausgehenden E-Mails nach Jahrgängen archiviert. Technisch also alles kein Problem. Allerdings organisationstechnisch.Das Problem ist nämlich immer wieder, dass ich am Notebook auf ältere E-Mails zurückgreifen müsste, das aber nicht kann, weil die eben auf dem PC liegen. Sicherlich, ich kann den PC per Wake-on-LAN hochfahren, mich remote einloggen und das tun, was getan werden muss, aber es ist umständlich.

Ein zusätzliches Thema bei einer Migration: Der Umfang meiner Mailarchive. Die gehen zurück bis 1997, enthalten rund 45.000 E-Mails und belegen knapp einen Gigabyte an Speicherplatz. Früher einmal war das eine Herausforderung, heute ist das eher eine Bürde. Denn 1 Gigabyte lässt sich in jeder modernen Festplatte bequem einbunkern, allerdings hat das Archivieren solcher E-Mail-Berge ganz andere Anforderungen: Lesbarkeit der Archive, Durchsuchbarkeit und vor allem Datensicherung. Ich schlenkere Mailarchive auf meiner normalen Festplatte herum, auf meiner NAS und sicherheitshalber nochmal auf einem externen Datenträger. Das ist alles schön und gut, aber im Cloud-Zeitalter einfach Käse.

Google Apps als Lösung.

Der Einsatz von Google Apps war schon seit langem eine Überlegung und wurde jetzt einfach dringend notwendig. Die Gründe dafür liegen auf der Hand: Google ist zuverlässig, Google ist flott, Google hat alle notwendigen Dienste und Google Apps kostet mich für meinen Bedarf nichts. Tatsächlich: Nichts. Denn Google Apps ist in der Basisfassung mit 10 (bis Ende der ersten Maiwoche noch 50) User-Accounts und jeweils 7 GB (anwachsendem) Speicherplatz kostenlos. Also: Tun!

Die zentrale Entscheidung ist erst einmal, zwischen dem kostenpflichtigen „Google Apps for Business“ und dem einfachen „Google Apps“ zu unterscheiden. Der Link hier führt zur kostenlosen Version. Dort geht es dann mit einem Klick auf den Erste-Schritte-Buttons sogleich los.

Neben den Kontaktdaten (das kann eine Firma sein, aber eben auch eine Einzelperson) sind vor allem zwei Dinge wichtig. Die Domain, unter der man später Mailadressen einrichten möchte und die Anlage eines neuen Google-Accounts. Es ist dabei tatsächlich ein neuer Google-Account notwendig, bestehende Google-Accounts können aus administrativen Gründen nicht benutzt werden. Und hier gibt es in vielen Fällen auch schon ein Problem, wenn nämlich die gewünschte Adresse für diesen neu einzurichtenden Google-Account schon für den bisherigen genutzt wird. Ist das der Fall, muss tatsächlich für den bisherigen Google Account eine andere Mailadresse gewählt werden, um die entsprechende Adresse dann für den neu einzurichtenden Google-Account zu nutzen.

Exkurs: Ein Google-Account oder lieber zwei?

Auch eine Sache, die man sich vorher überlegen muss: Nutzt man bereits Google-Dienste und möchte diese aus bestimmten Gründen weiterhin auf dem bisherigen Google-Account beibehalten (was Sinn machen kann, wenn man z.B. den Google-Apps-Account geschäftlich nutzen möchte), gibt es die Möglichkeit, sich mehrfach einloggen zu können. Aktiviert man diese Möglichkeit im bisherigen Google-Account, kann man sich demzufolge mit einem weiteren Google-Account einloggen und hat dann rechts oben im Browserfenster, dort wo die Mailadresse steht, mit der man aktuell eingeloggt ist, die Möglichkeit, schnell per Auswahl den anderen Account auszuwählen. Funktioniert nach meinem Test in vielen Google-Diensten, aber leider nicht in allen. Es macht also Sinn, sich ggf. tatsächlich über eine vollständige Migration der wichtigsten Dienste Gedanken zu machen, ganz unten gibt es einige Gedanken dazu.

Das Dashboard.

Zugegeben – wer es bisher gewohnt ist, dass Google-Dienste absolut einfach sind und ohne Denken funktionieren, der könnte bei Google Apps enttäuscht werden, denn es ist Mitarbeit gefragt. Benutzer müssen angelegt werden (natürlich nur, wenn man mehr als einen Benutzer einrichten möchte), und später muss für die Domain, die man für Mails nutzen möchte, auch die MX-Einträge geändert werden. Das ist nicht jedermanns Sache und die Google-Hilfe ist, sagen wir mal so, ausbaufähig. Der Hilfe-Assistent ist soweit brauchbar, allerdings muss man wissen, was man tut und das DNS sollte man auch kennen. Und leider muss man bei vielen Hilfe-Themen auf englischsprachige Artikel zurückgreifen, weil es an vielen Stellen keine deutsche Übersetzungen gibt.

Ansonsten, wenn es um einen einzigen Benutzer geht, sind die Einstellungen soweit schon mal brauchbar.

In Sachen Migration übrigens eine Empfehlung: Ruhig mal anfangen, sich in Google Apps umzuschauen, ohne gleich die eigene Domain auf Google Apps zu drehen. Das ist erst dann erforderlich, wenn man auch tatsächlich E-Mails dort live empfangen möchte. Zum Umschauen ist das noch nicht notwendig und auch noch nicht dann, wenn man Mailarchive importieren möchte. Und wer unbedingt schon mal den Empfang testen möchte, kann auf die segensreiche Möglichkeit der Test-Domain zurückgreifen, die Google Apps bei der Einrichtung automatisch anlegt (ist dann im Dashboard genau beschrieben).

Mail in Google Apps.

Wer bisher schon Google Mail genutzt hat, wird den Mail-Client kennen, denn es ist das Google-Mail-Frontend. Und Google Mail besitzt bekanntlicherweise auch eine Möglichkeit, per IMAP-Protokoll kontaktiert zu werden, so dass über diesen Weg auch bestehende Mailarchive importiert werden können (IMAP-Einstellungen gibt es in der Hilfe). Für die Outlook-Benutzer gibt es übrigens den angenehmen Nebeneffekt, dass es hier einen eigenen Importer gibt und auch der Import von PST-Postfachdateien funktioniert. Alle anderen Mailbenutzer müssen, wenn sie Mailarchive importieren möchten, den Weg über IMAP gehen.

Der IMAP-Transfer funktioniert, ist allerdings langsam. Sehr langsam. Für rund 75 % meiner Mails – das sind bis jetzt rund 35.000 E-Mails – habe ich rund 10 Stunden gebraucht und es sei angemerkt, dass das nur rund 250 MB Datentransfer war! Der Import größere Mailarchive ist also eine sehr zeitintensive Geschichte und es macht Sinn, durchaus zu überlegen, ob man wirklich alle E-Mails importiert haben möchte.

Ansonsten bietet IMAP alle Annehmlichkeiten, die man beim Archivieren haben kann, vor allem nämlich die Anlage von Unterordnern. Ich habe dazu im Archiv meines Postfaches einfach Unterordner mit der entsprechenden Jahreszahl angelegt und darin jeweils einen Ordner für Posteingang, Postausgang und jeweils für Mailinglisten. In die habe ich dann die entsprechenden Mails aus meinen Mailarchiven kopiert.

Im Google-Mail-Frontend, das bekanntlicherweise nicht mit Ordnern, sondern mit so genannten Labels arbeitet, erscheinen diese Unterordner dann alle im Format „Archiv/(Jahreszahl)/Eingang“ und sind in der Label-Ansicht auch nicht verschachtelt, da Labels nicht verschachtelt werden können. Aus der Navigationsansicht bekommt man die vielen Labels übrigens problemlos ausgeblendet, dazu einfach den Link „Labels verwalten“ anklicken und ausblenden.

Und noch eine Eigenart, die das Labeling mitbringt: Vorsicht mit der Möglichkeit, Mails mit mehreren Labeln zu versehen. Die erscheinen dann nämlich in der IMAP-Ansicht tatsächlich in den entsprechenden Ordnern mehrfach. Und auch Vorsicht mit E-Mails, die gar kein Label besitzen, wie sie normalerweise im Posteingang nach dem Empfang erscheinen. Die kann man zwar problemlos mit Labels versehen – nur wenn man das nicht macht, wird man sie, wenn man sie wegsortiert, kaum mehr finden, da Google Mail zwar eine Suchfunktion für Mails mit Labels bietet, dummerweise aber kein Suchkriterium kennt, um Mails zu finden, die kein Label tragen.

Empfehlung meinerseits, von einem alten Backup-Hasen: Do not delete your Backup. Auch wenn der Import der Mailarchive funktioniert, sollte man seine lokalen Mailarchive nicht löschen. Vielleicht gefällt einem Google Apps nicht, vielleicht geht etwas beim Import schief, vielleicht löscht man aus Versehen ein Verzeichnis in der Cloud (was wirklich Datenverlust bedeutet) und da ist ein lokales Backup die beste und einzige Lebensversicherung. Ich habe es hiermit gesagt!

Migration des Google Reader, Google Calendar und Google Contacts

Bei der Migration von Google Diensten ist leider Handarbeit gefragt. Bei all diesen drei Diensten, die ich bisher einsetze, müssen die Inhalte jeweils im bisherigen Google-Account exportiert und im neuen Google-Account wieder importiert werden. Das ist insofern problemlos, allerdings gehen beim Google Reader die Trend-Informationen, die während der Nutzung des Google Readers entstehen, verloren, da diese nicht ex- bzw. importiert werden. Ärgerliches, kleines Manko.

Beim Google Calendar gibt es zudem noch Pflegeaufwand, wenn in einem Konto noch zusätzliche Kalender abonniert sind oder gemeinsame Kalender mit anderen Benutzern geführt wird. Hier macht es Sinn, im alten Google-Account zunächst die Mailadresse des neuen Google-Accounts hinzuzufügen und sich dann mit dem neuen Google-Account einzuloggen, um die gemeinsamen Kalender auch dort verfügbar zu haben.

Migration und externe Clients

Was man bei der Anlage eines neuen Google-Accounts und einer eventuellen Migration von Diensten auch berücksichtigen muss: Überall, wo man Google-Dienste bisher verwendet hat, müssen nun die neuen Google-Account-Daten hinterlegt werden, also z.B. auf Smartphone, iPad etc. und dort dann auch in eventuelle Apps, die Google-Dienste nutzen. Funktioniert hier zwar alles weitgehend reibungslos, ist aber auch Zeitaufwand.

Next Level Mediadatenbank.

Als ich 2006 angefangen habe, meine altehrwürdige CD-Sammlung in Audiodateien umzuwandeln, wusste ich noch nicht so recht, wie praktisch das irgendwann sein könnte. Bereut habe ich es eigentlich kaum, denn obwohl ich lange Zeit so gar nichts mit mobiler Musik anfangen konnte, war es zumindest soweit praktisch, Musik immer per Knopfdruck am PC zu haben, ohne erst mal die CD zu suchen, einzulegen, abzuspielen und dann wieder die nächste usw. Irgendwann kommt man dann auch dahinter, wie das mit den Playlists funktioniert und wie der Windows Media Player anfängt, den Musikgeschmack zu lernen. Hübsch und gut.

Was damals mangels vernünftiger Alternative ein Schritt war, war die Entscheidung auf ein Musikformat. MP3 fiel heraus, weil mich MP3 nie wirklich von der Klangqualität überzeugte (ja, ich habe tatsächlich einmal Unterschiede heraushören können) und so landete ich bei Windows Media Audio. Ein Schritt, den man bedauern kann. Nicht, weil das Format nicht hochklassig wäre – das ist es nämlich nach wie vor – sondern weil WMA ein Problem hat: Das Apple-Reich will das Format nicht kennen. Schick wäre es allerdings, Musik auf dem iPhone haben zu können, immerhin habe ich ja sowohl für die Musik, als auch für das iPhone Geld bezahlt.

Also wartete der Schritt eigentlich nur darauf, einen Formatewandel durchzuziehen. MP3 fiel weiterhin aus, aber MP4 alias AAC ist dann die Antwort. Das ist das Hausformat von iTunes und inzwischen auch vom Windows Media Player 11 unter Windows 7. AAC wird zwar aufgrund höherer Lizenzkosten bei weitem noch nicht von allen Musikabspielgeräten eingesetzt, aber darf man trotzdem AAC als potentiellen Nachfolger von MP3 nennen? Falls nicht, ist es mir auch egal.

Also durften die noch bei mir im Besitz befindlichen CD wieder eine Runde im PC drehen, um ihren Inhalt als M4A-Dateien auf meine NAS auszuwürgen. Kurzfristig vermisste ich dann mal ungefähr 70 Alben und begann, das Haus zu durchsuchen, bis mir schwante, dass diese 70 Alben vielleicht schon längst nicht mehr in meinem Besitz sind, was sie auch tatsächlich nicht mehr sind. Nennen wir es mal „natürlich Auslese“, die da im Laufe der Jahre passiert ist.

Nun also: M4A alias AAC. Versteht nach wie vor die PS3, versteht auch das iPhone, iTunes kann mit meiner Buffalo-NAS korrespondieren, auf der die Audiodateien liegen und der Windows Media Player auch. Die nächste Stufe kann kommen.

Und noch ein Artikel in Sachen Google Calendar und iPhone.

Die Artikel zum Synchronisieren zwischen Google Calendar und dem iPhone gehören weiterhin zu den absoluten Artikelschlagern hier im Blog. Das hat den Vorteil, dass die Artikel offensichtlich einigen Ratsuchenden eine Hilfe darstellen und einiges an Erfahrungen zusammenkommen, die leider in den offiziellen Google-Anleitungen nicht gut oder teilweise gar nicht dokumentiert sind.

Bei der Verfassung der Anleitung zum Synchronisieren des Google Calendar mit dem iPhone hat sich ursprünglich das Verhalten gezeigt, dass über dem offiziellen Verfahren namens „Google Sync“ (das auf dem ActiveSync-Verfahren von Microsoft beruht) nur der Hauptkalender eines Google-Calendar-Accounts synchronisiert werden kann und offenbar nicht eventuell eingerichtete Sub-Kalender. Meine Alternative war die Anleitung zur Synchronisierung per CalDAV. Das funktioniert zwar, ist aber deutlich langsamer.

Nun, kurzum, es funktioniert doch mit Google Sync, wenn man sich von einer Fehlermeldung von Google, die auf einem simplen Sprachproblem basiert, nicht ins Boxhorn jagen lässt. Dementsprechend habe ich die Anleitungen auf Basis von Google Sync dementsprechend aktualisiert und der einzig wahre und perfekte Artikel ist folgender:

Und wer es dann trotzdem noch per CalDAV machen möchte, weil er ActiveSync aus politischen Gründen nicht nutzen kann, nimmt halt diese Anleitung, die jetzt einen neuen Titel hat:

Und wer beides nicht nutzt, also weder Google Calendar, noch iPhone, der kann trotzdem etwas per Flattr spenden, war nämlich alles richtig viel Dokumentationsarbeit. Alles nicht so einfach im Leben. 😉