Innovation

Entwicklung mobiler Websites: Markup

Dino Esposito

 

Heutzutage, da immer mehr Geräte zur Webdurchsuchung eingesetzt werden, wird eine für Mobilgeräte optimierte Website zu einem entscheidenden Faktor für Unternehmen. Machen wir uns doch nichts vor: Selbst mit den modernsten Smartphones gestaltet sich die Durchsuchung einer Desktop-Website recht problematisch. Für eine sinnvolle Anzeige der Inhalte und zum Verfolgen der Links müssen Sie hin- und herschwenken und zoomen. Dies ist natürlich machbar, bedeutet aber keine wirklich optimales Benutzererlebnis.

Ich nutze mein Smartphone zum Durchsuchen von Desktop-Websites, dabei rufe ich oftmals lieber die Vollversion als die eventuell verfügbare Mobilversion auf. Dafür gibt es vor allem einen Grund: Mobile Websites sind oft nicht so gut aufgebaut wie Desktop-Websites. Als häufiger Besucher einer Site bauen Sie gewisse Erwartungen auf. Sie gehen davon aus, dass Sie auch tatsächlich alles finden, was die Website verspricht, egal, über welches Medium Sie auf die Site zugreifen. Wenn Sie die Website von einem Mobilgerät aus aufrufen, erwarten Sie im Idealfall dieselbe Servicestufe, allerdings auf Ihren aktuellen Status ausgerichtet – den Status eines mobilen Nutzers, der vielleicht gerade auf dem Sprung und in Eile ist und mit einer schlechten Verbindung auskommen muss.

Genau das ist die Herausforderung, der sich die Architekten und Entwickler einer mobilen Website stellen müssen. Die größten Probleme bei einer mobilen Website bereitet nicht zwangsläufig die Implementierung der verschiedenen Funktionen. Eine mobile Site verfügt im Allgemeinen über weniger Funktionen und Aktionen pro Seite als eine Desktop-Website. Weniger Codezeilen bedeuten auch weniger Probleme. Für ein optimales Benutzererlebnis werden häufig angeforderte Funktionen allerdings sogar noch dringender benötigt als bei einer Desktop-Website. Ein optimales Benutzererlebnis auf Mobilgeräten zu ermöglichen, kann eine echte Herausforderung darstellen. Oft müssen die Teams in diesem Zusammenhang zu besonders raffinierten Codierungs- und Entwurfslösungen greifen.

Hinzu kommt, dass mobile Websites möglicherweise für eine große Bandbreite an verschiedenen Geräten geeignet sein müssen. Wenn Sie bis vor wenigen Jahren bereits der Umgang mit verschiedenen Desktopbrowsern erschreckt hat, denken Sie mal über den mobilen Bereich nach. Hier sprechen wir von verschiedenen Geräteprofilen in einer Größenordnung von Tausenden, mit denen Sie es zu tun haben können. (Das heißt allerdings nicht, dass Sie tausende verschiedene Versionen einer Seite vorbereiten müssen – diese tausende Geräteprofile werden auf einige wenige Geräteklassen reduziert, die unterschiedlich behandelt werden.)

Dieser Artikel eröffnet eine Serie, in der ich versuchen werde, die Entwicklung mobiler Websites aus einer nicht primär technologischen Perspektive zu betrachten. Meiner Meinung nach ist die Entwicklung mobiler Websites zu oft mit spezifischen Frameworks und den zugehörigen Lösungen verbunden, ohne dass viel über Anwendungsfälle und die Umstrukturierung von Inhalten nachgedacht wird. In diesem Artikel beginne ich mit den Grundlagen – dem Mobile Markup.

Browser und Viewport

Normalerweise rendern die meisten mobilen Browser Seiten heutzutage in Viewports, die viel größer als die tatsächlichen Bildschirme der Geräte sind. Die Viewportbreite hängt zwar vom Browser ab, sie liegt aber immer nahezu bei 1.000 Pixeln. So beträgt sie beispielsweise 980 Pixel bei Safari für iPhone und Internet Explorer 9 und 800 Pixel bei Android WebKit. Als Entwickler für Mobilgeräte sollten Sie sich zunächst die Aufgabe und Herkunft des Viewports klar machen. In Abbildung 1 ist die Verwendung des Viewports durch mobile Browser dargestellt.

Abbildung 1 – Verwendung des Viewports durch mobile Browser

Der Viewport ist ein Bereich mit fester Breite, in dem der Browser alle Inhalte rendert. Die Viewportgröße steht nicht zwangsläufig in Relation zur physischen Bildschirmgröße. Bei einem Desktop-Browser ist dies keine große Sache, bei den bedeutend kleineren Bildschirmen von Mobilgeräten wird es jedoch zum Problem. Browser rendern Seiten häufig in ihrer internen Viewportgröße. Bei der Anzeige wird der Viewport jedoch verkleinert, damit der gesamte Inhalt in die tatsächliche Bildschirmgröße passt.

Folglich müssen Sie als Benutzer entweder horizontal und vertikal scrollen, um den gesamten Inhalt zu sehen, oder die Anzeige vergrößern, um den Inhalt lesbar zu machen und – was noch wichtiger ist – den Links folgen zu können. Eine sehr hilfreiche Ressource mit weiteren Informationen zur internen Implementierung von Viewports in Browsern finden Sie unter bit.ly/bZYlKb.

Viewport und Markup

Zu Beginn wurde bei der Entwicklung von mobilen Websites ein anderes Markup verwendet als bei Desktop-Websites. Im Lauf der Jahre sind wir von Wireless Markup Language (WML) über kompaktes HTML (cHTML) zu erweiterbarem HTML (XHTML) für Mobilgeräte übergegangen. In allen diesen Fällen wurde dem Server ein anderer MIME-Typ (Multipurpose Internet Mail Extensions) bereitgestellt. Anhand dieses Typs konnte der Browser feststellen, welche Art von Inhalten er empfangen würde, und diesen entsprechend rendern. Mit der Aufkommen des iPhones wurde klar, dass Mobilgeräte eine Laptops vergleichbare Funktionalität bieten können, zumindest was das Rendern von Webseiten anbelangt. Dasselbe Markup für mobile Browser und Desktop-Browser bedeutete jedoch Probleme aufgrund der unterschiedlichen Bildschirmgrößen. Die mobilen Benutzer waren gezwungen, Inhalte nach Bedarf zu verkleinern und zu vergrößern.

Wenn derselbe MIME-Typ (text/html) sowohl für Desktopanforderungen als auch für mobile Anforderungen verwendet wird, kann der Browser nicht mehr anhand des MIME-Typs feststellen, ob die Inhalte auf einem Desktop oder einem Viewport in der Größe eines Mobilgeräts ausgegeben werden sollen. Aus diesem Grund hat Apple Inc. vor einigen Jahren das Viewportmetatag eingeführt. Heute ist das Viewportmetatag de facto Standard und sollte für jede Seite, die als mobile Seite vorgesehen ist, definiert sein. Typische Verwendung des Viewporttags:

<meta name="viewport" content="width=device-width" />

Für das Inhaltsattribut des Metatags (content) ist ein Ausdruck festgelegt, bei dem für einige Eigenschaften Ad-hoc-Werte definiert werden können. Die wichtigste dieser Eigenschaften ist die Breite. Über die Eigenschaft für die Breite (width) legen Browser die Größe ihrer Viewports dynamisch fest. Für die Breiteneigenschaft kann ein bestimmte Pixelanzahl oder ein besonderer Ausdruck angegeben werden, wie im vorherigen Beispiel veranschaulicht. So gibt speziell der Wert „device-width“ (Gerätebreite) die Breite des Bildschirms in Pixel an. In diesem Zusammenhang wird Pixel im Sinne eines geräteunabhängigen Pixels oder CSS-Pixels verwendet. Auf Geräten mit hoher Pixeldichte muss der Browser eine neue Skalierung vornehmen. Dabei kann es vorkommen, dass eine Breite von 100 Pixel 150 oder sogar 200 physische Pixel umfasst. In Abbildung 2 sind die unterstützten Eigenschaften in einem Viewportausdruck dargestellt. 

Abbildung 2 – Eigenschaften in einem Viewportausdruck

Eigenschaft	Beschreibung
width	Gibt die gewünschte Viewportbreite in geräteunabhängigen Pixeln an. Hierbei kann es sich um eine explizite Zahl (z. B. 240) oder – besser – um einen relativen Wert wie z. B. „device-width“ (Gerätebreite) handeln.
height	Gibt die gewünschte Viewporthöhe in geräteunabhängigen Pixeln an. Hierbei kann es sich um eine explizite Zahl (z. B. 320) oder – besser – um einen relativen Wert wie z. B. „device-height“ (Gerätehöhe) handeln.
initial-scale	Gibt die gewünschte Zoomstufe beim ersten Laden der Seite an. Der Wert 1 gibt an, dass die Seite in ihrer natürlichen Größe, also ganz ohne Zoom gerendert werden soll. Bei einem Wert von 2 wird die Seitengröße verdoppelt, usw. Sie können auch Dezimalwerte wie z. B. „1.0” verwenden.
minimum-scale	Gibt die niedrigste Zoomstufe an, die für die Seite zulässig sein soll. Der Wert 1 gibt an, dass der Benutzer die Seite nicht kleiner als in ihrer natürlichen Größe anzeigen kann.
maximum-scale	Gibt die höchste Zoomstufe an, die für die Seite zulässig sein soll. Der maximale Wert beträgt 10.0.
user-scalable	Eine Eigenschaft mit den möglichen Werten “yes“ (ja) und “no“ (nein), über die angegeben wird, ob der Benutzer auf der Seite zoomen darf.

Auf manchen Browsern gibt es unter Umständen weitere Eigenschaften. Insbesondere wird von Android-Browsern auch die Eigenschaft „target-densitydpi“ berücksichtigt, über die Entwickler mitteilen, welche Bildschirmauflösung sie für die Seite vorgesehen haben. Mit dieser Eigenschaft können Android-Browser möglicherweise die Skalierung pixelbasierter Ressourcen wie z. B. Abbildungen optimieren. Für die Eigenschaft “target-densitydpi“ kann eine bestimmte Zahl oder ein spezieller Wert wie z. B. “device-dpi“ festgelegt werden.

Nachfolgend sehen Sie eine speziellere Möglichkeit, das Viewportmetatag festzulegen:

<meta name="viewport"
  content="width=device-width, user-scalable=no, initial-scale=1"/>

Die Eigenschaft für die Höhe (height) wird nicht oft verwendet. Sie wird im Allgemeinen genutzt, wenn Elemente unten auf dem Bildschirm oder an einer von der Viewporthöhe abhängigen Stelle platziert werden sollen. Beachten Sie außerdem, dass bei Festlegung von „no” (nein) für „user-scalable“ (vom Benutzer skalierbar) für die betreffende Seite kein Pinch-and-Zoom möglich ist.

Heutzutage ist das Viewportmetatag weit verbreitet, in der Vergangenheit wurden jedoch von manchen Browsern für denselben Zweck andere Metatags wie HandheldFriendly und MobileOptimized verwendet:

<meta name="HandheldFriendly" content="true" /> 
<meta name="MobileOptimized" content="320" />

Das World Wide Web Consortium (W3C) ist dabei, ein Papier zur Standardisierung des Viewportelements auszuarbeiten. Den aktuellen Entwurf finden Sie unter bit.ly/AavTG5.

XHTML- und XHTML-Mobile Profile

Ziel des Viewportmetatags und anderer Metatags ist es letztendlich, die Größe des Viewports anzugeben, auf dem die Inhalte gerendert werden sollen. Metatags werden verwendet, wenn normales HTML-Markup für mobile Browser bereitgestellt wird. Wenn Sie Mobile Markup bereitstellen können, benötigen Sie keine Metatags, sondern nur ein Dokument mit dem XHTML Mobile Profile (MP) DOCTYPE: 

<!DOCTYPE html PUBLIC
  "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "http://www.openmobilealliance.org/tech/DTD/xhtmlmobile12.dtd">

Der MIME-Typ für das XHTML-MP lautet „application/vnd.wap.xhtml+xml.” Verglichen mit den Ausdrucksmöglichkeiten von normalem HTML gehört XHTML-MP der Vergangenheit an, da hierbei die DOM-Bearbeitung (DOM = Document Object Model) sowie wichtige Bereiche wie die Unterstützung von CSS und JavaScript eingeschränkt sind.

