Runde Ecken
Bislang können auf dem iPhone Anwendungen nur im Browser laufen. Wer seine Site für das Mobiltelefon anpassen will, muss manches beachten und kann auf allerlei Hilfsmittel zurückgreifen.
- Jochem Huhmann
Lokale Applikationen durch im Browser laufende Webapplikationen zu ersetzen, gelingt sowohl auf Workstations als auch auf mobilen Geräten bisher nur eingeschränkt. Auf Apples iPhone (und dem bis auf den fehlenden Mobilfunkteil weitgehend identischen iPod touch) allerdings bleibt vorerst keine große Wahl, da ein SDK erst im Februar 2008 erscheinen soll. Ein Überblick über Features, Einschränkungen und Besonderheiten hilft bei der Entscheidung, ob und wie sich Webapplikationen für das Gerät optimieren lassen.
In Gegensatz zu den auf mobilen Geräten sonst meist anzutreffenden speziellen Produkten läuft auf dem iPhone Safari und damit ein weitgehend voll funktionsfähiger Browser. Er gaukelt dem Webserver eine Fensterbreite von 980 Pixeln vor und skaliert die Darstellung dann auf die vorhandenen 320 (bei horizontaler Orientierung 480) Pixel. Die meisten Seiten stellt er damit nahezu perfekt dar: Obwohl Fließtext so nur selten lesbar ist, kann man sich einen Überblick über Seiteninhalte und eingebettete Grafiken verschaffen und Überschriften lesen. Für Details zoomt Doppeltippen in einzelne Spalten und Blöcke hinein- und wieder heraus. Dabei bemüht sich Safari, die Elemente passgenau auf den Schirm zu bringen. Voraussetzung hierfür ist allerdings ein Seitenlayout, das den Textumbruch nicht vollständig dem Browser überlässt: Bei Zeilen, die sich über die gesamten (virtuellen) 980 Pixel erstrecken, bleibt einem nur die Wahl zwischen mikroskopisch winziger Darstellung oder kontinuierlichem horizontalen Scrollen nach freiem Hineinzoomen durch „Aufziehen“ eines Bereichs mit zwei Fingern. Webseiten, die die Textbreite nicht begrenzen, gibt es allerdings selten, da sie auf Desktops bei üblichen Fenstergrößen und Auflösungen leicht zu enormen Zeilenlängen führen und deshalb mittlerweile fast ganz ausgestorben sind.
Grenzen bei aufwendigem Layout
Für das reine Lesen von Webseiten ist diese Art der Darstellung und Bedienung auf dem kleinen Display überraschend gut geeignet. Sie stößt jedoch schnell an ihre Grenzen, wenn es um typische Webapplikationen geht: Großzügig horizontal und vertikal auf der Seite verteilte Eingabefelder, Buttons, Auswahllisten, Textkästen und dekorative Elemente erfordern viel Scrollen in alle Richtungen. Buttons sind oft so klein oder liegen so eng beieinander, dass sie sich in einer die Übersicht bewahrenden Zoomstufe nicht sicher treffen lassen. Zum Schluss darf man sich auf die Suche nach dem „Senden“-Button begeben. Kurz: Formulare sind eine Qual. Dass dies trotz der eingeschränkten Platzverhältnisse nicht so sein muss, beweisen die mitgelieferten und durchweg angenehm bedienbaren Anwendungen, die in der Regel noch nicht einmal besonders aufwendig gestaltet sind.
Webapplikationen lassen sich mit wenig Mühe für das iPhone optimieren. Will man den Nutzern „normaler“ Browser nicht eine sehr ungewohnte Ansicht bieten, wird man allerdings nicht um eine der (meist zu Recht) unbeliebten Browser-Weichen herumkommen. Mobile Safari auf dem iPhone beziehungsweise iPod touch meldet sich im User-Agent-Teil des HTTP-Header folgendermaßen:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+
(KHTML, like Gecko)
Version/3.0 Mobile/1A543 Safari/419.3
Mozilla/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1
(KHTML, like Gecko)
Version/3.0 Mobile/3A101a Safari/419.3
Diesen Kopfzeilen sieht man auf den ersten Blick an, dass der mobile Safari gern als Webkit-, notfalls auch als Gecko-Browser (wie Mozilla/Firefox) oder als KHTML, aber auf gar keinen Fall als IE erkannt werden möchte. Will man ihn sicher als das identifizieren, was er ist, führt kein Weg an der Prüfung auf „iPhone“ oder „iPod“ vorbei, zumal auch die Webkit-Versionen je nach OS-Version des Geräts variieren. Nebenher bemerkt legt die fehlende generische Identifikation wie „MobileSafari“ die Vermutung nahe, dass es in Zukunft noch weitere Geräte mit demselben Browser, aber mit anderen Fähigkeiten oder anderer Bildschirmauflösung geben könnte. Die bisherigen Versionen des iPhone und des iPod touch unterscheiden sich hinsichtlich der Fähigkeiten des eingebauten Browsers nicht.
Meta-Tags vermeiden Scrollen
Der erste Schritt besteht darin, horizontales Scrollen zu vermeiden. Die vom mobilen Safari angenommenen 980 Pixel Fensterbreite lassen sich mit dem Viewport Meta-Tag an die tatsächlichen Gegebenheiten anpassen. Im selben Schritt kann man das nun überflüssige Zoomen unterbinden:
<meta name="viewport"
content="user-scalable=no, width=device-width">
Zum Ausblenden der beim expliziten Aufruf einer Webapplikation überflüssigen bis lästigen URL-Zeile reicht ein bisschen Javascript:
window.onload = function() {
setTimeout(function(){window.scrollTo(0, 1);}, 100);
}
Es rollt den Bildschirminhalt um ein Pixel nach unten, wodurch Safari die URL-Zeile ausblendet und 60 Pixel mehr Platz schafft.
Bei derart optimierten Webapplikationen dürfte der Einstiegspunkt nach einem Titel und einem Logo am oberen Seitenrand ein Menü sein. Es sollte den mitgelieferten iPhone-Applikationen ähneln und eine einfache vertikale Auswahlliste von Textlinks anbieten. Schriftgröße und Zeilenhöhe müssen für das sichere Antippen mit dem Finger hinreichend groß gewählt sein: Apple empfiehlt 44 Pixel Zeilenhöhe und eine Schriftgröße von 14 Punkt, mit einem Pfeil am rechten Rand zur Verdeutlichung des Menücharakters. Damit lassen sich ungefähr fünf Einträge samt Überschrift und einer Fußzeile mit zwei bis drei Buttons (für Impressum, Registrierung et cetera) so unterbringen, dass sie ohne Scrollen sichtbar und mit einem Fingerdruck erreichbar sind.
Weitere Inhalte (Neuigkeiten, Meldungen, Abkürzungen zu Inhalten) können weiter unten folgen. Dabei ist aber darauf zu achten, dass der mobile Safari Scrollbalken nur anzeigt, wenn der Benutzer den Inhalt tatsächlich verschiebt - es gibt keinen sichtbaren Hinweis darauf, dass die Seite größer ist als der gerade sichtbare Bereich. Deshalb sollten alle wichtigen Links im sichtbaren Bereich liegen. Im Vergleich zu manchen aufwendigen Startseiten mag all dies wie eine starke Einschränkung wirken, aber einen Vorteil hat die Konzentration: Der Einstieg ist übersichtlich und schnell sichtbar.
Eine der wesentlichen Neuerungen im GUI von Nextstep und heute bei Mac OS X war die spaltenweise Navigation durch Hierarchien: Anstelle grafisch dargestellter Bäume und verzweigter Listen stellt der Finder in OS X Verzeichnishierarchien spaltenweise nebeneinander dar. Ein Klick auf eine Zeile (Verzeichnis) in einer Spalte öffnet eine neue rechts davon, die den Inhalt zeigt. Viele Menüs auf dem iPhone und iPod touch folgen dieser Konvention, und es gibt gute Gründe, dies bei Webapplikationen beizubehalten.
Menüs von Nextstep inspiriert
Im Unterschied zum Datei-Browser bei Nextstep und zum Finder bei Mac OS X hat das iPhone in der Regel nur Platz für eine Spalte auf dem Schirm. Umso wichtiger ist eine klare Navigation samt einfacher Rückkehr zur darüberliegenden Ebene. Dies erreicht meist ein pfeilartiger Button links in der obersten Zeile, der den Titel der letzten Ebene trägt und zu ihr zurückführt. Dieses Modell lässt sich einfach auf eine Hierarchie von Webseiten übertragen. Netterweise bietet Apple fertige Images samt CSS-Styles an (siehe Kasten „Onlinequellen“), die den üblichen GUI-Konventionen auf dem Gerät folgen. Zur Vermeidung unnötig übertragener Daten verwenden diese das proprietäre CSS-Attribut -webkit-button-border, das horizontal skalierende PNG-Grafiken auf beliebige Elemente stempelt. So lassen sich aus einer Grafik Buttons mit beliebigen Texten erzeugen, ohne für jeden Button eine weitere Datei übertragen zu müssen. Ähnliches gilt für die visuell leicht abweichenden Menüs für Einstellungsdialoge samt gerundeten Rahmen für gruppierte Einstellungen. Der „Senden“-Button, den man beim iPhone eher „Sichern“ oder „Fertig“ nennen sollte, ist übrigens auf Einstellungsseiten rechts oben am besten untergebracht.
Wem all dies nun zwar interessant, aber mühsam umzusetzen erscheint, der sei getröstet: Es existieren bereits Javascript-Bibliotheken wie IUI (s. Abb. 1), die dem Entwickler nicht nur den Großteil der Kleinarbeit abnimmt und fertige Hierarchien und Einstellungsdialoge zur Verfügung stellt, sondern auch Ajax-Techniken wie das Laden von Inhalten in die aktuelle Seite unterstützt. Open-Source-Applikationen wie das Mail-Programm imobmail sind eine nützliche Quelle zum Lernen und Experimentieren.
Eine der größten Schwächen von Webapplikationen nicht nur auf dem iPhone ist der eingeschränkte Zugriff auf Funktionen und Software des Betriebssystems. Im mobilen Safari aktiviert ein Klick auf „mailto“-URLs den integrierten Mailclient, „tel“-URLs rufen (nach Bestätigung des Benutzers) die angegebene Telefonnummer an, und bei Links auf Youtube-Videos oder Google-Maps benutzt das iPhone automatisch die eingebauten Clients. „sms“-URLs erkennt es nur in E-Mails, jedoch nicht auf Webseiten. Kontrolle über die bei Bedarf eingeblendete Tastatur gibt es nur begrenzt: Sprachspezifische Tastaturen lassen sich über das lang-Attribut des jeweiligen Eingabe-Feldes anfordern. Enthält der Feldname „zip“, bekommt man eine numerische Tastatur, bei „phone“ die Telefontastatur. Die von Safari im URL-Feld verwendete spezielle Tastatur lässt sich leider nicht programmatisch wählen.
Canvas statt Flash, SVG & Co.
Die Darstellung und Kontrolle komplexerer grafischer Elemente zum Beispiel für Charts oder virtuelle Geräte ist mangels Unterstützung für Flash, OpenGL, Java und SVG nur über das Canvas-Element möglich, das aber gut in Javascript und DOM eingebunden ist und auch in OS-X-Widgets Verwendung findet.
Fehler in Webapplikationen zu finden, ist aufgrund der Wechselwirkungen zwischen HTML, CSS, Javascript und serverseitig laufender Software oft eine Qual. Eine Plattform mit so vielen (notwendigen) Eigenheiten wie der mobile Safari erleichtert es dem derart geplagten Entwickler nicht, da bewährte Hilfen wie Firebug nur begrenzt einsetzbar sind.
Glücklicherweise hat Apple dem iPhone-Browser eine Debug-Konsole spendiert, die sich im Entwicklerabschnitt der Safari-Einstellungen aktivieren lässt. Safari blendet dann unterhalb der URL-Zeile eine Leiste mit der Anzahl der erkannten HTML-, CSS- und Javascript-Fehler ein, die nach Antippen in eine nützliche Fehlerliste mit Zeilennummern verzweigt. Buttons am unteren Rand erlauben es, nur HTML-, CSS- und Javascript-Fehler anzuzeigen. Auch Dinge wie die Laufzeitausgabe von Variablen sind damit möglich: die Zeile console.log(“var=“ + var) schreibt zum Beispiel den Namen und Inhalt der Variablen var in die Konsole. Außerdem gibt es error()-, warn()- und info()-Methoden, die die Ausgabe in der Konsole mit passenden Icons verzieren.
Als Steve Jobs dem ungläubigen Publikum verkündete, dass er sich bei Applikationen für das „Jesus Phone“ auf die Web-2.0-Idee verlässt, gab es nur wenige begeisterte Gesichter. Betrachtet man die Anzahl der Apple-eigenen Webseiten, die das iPhone berücksichtigen (bis auf minimale Anpassungen der Darstellung praktisch keine) und nimmt die kürzliche Ankündigung eines nativen SDK für Februar 2008 dazu, stellt sich die Frage: Wozu der Aufwand?
Der dünnste Thin Client als Ziel
Eine mögliche Antwort ist die etwas verblüffende Erkenntnis, dass Webapplikationen für das iPhone häufig trotz der vielen Einschränkungen besser benutzbar sind als ihre großen Vorbilder. Der Zwang zu hierarchischer Navigation und durchdachter Oberfläche sowie der geringe Spielraum für Layout-Unarten trotz Möglichkeiten für visuelle Finesse lassen erahnen, was Webapplikationen sein könnten, wenn man nur wollte. Deshalb sind sie auf dem iPhone zumindest nicht weniger sinnvoll als auf dem Desktop. Da der „Thin Client“ im Fall des iPod touch nur 8 Millimeter dünn ist, drängt sich der Schluss auf: Wenn schon Webapplikation, dann ist dies der richtige Client.
Während viele Entwickler bei Browser-Weichen und gerätespezifischen Entwicklungen aufstöhnen, könnte es gut sein, dass sie solche Anpassungen kaum mehr vermeiden können. Googles Android-Plattform für mobile Geräte verwendet dieselbe Browser-Basis, sodass die Zielgruppe für Webkit-Spezifisches sich bald nicht mehr auf iPhone- und Mac-Benutzer beschränken wird. So lief WPhone, eine iPhone-Anpassung für die Verwaltungsoberfläche des Blog-Systems Wordpress, nach nur geringen Änderungen auf Android.
Trotzdem, Apple muss nachbessern: Ein schwerwiegender Mangel des Geräts ist das Fehlen jeglicher Keychain-Unterstützung - Benutzernamen und Passwörter für Webseiten muss sich der Anwender merken und immer wieder von Hand eingeben. Wer einmal die vorhandenen Applikationen in Apples Verzeichnis durchprobiert, stellt schnell fest, dass sogar eine simple Einkaufsliste eine Registrierung verlangt. Selbst wenn man (sicherheitstechnisch bedenklich) immer dasselbe Passwort benutzt, hört hier der Spaß schnell auf.
Abhilfe schafft bestenfalls OS-X-Shareware wie 1Password (1password.com) auf dem Mac zusammen mit einem Bookmarklet auf dem iPhone, aber nicht jeder hat einen Mac. Authentifizierung über IP-Adressen ist innerhalb kontrollierter Netze vielleicht ein Ausweg, in öffentlichen Netzen ist der Komfortverlust durch explizites Anmelden bei jeder Anwendung aber prohibitiv. Für weniger sicherheitsrelevante Angebote empfiehlt sich dringend das Speichern von Benutzerdaten in Cookies, wenn man die Anwender nicht vergraulen möchte. Dazu kommen Einschränkungen wie der fehlende Support für lokales Speichern von Daten und die daraus resultierende fehlende Unterstützung für Up- und Downloads sowie fehlendes Copy&Paste - beides ist zwar überraschend oft verzichtbar, aber wenn es fehlt, dann fehlt es richtig.
Unterm Strich ist der mobile Safari auf dem iPhone und iPod touch für viele Webapplikationen gut brauchbar. Diese Geräte können zwar größere Rechner genauso wenig ersetzen wie Webapplikationen alle nativen Programme. Trotzdem gibt es viele Fälle, in denen zentrales Vorhalten von Daten und Code zusammen mit einem leistungsfähigen mobilen Client den Aufwand der Anpassung lohnen.
Jochem Huhmann
ist freiberuflicher Autor und Entwickler.
iX-TRACT
- Bislang können Anwendungen für das iPhone nur in dessen Safari-Browser laufen. Ein natives SDK soll es erst ab Februar 2008 geben.
- Webapplikationen sollten sich an den auf dem Gerät installierten Programmen orientieren. Entwickler können sich dazu bei Apple mit Grafiken bedienen und spezielle CSS-Attribute nutzen.
- Eine Debug-Konsole auf dem iPhone hilft bei der Fehlersuche in Webanwendungen. Auch die Firefox-Erweiterung Firebug lässt sich dazu nutzen.
(ck)
