© DrHitch/Shutterstock.com
GWT

1 Anpassungs- und reaktionsfähiges Design mit dem Google Web Toolkit


Die zunehmende Device-Divergenz machte „Responsive Web Design (RWD)“ nicht nur zu einem der Trends in 2013, sondern zur Notwendigkeit für eine moderne und professionelle Internetpräsenz [1]. Im Vergleich zur herkömmlichen Vorgehensweise über die neueren Webstandards wie HTML5 und CSS Media Queries bietet die Umsetzung in GWT durchaus Vorteile, die in diesem Kapitel gezeigt werden sollen.

Immer mehr und immer verschiedenartigere Geräte tummeln sich im World Wide Web. Nicht mehr nur der Desktoprechner, sondern auch Smartphones, Tablets, Spielekonsolen, Fernseher, E-Book-Reader, ja selbst Kühlschränke sind internetfähig. Was des Nutzers Herz erwärmt, stellt den armen Webdesigner vor neue Herausforderungen in puncto Interoperabilität und Nutzbarkeit seines Webangebots.

Zugegeben muss die Darstellung nicht für Kühlschränke optimiert werden. Aber sie sollte auf einem möglichst großen Anteil der übrigen Medien adäquat sein. Auch muss sich das Navigationsmenü mit der jeweils angebundenen Peripherie bedienen bzw. ansteuern lassen und der Einsatzbereich des Geräts beachtet werden. So wird eine HD-Auflösung vor einem Fernsehapparat sitzend anders wahrgenommen als vor einem Notebook.

1.1 Auf der Suche nach der eierlegenden Wollmilchsau

Zu Beginn soll eine kleine Checkliste einen groben Überblick geben, welche Kriterien für eine Webanwendung zur Emulation eines nativen Erlebnisses auf dem Wiedergabegerät herangezogen werden könnten:

  • Medientyp: Berücksichtigung von Typografie, Layout und Farbgebung (Braille, Sprachausgabe, TV, Bildschirm ...)
  • Peripherie: Optimiertes Handling für Maus, Touchpad und Gamepad; Sprachsteuerung
  • Ressourcen: Content mit Rücksicht auf Art der Datenverbindung generieren; Fallbacks für Browserinkompatibilitäten definieren
  • Einsatzgebiet und Anwendungskontext: Unterschiedliche Startseiten durch Priorisierung des Content-Typs; bspw. könnte eine Lebensmittelkette auf einem Handheld direkt auf ihr Angebot im App Store verweisen, auf einem Fernsehapparat den neuesten Werbespot zeigen und in der Desktopversion aktuelle Sonderangebote anpreisen
  • Geographie: Sprache und Content in Abhängigkeit der GPS-Position; bspw. könnte die Lebensmittelkette die Öffnungszeiten der nächsten Filiale anzeigen

Diese Liste zeigt nur in Ansätzen, welche Bandbreite an Punkten beachtet werden muss. Allerdings können schwerlich alle aufgeführten Punkte Berücksichtigung finden, denn ihnen stehen sowohl der Mehraufwand als auch besondere Problemstellungen in der technischen Umsetzung gegenüber. Dennoch differenziert bspw. Google innerhalb einer Device-Kategorie: An iPhone, BlackBerry Curve und Nokia 6300 werden jeweils unterschiedliche HTML-Dokumente gesendet [2].

Bekanntlich besitzt Google enorme Ressourcen. Doch wird hier sicherlich nicht für jede Kombination aus den obigen Anforderungen eine dedizierte Benutzerschnittstelle implementiert. Vielmehr greift eine serverseitige Systematik, die automatisiert Anpassungen vornimmt.

Kategorisierung und Adaption durch Server

Vor nicht allzu langer Zeit waren die mobilen Browser nicht fähig, eine vollwertige Anzeige von Webinhalten zu gewährleisten. Daher mussten die Inhalte separat in einem eigenen Format ausgegeben werden: der „Wireless Markup Language (WML)“. Davon ausgehend können Informationen auch heutzutage über eine spezielle Domainerweiterung entweder als Subdomain wie bspw. http://m.spiegel.de oder eigene TLD wie bspw. http://www.kicker.mobi explizit in einer für mobile Geräte optimierten Darstellung abgerufen werden.