Der aktuelle Standard für die meisten heutigen Geräte ist die Verwendung von HTML mit dem Viewporttag. Möglicherweise muss Ihre Website jedoch für ein wirklich breites Spektrum an Geräten offen sein, darunter auch alte Geräte, die HTML oder das Viewporttag nicht unterstützen. Was ist in diesem Fall zu tun?

Es mag zwar etwas direkt klingen, aber Sie brauchen Hilfe aus speziellen Datenbanken, in denen Informationen zur Funktionalität mobiler Browser gespeichert sind. Diese Datenbank sind unter der Bezeichnung „Device Description Repositorys“ (DDR) bekannt. Wireless Universal Resource File (WURFL) – das von Facebook verwendete DDR – verfügt über eine Eigenschaft „preferred_markup“ (bevorzugtes Markup), die Sie auf dem Server abfragen können (beispielsweise von einer ASP.NET-Anwendung aus), um festzustellen, welches Markup für ein Gerät am besten geeignet ist. Weitere Informationen zu WURFL finden Sie unter wurfl.sourceforge.net. Ich plane, mich in zukünftigen Artikeln mit WURFL und anderen DDRs wie z. B. 51Degrees zu befassen.

HTML5 und mobile Browser

HTML5 ist eine Markupsprache, die von modernen mobilen Browsern relativ gut unterstützt wird – zumindest was den aktuellen Stand des Standards betrifft. Dies gilt für integrierte Browser in Smartphones (Safari auf iPhone und iPad, Android WebKit und Internet Explorer 9 auf Windows Phone) sowie für externe Browser wie Fennec (die mobile Version von Firefox) und Opera Mobile.

Lesen Sie insbesondere die Informationen unter mobilehtml5.org. Dort finden Sie einen umfassenden Vergleich der HTML5 -Unterstützung auf einer Vielzahl mobiler Browser. Wie Sie sehen werden, ist die Canvas- und SVG-Unterstützung nahezu universell, wogegen Eingabeelemente – ein entscheidender Faktor auf mobilen Seiten – zwar gut auf iOS 5, nicht jedoch in den aktuellen Versionen von Android WebKit unterstützt werden. Die Punkte „Local storage“ (Lokaler Speicher), „Geolocation“ (Geografischer Standort) und „Multimedia“ treffen nahezu stets zu. 

Nicht ganz so smart

Zu oft wird eine mobile Website einfach als Abkömmling einer vorhandenen Desktop-Website angesehen. So kommt es, dass die meiste Gestaltung aus der Perspektive der Desktop-Website erfolgt, wobei davon ausgegangen wird, dass der Client so „smart” – bzw. vielseitig und leistungsstark – wie ein Desktop-Browser ist. Smartphones sind aber nicht so „smart” wie Laptops. Diese starke Fragmentierung ist ein wichtiger Aspekt bei der Entwicklung von mobilen Websites. Wenn Sie also mit einem Projekt für eine mobile Website beginnen, sollten Sie sich zunächst Anwendungsbeispiele überlegen, für die Sie Ihr Projekt konzipieren möchten, und festlegen, für welche Geräte Ihre Website geeignet sein soll. Die Frage nach der zu verwendenden Technologie kommt später. In zukünftigen Artikeln werde ich mich mit den Techniken befassen, mit denen ad-hoc mobile Anwendungsbeispiele, Entwicklungsmuster für Mobilgeräte und ein geräteabhängiges Rendering festgelegt werden können.

Dino Esposito ist der Autor von „Architecting Mobile Solutions for the Enterprise” (Microsoft Press, 2012) sowie „Programming ASP.NET MVC 3” (Microsoft Press, 2011) und Mitverfasser von „Microsoft .NET: Architecting Applications for the Enterprise“ (Microsoft Press 2008). Esposito lebt in Italien und ist ein weltweit gefragter Referent für Branchenveranstaltungen. Sie können ihm auf Twitter unter twitter.com/despos folgen.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Shane Church und Steve Sanderson