Ix 12 2011_reicher_werden_kaintantzis

Rich Internet Applications (RIAs) sol-len vor allem eins gewährleisten: ei-

ne den Desktop-Clients vergleichbarekomfortable Bedienbarkeit im Browser.Google hat mit gut aussehenden undleicht zu bedienenden Anwendungenvorgemacht, wie RIAs sich präsentierenkönnen. Die neue „Richness“ im Inter-net ist allgegenwärtig. Moderne Web-Clients für E-Mail, Wegbeschreibungenoder Suchfunktionen für Adressen ha-ben aber bei den Anwendern auch neueErwartungen bezüglich Interaktivitätund Leistungsfähigkeit geweckt, die sievon Desktop-Applikationen her kennen– eine Herausforderung für die Ent-wickler neuer Applikationen. Daherlohnt es sich, die Konzepte und die Po-sitionierung von RIAs, Thin und RichClients zu beleuchten und im Kontextvon HTML5 eine aktuelle Auslegeord-nung vorzunehmen. Wer will, kann andieser Stelle in einem kleinen Quiz er-

mitteln, was er selbst unter einer RIAversteht (siehe Quiz-Kasten).

Im Fokus erfolgreicher Applikationenstehen der Benutzer und seine Aufga-ben. Nur wenn man sich auf dessen In-teraktionsverhalten konzentriert, kannman seine Erwartungen erfüllen odersogar übertreffen. Dabei können An-forderungen an die Benutzerinterak -tion so unterschiedlich formuliert seinwie „Ständige Datenerfassung und In-teraktion“ und „Daten lesen“.

Im ersten Fall ist das Eingeben vonDaten eine der Hauptaufgaben des Anwenders, beispielsweise bei einerSchadenserfassungssoftware von Ver-sicherungsmitarbeitern oder bei Ent-wicklungsumgebungen. Die Applikationsoll schnell sein und kurze Antwortzei-ten gewährleisten. Hilfreich dabei sinddie Navigation mit der Tastatur und dasVerwenden von Tastenkürzeln für häu-fige Aufgaben. In diesem Fall unter-

stützt eine lokal installierte Applikationden Benutzer am besten.

Im zweiten Fall will der Benutzerschnell informiert werden. Er selbstgibt Informationen – wenn überhaupt –nur in Form längeren, unformatiertenTextes in ein einziges Feld respektivewenige Felder ein. Das sind typischer-weise Webapplikationen wie Nachrich-tenportale, Blogs und Foren.

Neben der Konzentration auf die Be-nutzer gibt es betriebliche Aspekte undProjektrahmenbedingungen, die rele-vant sind. Dazu gehören Anforderungenwie das Umgehen mit unterschiedli-chen Versionen einer Applikation oderdass Applikationen auf jedem Firmen-PC vorhanden respektive von jedemFirmen-PC aus erreichbar sein müssen.

Ein häufig verlangter Aspekt ist Off -line-Fähigkeit. Beispielsweise soll einAußendienstmitarbeiter beim Kundenvor Ort eine Offerte ohne Netzverbin-dung erstellen. Wenn er zurückkommtund der Laptop am Netz ist, soll die Ap-plikation beginnen, Daten zu synchroni-sieren. Ein anderes Beispiel: Benutzersollen E-Mails offline schreiben können,die automatisch abgeschickt werden,wenn das Netz wieder verfügbar ist.

Will man schnell viele Personen er-reichen, dient dazu häufig eine Appli-kation, die man nicht installieren muss.Der Anwender soll nicht warten müs-sen, bis die Applikation benutzbar ist.So soll er etwa die News einer Zeitungschnell lesen können, ohne zuvor einPlug-in zu installieren oder ein Pro-gramm zu aktualisieren. Keine Installa-tion bedeutet zudem, dass man keineInfrastruktur für ein effizientes undschnelles Rollout benötigt und so dieVertriebsinfrastruktur einsparen kann.

In diesem Umfeld von Forderungen,Rahmenbedingungen und Benutzer -ansprüchen ist es wichtig, die unter-schiedlichen Client-Kategorien Thin,RIA und Rich auseinanderzuhalten.Nur so kann man die richtige Katego-rie und schließlich die richtige Technikfür eine Aufgabe wählen.

RIA ist nicht gleich RIADas RIA-Konzept befindet sich imSpektrum zwischen klassischen seiten-basierten Webseiten (Thin Clients) und Stand-alone-Applikationen (RichClients) (siehe Abbildungˇ1). Zu Erste-ren gehören etwa die Internetseiten vonZeitungen, während man zu den Stand-alone-Applikationen Pakete wie MSOffice, Photoshop oder Entwicklungs-

86 iX 12/2011

REPORT Web-Clients

Wie HTML5 Rich Internet Applications verändert

Reicher werden Nikolaos Kaintantzis

Der Begriff Rich Internet Application – kurz RIA – ist zwar gängig, aber nicht konkret definiert. Wer eine RIA entwickelnwill, sollte genau wissen, was sie von Thin und Rich Clients unterscheidet. Und vor allem: welche neuen Funktionen HTML5 für diese Aufgabe mitbringt.

ix.1211.086-091 07.11.2011 17:49 Uhr Seite 86

© Copyright by Heise Zeitschriften Verlag

werkzeuge wie Eclipse rechnet. Austechnischer Sicht lassen sich RIAs indrei Kategorien einteilen:–ˇRIA mit Ajax, also auf Basis von Ja-va Script wie map.search.ch oder Goo-gle Mail, –ˇRIA mit Plug-in, zum Beispiel derRoutenplaner Map24.com, der auf Java-Applets basiert, oder Photoshop Light/Express (Flash-Client), –ˇRIA ohne Browser kann man tech-nisch als Spezialfall von „RIA mit Plug-in“ verstehen. Der Anwender schaut sichdie Applikation im Browser mit einemPlug-in an, und wenn sie ihm gefällt,kann er sie auf den Desktop ziehenoder herunterladen. Beispiele hierfürsind Java Web Start und Adobe AIR.

HTML5 gehört technisch zu „RIAmit Ajax“. Im Wesentlichen erweitertund vereinfacht es die bisherige Versionder Hypertext Markup Language. Hinzukommen viele neue JavaScript-Schnitt-stellen sowie Neuerungen in CSS3.

So weit die technische Sicht. Die An-wendersicht verdeutlicht Abbildungˇ2.Je näher eine Client-Kategorie in denBereich „Stand-alone“ vordringt, destomehr Vorarbeit muss der Anwenderleisten, bis er eine konkrete Applika tionbenutzen kann. Gegebenenfalls ist ernicht in der Lage, diese Vorarbeiten aus-zuführen, etwa weil er JavaScript ausGründen der Firmen-Policy gar nichtaktivieren kann oder keine Administra-torrechte für die Installation einer Ap-plikation auf seinem Rechner hat.

��

�!

��

Für den Anwender ist wichtig, was erinstallieren muss (Abb.ˇ2).

iX 12/2011 87

x-TRACT● Webapplikationen gibt es in diversen Ausprägungen – von der einfachen Webseite

bis zur Rich Internet Application –, die sich für unterschiedliche Aufgaben eignen.● Wichtige Kriterien bei der Wahl der richtigen Client-Technik sind unter anderem

der Grad der Benutzerinteraktion und die durch die Projektrahmenbedingungen bestimmte Ausführungsumgebung.

● Während sich bisher einige Funktionen nur durch zusätzliche Bibliotheken oder Plug-ins realisieren ließen, können Entwickler sie jetzt nativ in Browsern nutzen, die HTML5 unterstützen.

Quiz: Was ist eine RIA?Der Begriff RIA ist allgegenwärtig, dochselten verstehen zwei Personen dasselbedarunter. Zwei Fragen sollen ermitteln,welches Verständnis ein Leser an dieserStelle des Artikels von RIA hat (bitte diePunkte in Klammern addieren).

Frageˇ1:ˇRIAs vereinfachen die Verteilungder Applikation, weil der Anwender (au-ßer dem Browser) nichts installieren muss,um mit ihr zu arbeiten.

(1) Stimme ich voll zu. (2) Stimme ich nicht zu.

Frageˇ2:ˇRIAs bieten dieselben Möglich-keiten und denselben Bedienkomfort wielokal installierte Applikationen.

(10) Stimme ich voll zu. (20) Stimme ich nicht zu.

Die Auswertung des Quiz erfolgt am Endedes Artikels.

"��#��$�#��%&��'(%&��%&��$�%��$��

�!

��

Aus Sicht der Informatik gibt es unterschiedliche RIA-Typen (Abb.ˇ1).

��

)��!*��

#��

+��,�+��

+��

�� (��

Der Grad der Benutzerinteraktion in einer Applikation reicht von einfachbis komplex (Abb.ˇ3).

ix.1211.086-091 07.11.2011 17:49 Uhr Seite 87


Bei der Entscheidungsfindung, wel-che Client-Kategorie ein Entwicklernutzen will, spielt auch der geforderteGrad an Interaktion mit dem User-In-terface eine wichtige Rolle. Hinsicht-lich der Dimension der Benutzerinter-aktion unterscheidet man zwischeneiner einfachen Navigation über Bild-schirmseiten sowie interaktiven undkomplexen Vorgängen. Um die Art derBenutzerinteraktion im Spektrum „ein-

fach“ bis „komplex/hoch“ (siehe Ab -bildungˇˇ3) einordnen zu können, sollteman verschiedene Fragen stellen: SindDialoge erforderlich, die beispielsweiseeinen Kunden einem Produkt zuordnen?Gehört das schnelle Arbeiten über Tas-tatur-Navigation zu den Anforderungen?Benötigt der Anwender Dragˇ&ˇDrop,um zum Beispiel einen Datensatz ausder Datenbank von einer Applikationzur anderen zu schieben? Jede mit „Ja“beantwortete Frage erhöht die Reich-haltigkeit der Interaktion und verlangtden Einsatz einer unterstützenden Tech-nik. Nicht alle Client-Kategorien un-terstützen die Interaktion gleicherma-ßen. Abbildungˇ4 verdeutlicht dies imKontext der Benutzerinteraktion undder Ausführungsumgebung.

Der Anwender hat seine eigene SichtGemäß Abbildungˇ4 unterstützen so-wohl Rich Clients als auch RIAs einhohes Maß an Interaktion mit der Be-nutzerschnittstelle. Die Unterschiedewerden deutlich, wenn man die Schich-ten einer Applikation betrachtet (sieheAbbildung 5).

Ein Rich Client deckt alle Schichtenvon der Datenhaltung bis zur Oberflä-chendarstellung ab. Der Server, falls ergebraucht wird, ist in der Regel nur fürdie gemeinsame Datenhaltung zustän-dig – eventuell auch für einen Teil derGeschäftslogik. Microsofts Word istein Bespiel für einen Rich Client, derkeinen Server benötigt. Outlook hinge-gen ist ein Rich Client mit Server, derfür die Aufbewahrung der Mails zu-ständig ist.

Deckt ein Client mehrere Schichtenab, kann die Kommunikation zwischenihm und dem Server in tieferen Schich-ten und weniger häufig erfolgen. Solchein Client hat ein schnelleres Antwort-verhalten, bietet somit eine bessere Be-nutzerunterstützung und erlaubt so einflüssigeres Arbeiten.

Im RIA-(Ajax)-Fall ohne HTML5kann der Client maximal die Schich-ten bis zur Geschäftslogik abdecken.Gleichzeitig muss immer ein Servervorhanden sein. Er kann Aufgaben biszur Präsentationslogik übernehmen.Die daraus resultierende längere Ant-wortzeit beeinträchtigt unter Umstän-den die Interaktivität. KomplexereUser-Interfaces reagieren meistens ei-nen Tick zu langsam, sodass ein flüs-siges Arbeiten nicht immer möglichist. Einen ganzen Tag intensiv mit ei-

nem Ajax-Client zu arbeiten, ist oftanstrengend.

Mit HTML5 lassen sich ebenfallsAjax-Applikationen realisieren. Abbil-dungˇ5 zeigt, dass ein damit realisierterClient standardisiert in tiefere Schich-ten vordringen kann, ermöglicht unteranderem durch Local Storage, IndexedDatabase und File-API. Ein RIA-Ajax-Client kann mit HTML5 seine Datenselbst verwalten und benötigt hierfürkeinen Server. Das führt wie beim RichClient zu schnellen Reaktionszeiten.Muss der HTML5-Client aber mit demServer interagieren, weil er von dortDaten oder Logik bezieht, kann sichdas wie bei Ajax ohne HTML5 negativauf die Interaktivität auswirken.

Abbildungˇ4 zeigt oben rechts undunten links freie Flächen, die nicht vonClient-Kategorien abgedeckt sind. FürRIAs mit Ajax gibt es technische Gren-zen, die noch nicht überwindbar sind.Dazu gehören unter anderem:–ˇDragˇ&ˇDrop zwischen Applika -tionen: Diese Funktion steht für Textund Bilder zwar zur Verfügung, aller-dings haben nicht die Applikationen dieKontrolle darüber. Technisch gar nichtmachbar ist zurzeit das Verschiebenvon Business- oder Domain-Objektenzwischen Programmen (zum Beispieldas Kunden-Objekt von der Applika -tionˇA in die Stammdatenhaltung).–ˇReaktionszeiten: Komplexere, inter-aktive Applikationen mit vielen Objek-ten können zu schlechten Reaktionszei-ten der Benutzerschnittstelle führen.–ˇAutomatische Hardware-Interak-tionen: Nicht möglich ist beispielswei-se das automatische Inspizieren des In-halts eines Memory-Sticks oder einer-Karte beim Anschluss.

Grenzen von Technik und AufwandSomit bieten Ajax-Clients einen gerin-geren Grad an Interaktionsmöglichkei-ten als Rich Clients. Dies symbo lisiertdas Dreieck rechts oben in Abbildungˇ6.Die gestrichelte Line darunter symbo-lisiert die Kosten-Nutzen-Grenze. DasEntwickeln nah an dieser Grenze wirdschnell teuer, weil Standards verlassenwerden und Unterschiede in Browsernoder Plattformen nicht mehr durchsFramework gekapselt sind. Dies gilt esfrühzeitig zu erkennen und durch dieWahl einer passenderen Client-Kate-gorie zu vermeiden, in die „Pareto-Falle“ zu tappen. Diese 80/20-Regelbesagt, dass 80ˇProzent der Arbeit in nur

88 iX 12/2011

REPORT Web-Clients

�� (��

��

�!

��

��

��

��

��!"�� #��

��$%�

Clients lassen sich in unterschiedlichetechnische Kategorien einteilen(Abb.ˇ4).

��

&��

-!��*��

��*��

.��*��

+�� '��

��$%�

-!��*��

��*��

.��*��

+��

��'��

(�)*+�&��

&��

Ein RIA-Client mit Ajax konnte vorHTML5 nicht alle Schichten einer Web-anwendung abdecken (Abb.ˇ5).

�� (��

��

�!

��

��

��

��

��!"�� #��

��/��0��

��$%�

(�)*+

Sowohl der Technik als auch dem Auf-wand sind bei RIAs Grenzen gesetzt(Abb.ˇ6).

ix.1211.086-091 07.11.2011 17:49 Uhr Seite 88


20ˇProzent der Gesamtzeit erledigt wer-den, die verbleibenden 20ˇProzent alsodie meiste Arbeit verursachen.

HTML5 hat dazu beigetragen, dieAjax-Box zu vergrößern und somit dieGrenzen zu verschieben, unter anderemmit einer JavaScript-API für nativesDragˇ&ˇDrop. So kann man etwa Datei-en aus dem Dateisystem in eine Web-applikation hineinziehen. Auch dasDragˇ&ˇDrop selbst definierter Typenist möglich. Nichtsdestotrotz bleibt so-wohl die technische als auch die Kos-ten-Nutzen-Grenze bestehen.

Auch bei wenig interaktiven Stand-alone-Clients stellt sich die Kosten-Nut-zen-Frage. Im Bereich unten links (Ab-bildungˇ6) ist es oft effektiver, sich füreinen Web-Client zu entscheiden.

Die Entwicklung mobiler Applikatio-nen (Apps) ist ein Geschäftsfeld, in demRich Clients für wenig interaktive Ar-beitsweisen erstellt werden. Die Opti-mierung von Webseiten für jedes Handykann sich als ebenso umfangreich er-weisen wie eine Applikation „nativ“ fürdie Plattform – beispielsweise iPhoneoder Android – zu schreiben. Für dienative Stand-alone-Vari ante spricht zu-dem, dass die im Trend liegendenApp-Stores respektive Market-Placeses erleichtern, Applikationen zu fin-den. Der Benutzer weiß, dass eine Ap-plikation aus dem Store zum Telefonpasst. Bei einer Webseite kann er nichtdavon ausgehen, dass sie für sein Tele-fon optimiert wurde.

Wer jetzt sein eigenes Verständnis,was eine RIA ausmacht, mit dem ver-gleichen möchte, das er am Anfang die-ses Artikels hatte, findet die Antwort inder Auswertung.

Konkrete Veränderungendurch HTML5Die Abbildungenˇ5 undˇ6 haben ge-zeigt, dass HTML5 neue Möglichkei-ten eröffnet. Obwohl die Spezifikationnoch nicht fertig ist, unterstützen mo-derne Browser Teile davon bereits jetzt.Jede neue Browser-Generation bietetmehr Support für das aktuelle HTML5.

Einige Funktionen, die HTML5 insRampenlicht rückt, ließen sich bereitsfrüher mit JavaScript-Bibliotheken rea-lisieren. Jedoch musste der Entwicklerfür jedes Feature eine gesonderte Li-brary verwenden. Diese Bibliothekenfunktionierten jedoch oft nur mit ein-zelnen Browsern in bestimmten Ver-sionen. Der Vorteil von HTML5 alsStandard ist, dass die neuen Browser

wettbewerbsbedingt früh und möglichstviel seiner Funktionen unterstützen.

Konkret haben Neuerungen rund umHTML5 eine Annäherung von Ajax an„Stand-alone“-Clients gebracht, alsodie RIA(Ajax)-Box aus Abbildungˇ6nach unten vergrößert. Dazu zählen–ˇOffline-Möglichkeiten:ˇDurch denApplication Cache in HTML5 kann derAutor einer Webseite respektive Appli-kation bestimmen, welche Teile auchoffline verfügbar sein sollen. Diesewerden auf dem Gerät gespeichert unddann verwendet, wenn keine Online-verbindung vorhanden ist.–ˇLocal Storage und Indexed Data-base:ˇWie erwähnt, wurde mit HTML5der Local Storage eingeführt. Somitkann nun ein RIA-Ajax-Client mit derHypertext Markup Language bis zu ei-ner gewissen Menge seine Daten selbstverwalten und benötigt hierfür keinen

iX 12/2011 89

Was ist eine RIA? –Auswertung

Zeit zur Auflösung des Quiz: Die Sum-me zeigt, was der Quiz-Teilnehmer un-ter einer RIA versteht (Abb.ˇ7).

Wer als Summe 21 hat, meint Ajax,wenn er von RIA spricht und denkt anTechniken wie JSF, ASP und GWT.

Beträgt die Summe 11, wurde die Mäch-tigkeit, die Plug-ins in die Interaktioneinbringen, mit der Einfachheit des De-ployment von Ajax vermengt. Leidergibt es keine Technik, die dies vollstän-dig unterstützt – selbst HTML5 nicht.Bleibt nur die Hoffnung, dass der tech-nische Fortschritt die Hürden eines Ta-ges eliminiert. Bis dahin gilt es, auf ei-ner der Achsen Abstriche zu machen.

Diejenigen, deren Summe 12 beträgt,ordnen RIAs komplett der Plug-in-Weltzu, also Techniken wie Flex, Silverlight,JavaFX und Applets.

Lautet die Ergebnis-Summe 22, ist dasVerständnis von RIA nicht auf eine RIA-Kategorie festgelegt.

�� (��

��

�!

��

��

��

�� !"�� #��

��/��0��

��$%�

,,

,---

-,

ix.1211.086-091 07.11.2011 17:49 Uhr Seite 89


Server. Für größere Datenmenge gibt eseine lokale Datenbank.–ˇFile-API:ˇHTML5 hat eine mächtigeAPI zum Lesen und Schreiben von Da-teien eingeführt. Unter anderem lassensich Daten auf einfache Weise asyn-chron hochladen oder in ein temporä-res Verzeichnis kopieren.–ˇGeolocation:ˇMit Geolocation kannein Anwender die Position seines Mo-biltelefons (sofern verfügbar und er-laubt) abfragen. Bei PCs handelt essich dabei meist um die Position desZugangspunktes des Internet-Providers.–ˇDevice Elements:ˇHTML5 erlaubtden Zugriff auf Hardware-Elemente desGeräts wie Kamera oder GPS-Sensor.Allerdings sind nicht alle Sensoren stan-dardisiert ansprechbar. Beispielsweisehat HTML5 keine Kompass-API. Die inder Entwurfsphase befindliche Spezifi-kation „DeviceOrientation Event Speci-fication“ (siehe „Onlinequellen“ [a] undiX-Link) wird es erlauben, herauszufin-den, wie das Mobiltelefon oder der PCorientiert ist und welche Beschleuni-gungskräfte darauf einwirken.–ˇWeb Messaging:ˇChannel Messagingerlaubt die Kommunikation zwischenBrowsern.

Weitere Neuerungen verbessern zu-dem die Interaktion und vergrößerndamit die RIA(-Ajax)-Box aus Abbil -dungˇ6 nach rechts.

Das Einführen neuer Typen für dasElement input etwa vereinfacht die Ein-gabe von Daten. Smartphones können

darauf reagieren und die eingeblendeteTastatur optimieren (bei Zahlen nur Zah-len, bei E-Mail das @-Zeichen an einerschnell auffindbaren Stelle und so wei-ter). Darüber hinaus gibt es neue Typenfür Datum, Zeit und Farben. Somit istes für den Benutzer einfacher, Dateneinzugeben beziehungsweise auszu-wählen. Prinzipiell ging das zwar schonvor HTML5, aber der Webentwicklermusste entweder eine komfortable Ein-gabemöglichkeit selbst programmierenoder auf eine Bibliothek zurückgreifen.

Mit HTML5 erhält das Element in-put das Attribut Pattern. Diese RegularExpression dient zur Validierung derBenutzereingabe.

Dragˇ&ˇDrop ist in HTML5 einge-baut und nun ohne Bibliotheken ver-wendbar. Der Entwickler kann auch ei-gene Typen definieren.

Canvas und WebGL erlauben überScripts ein einfaches Rendering vonSzenen, sodass man Teile der Benutzer-schnittstelle selbst professionell gestal-ten kann. Die nötige Performance wirdüber das Ansprechen der lokalen Gra-fikhardware erreicht.

Web-Sockets ermöglichen unter an-derem die Kommunikation zwischenServer und Client und zwar ohne auf-wendige Workarounds wie „Long Pol-ling“ oder den Einsatz von Bibliotheken.Gibt es auf dem Server ein Ereignis,kann er das dem Client sofort mitteilen.Reverse-Ajax respektive Server-Push istsomit standardisiert und ohne Kniffe ge-löst. Über Web-Sockets lässt sich ähn-lich kommunizieren wie über Socketszwischen Rich Clients und Server.

HTML5 ist mehr als ein HypeHTML5 verschiebt also die Grenzenvon RIAs mit Ajax. Somit lassen sichmit den hinter der Spezifikation stehen-den Konzepten Aufgaben relativ ein-fach lösen, die vorher nicht oder nurmit Aufwand und unter Einbeziehungproprietärer Software realisierbar wa-ren. Die Grenzen von RIAs mit Ajaxkann HTML5 aber (noch) nicht beseiti-gen. Beispielsweise lassen sich nicht

alle Sensoren eines Mobiltelefons stan-dardisiert ansprechen.

Laut Gartner Hype Cycle [b] weckenneue Techniken zuerst eine übertriebeneErwartungshaltung, gefolgt von Desillu-sionierung (Tal der Tränen). Die Tech-nik gewinnt wieder an Boden, wennRealismus die Oberhand gewinnt, odersie verschwindet, weil sie doch keinewirkliche Innovation darstellt oder ihreNachteile überwiegen. HTML5 wirdnicht im Tal der Tränen verbleiben, dadas Verschieben der Grenzen neue Mög-lichkeiten eröffnet hat.

Weder Schichtenarchitektur nochaktuelle Trends sollten die Auswahl derClient-Technik bestimmen. Organisato-rische und projektbedingte Rahmenbe-dingungen bestimmen die vertikale unddas Interaktionsverhalten die horizon-tale Achse der Matrix aus Abbildungˇ6.Abbildungˇ8 zeigt entscheidende Rah-menbedingungen und Anwendungsfälleohne Anspruch auf Vollständigkeit.

Treffen obige Rahmenbedingungenzu, sollte die Entscheidung RichtungWeb-Client gehen. Gelten die unterenAnforderungen, ist eine Stand-alone-Applikation die richtige Wahl. Sollte derlinke Anwendungsfall auf die Applika-tion zutreffen, bietet sich ein einfacherClient an, und aufgrund der Kostengren-ze wird es ein Thin Client sein. Die An-wendungsfälle auf der rechten Seiteverlangen eine Applikation mit hohemAnteil von Benutzerinteraktion. Auf-grund der Machbarkeits- und Kosten-grenze wird man sich in dem Fall eherfür einen Fat, Smart oder Rich Cliententscheiden oder allenfalls für eine RIAohne Browser.

Allerdings gehören konkurrierendeund widersprüchliche Anforderungenund Rahmenbedingungen zum Pro jekt-alltag. So auch in diesem Fall. ZumBeispiel kann der Anwendungsfall „stän-dige Datenerfassung“ zu den Anforde-rungen gehören und gleichzeitig „kei-ne Installation“ von höheren Instanzenim Unternehmen als Rahmenbedingungvorgegeben sein. „Keine Installation“und „Offline-Fähigkeit“ werden eben-falls häufig gleichzeitig gefordert.

Drei Maßnahmen können solcheKonflikte lösen:–ˇpriorisieren (respektive bei einzelnenAnforderungen Abstriche machen),–ˇMehrkanalfähigkeit anstreben, alsomehrere Clients entwickeln und–ˇhohen Aufwand investieren, um alleAnforderungen in einem Client zu er-füllen.

Wie sich solche Konflikte lösen las-sen, zeigen im Folgenden drei Beispiele.

90 iX 12/2011

REPORT Web-Clients

�� (��

��

�!

��

��

��

��

��!"�� #��

��/��0��

��$%��

��

��$%��..��

�� $�/� ��&�'��!"�#�

��0��

��

��!!��#��#�

��

0��

��

��

��1�/��

�

��

��

0��

��1�/��0��!��

Alle Kriterien für die Auswahl derrichtigen Client-Technik auf einenBlick (Abb.ˇ8)

[a] DeviceOrientation dev.w3.org/geo/api/spec-source-orientationEvent Specification

[b] Gartner Hype Cycle www.gartner.com/technology/research/methodologies/hype-cycle.jsp[c] Stopping the Gears gearsblog.blogspot.com/2011/03/stopping-gears.html

Onlinequellen

ix.1211.086-091 07.11.2011 17:49 Uhr Seite 90


Eine sehr spezielle Anforderungskom-bination ist „Daten lesen“ und „ständi-ge Interaktion“. Wahrscheinlich stehenhier zwei unterschiedliche Arten vonBenutzertypen hinter den Anforderun-gen (siehe Flückiger und Richter zumPersonas-Modell [1]). BeispielsweiseSachbearbeiter (Eingabe) und Manager(Reports). An dieser Stelle ist die Über-legung angebracht, zwei Applikationenzu entwickeln. Eine für die Reports undeine für die Erfassung. Die Konflikt -lösungsstrategie „mehrere Clients schrei-ben“ ist hier aus Usability-Gründen amnaheliegendsten.

Will man den Widerspruch zwischen„keine Installation“ und „hohe Datener-fassung“ auflösen, sollte man priorisie-ren, also eine der Anforderungen ab-schwächen oder fallen lassen. Gewinntdie hohe Datenerfassung, kann vielleichteine RIA-Technik, die näher an Web ist,die Installationsproblematik lösen. Ist„keine Installation“ ein Killerkriterium,muss man besonderes Augenmerk aufdie Benutzerschnittstelle legen. Unzu-friedene Anwender nutzen eine Applika-tion nicht – selbst dann nicht, wenn sienichts installieren müssen. Zudem sinktdie Motivation, und die Fehleranfällig-keit steigt, wenn Mitarbeiter schnellerarbeiten könnten, als es die Applikationzulässt.

Mehrere Clients sind – sofern es dieFinanzen erlauben – ebenfalls eine guteWahl. Was sich auf den ersten Blickverschwenderisch anhört, kann sich alsWettbewerbsvorteil herausstellen. AlsAnwendungsbeispiel sei die Fotobestel-lung über das Internet genannt. Oft gibtes einen rudimentären Web-Client, überden Anwender Fotos hochladen undbestellen können. Daneben steht häu-fig ein RIA-Client zur Verfügung, derMassen-Uploads und Bildmanipulatio-nen erlaubt. Einige Anbieter haben da-rüber hinaus einen Rich Client für dielokale Bildbearbeitung, mit dem derBenutzer ein Foto beispielsweise zu-schneiden und die roten Augen entfer-nen kann, ohne dass er den Server desLabors bemühen muss. Erst am Endedieser Vorarbeiten werden die Bilderhochgeladen. Dies kann für einigeKunden angenehmer sein, als die Bil-der zuerst hochzuladen und dann zubearbeiten. Die Foto-Labors wendensich mit ihren Clients an unterschiedli-che Benutzergruppen: von Personen,die nur schnell die Fotos hochladenund bestellen wollen, bis zu Stamm-kunden, die eine lokale Applikationinstalliert haben, alles vorbereiten underst danach alles hochladen.

E-Mail ist hierfür ein weiteres Bei-spiel. Nur einen Rich Client zu habengenügt nicht. Web-Clients sind Pflicht.

Ein weiterer Widerspruch ist derzwischen den häufig geäußerten Anfor-derungen „keine Installation“ und „Off -line-Fähigkeit“. Das Bedürfnis nachOffline-Fähigkeit wächst seit Jahrenimmer mehr. So gab es früh Lösungs-ansätze wie Googles Gears. Das Projektwird aber nicht mehr weiterentwickeltund soll Ende 2012 eingestellt wer-den [c]. Die Anstrengungen des Gears-Teams sind in HTML5 eingeflossen.

ZusammenfassungKomplexe, interaktive Web-Clients ha-ben technische Grenzen. HTML5 ver-schiebt diese Grenzen und hat somit dasPotenzial, sich über einen Hype hinauszu etablieren. Als Voraussetzung fürseinen breiten Einsatz müssen sich dieHTML5-fähigen Browser etablieren.

HTML wird jedoch auch dann Tech-niken aus anderen Client-Kategoriennicht verdrängen. Um die richtige Kate-gorie zu finden, muss man weiterhin dieAnforderungen analysieren. Entschei-dend sind Rahmenbedingungen wie„keine Installation“ und „Offline-Fä-higkeit“ sowie das Interaktionsverhal-ten des Anwenders, der „Daten lesen“und „ständige Datenerfassung“ betrei-ben soll. Ignoriert man die Anforderun-gen aus Rahmenbedingungen und Inter-aktionsverhalten der Benutzer zugunsteneiner bevorzugten Technik, muss manmit höheren Entwicklungskosten oderAkzeptanzproblemen rechnen.

Mit HTML5 sind reichere RIAsmöglich geworden. Ist aber eine hoheInteraktion oder automatische Hard-ware-Interaktion gefordert, sind RichClients „reicher“. (ka)

NIKOLAOS KAINTANTZIS arbeitet als Softwarearchitekt bei Zühlke Engineering und leitet dort imCompetence Center Client Technologydie Java--Gruppe.

Literatur[1]ˇMarkus D. Flückiger, Michael Rich-

ter; Usability Engineering kompakt:Benutzbare Software gezielt ent -wickeln; Spektrum Akademischer Verlag, 2007

iX 12/2011 91

Alle Links: www.ix.de/ix1112086 x

ix.1211.086-091 07.11.2011 17:49 Uhr Seite 91


Ix 12 2011_reicher_werden_kaintantzis

Technology

Transcript of Ix 12 2011_reicher_werden_kaintantzis