Dieser Ansatz erfordert allerdings vom Nutzer Kenntnis über die korrespondierende Adresse und macht das Weitergeben und Teilen von URLs über verschiedene Medientypen hinweg unbequem, da sie sich unterscheiden. Schon beim automatisierten Weiterleiten auf das passende Angebot ist eine serverseitige Identifizierung und Klassifizierung des Client-Devices notwendig. Erst mit dieser Information kann die eigentliche Auslieferung „mundgerechter“ Webseiten stattfinden.

User-Agent-Detection

Zur Bestimmung des Clients wird beim Browser-Sniffing der HTTP-Header des Requests analysiert und ausgewertet. Hauptsächlich wird das Feld „User-Agent“ zum Abgleich mit einem „Device Description Repository“ [3] verwendet. Diese Technik wird nicht erst seit dem Bekanntwerden des RWD eingesetzt, sodass bereits eine Vielzahl an Bibliotheken bereitsteht, die diese Aufgabe bewältigen [4], [5].

In diesem Kapitel wird eine leicht abgewandelte Version von Brett Jankords Categorizr (Achtung: Categorizr wird nicht mehr aktiv weiterentwickelt!) verwendet, einem kleinen PHP-Skript mit Portierungen u. a. für Java und JavaScript [6]. Eine beispielhafte Kategorisierung ist in Tabelle 1.1 zu sehen, wobei auch gleich auffällt, dass die Identifizierung eines Geräts anhand der HTTP-Header im Falle des Samsung-Fernsehers nicht korrekt ist: Das Skript sucht zwar nach dem String SmartTV, das Gerät meldet sich aber als SMART-TV.

Es ist offensichtlich, dass die zugrunde liegende Datenbank nicht wartungsfrei ist und ein Updateservice entweder durch Einkauf von entsprechenden Dienstleistungen oder durch eigenständige Wartung Kosten verursacht.

Device

Browser [7]

Categorizr

Media Queries [8]

Auflösung, DPR [9]

Sony PlayStation 3

Mozilla

tv

screen

1 920 x 1 080, 1

Microsoft Xbox 360

IE 9 (Windows)

tv

screen

1 167 x 656, 0

Sony Bravia KDL-40EX525

Opera 11 (Linux)

tv

screen

1 920 x 1 080, 1

Samsung UE40ES6300

Safari 5 (Linux)

desktop

screen

1 280 x 720, 1

Google Nexus 7

Chrome 27 (Linux)

tablet

screen

962 x 553, 1,33

Google Nexus 4

Chrome 27 (Linux)

mobile

screen

592 x 384, 2

BlackBerry Torch 9800

Mozilla

mobile

screen

360 x 480, 1

Samsung Galaxy Note II

Chrome 27 (Linux)

mobile

screen

640 x 360, 2

Sony PlayStation Vita

Mozilla

mobile

screen

960 x 544, 1

iPod touch (4. Generation)

Safari 6 (iPhone/iPod)

mobile

screen

320 x 480, 2

Tabelle 1.1: Vergleich zwischen User-Agent-Detection und Media Queries für einige Medientypen

1.2 Einordnung der Kandidaten Server und Client

Da bei einer Webanwendung von Natur aus zwei Akteure involviert sind, ist der Browser ebenso ein Kandidat zur Realisierung der Adaptionslogik. Diese Variante ist im Allgemeinen gemeint, wenn der Terminus „Responsive Webdesign“ fällt (Kasten: „Responsive Webdesign“). Die dritte Möglichkeit stellt eine hybride Lösung dar, die versucht, die Vorteile der Einzellösungen zu kombinieren, indem sie die entsprechende Anwendungsintelligenz zwischen Server und Client aufteilt.

Luke Wrobleweski gruppiert anpassungsfähige Webseiten in ebendiese drei Kategorien und nennt Entscheidungskriterien, während Ronan Cremin in einem Blogeintrag eine feinere Einteilung in fünf Kategorien vornimmt [10], [11]:

  • Responsive Design
  • Mobile-first Responsive Design
  • Progressive Enhancement
  • Server-side...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang