Ix 12 2011_reicher_werden_kaintantzis

  • Published on
    22-Oct-2014

  • View
    1.243

  • Download
    0

DESCRIPTION

Der Begriff Rich Internet Application kurz RIA ist zwar gngig, aber nicht konkret definiert. Wer eine RIA entwickeln will, sollte genau wissen, was sie von Thin und Rich Clients unterscheidet. Und vor allem: welche neuen Funktionen HTML5 fr diese Aufgabe mitbringt.

Transcript

ix.1211.086-091

Rich Internet Applications (RIAs) sol-len vor allem eins gewhrleisten: ei-ne den Desktop-Clients vergleichbarekomfortable Bedienbarkeit im Browser.Google hat mit gut aussehenden undleicht zu bedienenden Anwendungenvorgemacht, wie RIAs sich prsentierenknnen. Die neue Richness im Inter-net ist allgegenwrtig. Moderne Web-Clients fr E-Mail, Wegbeschreibungenoder Suchfunktionen fr Adressen ha-ben aber bei den Anwendern auch neueErwartungen bezglich Interaktivittund Leistungsfhigkeit geweckt, die sievon Desktop-Applikationen her kennen eine Herausforderung fr 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 erfllen odersogar bertreffen. Dabei knnen An-forderungen an die Benutzerinterak -tion so unterschiedlich formuliert seinwie Stndige 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 gewhrleisten. Hilfreich dabei sinddie Navigation mit der Tastatur und dasVerwenden von Tastenkrzeln fr hu-fige Aufgaben. In diesem Fall unter-

sttzt eine lokal installierte Applikationden Benutzer am besten.

Im zweiten Fall will der Benutzerschnell informiert werden. Er selbstgibt Informationen wenn berhaupt nur in Form lngeren, 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 gehren Anforderungenwie das Umgehen mit unterschiedli-chen Versionen einer Applikation oderdass Applikationen auf jedem Firmen-PC vorhanden respektive von jedemFirmen-PC aus erreichbar sein mssen.

Ein hufig verlangter Aspekt ist Off -line-Fhigkeit. Beispielsweise soll einAuendienstmitarbeiter beim Kundenvor Ort eine Offerte ohne Netzverbin-dung erstellen. Wenn er zurckkommtund der Laptop am Netz ist, soll die Ap-plikation beginnen, Daten zu synchroni-sieren. Ein anderes Beispiel: Benutzersollen E-Mails offline schreiben knnen,die automatisch abgeschickt werden,wenn das Netz wieder verfgbar ist.

Will man schnell viele Personen er-reichen, dient dazu hufig eine Appli-kation, die man nicht installieren muss.Der Anwender soll nicht warten ms-sen, bis die Applikation benutzbar ist.So soll er etwa die News einer Zeitungschnell lesen knnen, ohne zuvor einPlug-in zu installieren oder ein Pro-gramm zu aktualisieren. Keine Installa-tion bedeutet zudem, dass man keineInfrastruktur fr ein effizientes undschnelles Rollout bentigt und so dieVertriebsinfrastruktur einsparen kann.

In diesem Umfeld von Forderungen,Rahmenbedingungen und Benutzer -ansprchen ist es wichtig, die unter-schiedlichen Client-Kategorien Thin,RIA und Rich auseinanderzuhalten.Nur so kann man die richtige Katego-rie und schlielich die richtige Technikfr eine Aufgabe whlen.

RIA ist nicht gleich RIADas RIA-Konzept befindet sich imSpektrum zwischen klassischen seiten-basierten Webseiten (Thin Clients) und Stand-alone-Applikationen (RichClients) (siehe Abbildung1). Zu Erste-ren gehren etwa die Internetseiten vonZeitungen, whrend man zu den Stand-alone-Applikationen Pakete wie MSOffice, Photoshop oder Entwicklungs-

86 iX 12/2011

REPORT Web-Clients

Wie HTML5 Rich Internet Applications verndert

Reicher werden Nikolaos Kaintantzis

Der Begriff Rich Internet Application kurz RIA ist zwar gngig, 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 fr 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 gefllt,kann er sie auf den Desktop ziehenoder herunterladen. Beispiele hierfrsind Java Web Start und Adobe AIR.

HTML5 gehrt 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 Abbildung2.Je nher 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-zufhren, etwa weil er JavaScript ausGrnden der Firmen-Policy gar nichtaktivieren kann oder keine Administra-torrechte fr die Installation einer Ap-plikation auf seinem Rechner hat.

!

Fr den Anwender ist wichtig, was erinstallieren muss (Abb.2).

iX 12/2011 87

x-TRACT Webapplikationen gibt es in diversen Ausprgungen von der einfachen Webseite

bis zur Rich Internet Application , die sich fr 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 Ausfhrungsumgebung.

Whrend sich bisher einige Funktionen nur durch zustzliche Bibliotheken oder Plug-ins realisieren lieen, knnen Entwickler sie jetzt nativ in Browsern nutzen, die HTML5 untersttzen.

Quiz: Was ist eine RIA?Der Begriff RIA ist allgegenwrtig, dochselten verstehen zwei Personen dasselbedarunter. Zwei Fragen sollen ermitteln,welches Verstndnis ein Leser an dieserStelle des Artikels von RIA hat (bitte diePunkte in Klammern addieren).Frage1: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.Frage2:RIAs bieten dieselben Mglich-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

Copyright by Heise Zeitschriften Verlag

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 Vorgngen. Um die Art derBenutzerinteraktion im Spektrum ein-

fach bis komplex/hoch (siehe Ab -bildung3) einordnen zu knnen, sollteman verschiedene Fragen stellen: SindDialoge erforderlich, die beispielsweiseeinen Kunden einem Produkt zuordnen?Gehrt das schnelle Arbeiten ber Tas-tatur-Navigation zu den Anforderungen?Bentigt der Anwender Drag&Drop,um zum Beispiel einen Datensatz ausder Datenbank von einer Applikationzur anderen zu schieben? Jede mit Jabeantwortete Frage erhht die Reich-haltigkeit der Interaktion und verlangtden Einsatz einer untersttzenden Tech-nik. Nicht alle Client-Kategorien un-tersttzen die Interaktion gleicherma-en. Abbildung4 verdeutlicht dies imKontext der Benutzerinteraktion undder Ausfhrungsumgebung.

Der Anwender hat seine eigene SichtGem Abbildung4 untersttzen 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 frdie gemeinsame Datenhaltung zustn-dig eventuell auch fr einen Teil derGeschftslogik. Microsofts Word istein Bespiel fr einen Rich Client, derkeinen Server bentigt. Outlook hinge-gen ist ein Rich Client mit Server, derfr die Aufbewahrung der Mails zu-stndig ist.

Deckt ein Client mehrere Schichtenab, kann die Kommunikation zwischenihm und dem Server in tieferen Schich-ten und weniger hufig erfolgen. Solchein Client hat ein schnelleres Antwort-verhalten, bietet somit eine bessere Be-nutzeruntersttzung und erlaubt so einflssigeres Arbeiten.

Im RIA-(Ajax)-Fall ohne HTML5kann der Client maximal die Schich-ten bis zur Geschftslogik abdecken.Gleichzeitig muss immer ein Servervorhanden sein. Er kann Aufgaben biszur Prsentationslogik bernehmen.Die daraus resultierende lngere Ant-wortzeit beeintrchtigt unter Umstn-den die Interaktivitt. KomplexereUser-Interfaces reagieren meistens ei-nen Tick zu langsam, sodass ein fls-siges Arbeiten nicht immer mglichist. Einen ganzen Tag intensiv mit ei-

nem Ajax-Client zu arbeiten, ist oftanstrengend.

Mit HTML5 lassen sich ebenfallsAjax-Applikationen realisieren. Abbil-dung5 zeigt, dass ein damit realisierterClient standardisiert in tiefere Schich-ten vordringen kann, ermglicht unteranderem durch Local Storage, IndexedDatabase und File-API. Ein RIA-Ajax-Client kann mit HTML5 seine Datenselbst verwalten und bentigt hierfrkeinen Server. Das fhrt 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 Interaktivitt auswirken.

Abbildung4 zeigt oben rechts undunten links freie Flchen, die nicht vonClient-Kategorien abgedeckt sind. FrRIAs mit Ajax gibt es technische Gren-zen, die noch nicht berwindbar sind.Dazu gehren unter anderem:Drag&Drop zwischen Applika -tionen: Diese Funktion steht fr Textund Bilder zwar zur Verfgung, aller-dings haben nicht die Applikationen dieKontrolle darber. Technisch gar nichtmachbar ist zurzeit das Verschiebenvon Business- oder Domain-Objektenzwischen Programmen (zum Beispieldas Kunden-Objekt von der Applika -tionA in die Stammdatenhaltung).Reaktionszeiten: Komplexere, inter-aktive Applikationen mit vielen Objek-ten knnen zu schlechten Reaktionszei-ten der Benutzerschnittstelle fhren.Automatische Hardware-Interak-tionen: Nicht mglich 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 Interaktionsmglichkei-ten als Rich Clients. Dies symbo lisiertdas Dreieck rechts oben in Abbildung6.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 esfrhzeitig zu erkennen und durch dieWahl einer passenderen Client-Kate-gorie zu vermeiden, in die Pareto-Falle zu tappen. Diese 80/20-Regelbesagt, dass 80Prozent 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

Copyright by Heise Zeitschriften Verlag

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

HTML5 hat dazu beigetragen, dieAjax-Box zu vergrern und somit dieGrenzen zu verschieben, unter anderemmit einer JavaScript-API fr nativesDrag&Drop. So kann man etwa Datei-en aus dem Dateisystem in eine Web-applikation hineinziehen. Auch dasDrag&Drop selbst definierter Typenist mglich. 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-bildung6) ist es oft effektiver, sich freinen Web-Client zu entscheiden.

Die Entwicklung mobiler Applikatio-nen (Apps) ist ein Geschftsfeld, in demRich Clients fr wenig interaktive Ar-beitsweisen erstellt werden. Die Opti-mierung von Webseiten fr jedes Handykann sich als ebenso umfangreich er-weisen wie eine Applikation nativ frdie Plattform beispielsweise iPhoneoder Android zu schreiben. Fr 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 fr sein Tele-fon optimiert wurde.

Wer jetzt sein eigenes Verstndnis,was eine RIA ausmacht, mit dem ver-gleichen mchte, das er am Anfang die-ses Artikels hatte, findet die Antwort inder Auswertung.

Konkrete Vernderungendurch HTML5Die Abbildungen5 und6 haben ge-zeigt, dass HTML5 neue Mglichkei-ten erffnet. Obwohl die Spezifikationnoch nicht fertig ist, untersttzen mo-derne Browser Teile davon bereits jetzt.Jede neue Browser-Generation bietetmehr Support fr das aktuelle HTML5.

Einige Funktionen, die HTML5 insRampenlicht rckt, lieen sich bereitsfrher mit JavaScript-Bibliotheken rea-lisieren. Jedoch musste der Entwicklerfr 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 frh und mglichstviel seiner Funktionen untersttzen.

Konkret haben Neuerungen rund umHTML5 eine Annherung von Ajax anStand-alone-Clients gebracht, alsodie RIA(Ajax)-Box aus Abbildung6nach unten vergrert. Dazu zhlenOffline-Mglichkeiten:Durch denApplication Cache in HTML5 kann derAutor einer Webseite respektive Appli-kation bestimmen, welche Teile auchoffline verfgbar sein sollen. Diesewerden auf dem Gert gespeichert unddann verwendet, wenn keine Online-verbindung vorhanden ist.Local Storage und Indexed Data-base:Wie erwhnt, wurde mit HTML5der Local Storage eingefhrt. Somitkann nun ein RIA-Ajax-Client mit derHypertext Markup Language bis zu ei-ner gewissen Menge seine Daten selbstverwalten und bentigt hierfr keinen

iX 12/2011 89

Was ist eine RIA? Auswertung

Zeit zur Auflsung 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.Betrgt die Summe 11, wurde die Mch-tigkeit, die Plug-ins in die Interaktioneinbringen, mit der Einfachheit des De-ployment von Ajax vermengt. Leidergibt es keine Technik, die dies vollstn-dig untersttzt selbst HTML5 nicht.Bleibt nur die Hoffnung, dass der tech-nische Fortschritt die Hrden eines Ta-ges eliminiert. Bis dahin gilt es, auf ei-ner der Achsen Abstriche zu machen. Diejenigen, deren Summe 12 betrgt,ordnen RIAs komplett der Plug-in-Weltzu, also Techniken wie Flex, Silverlight,JavaFX und Applets.Lautet die Ergebnis-Summe 22, ist dasVerstndnis von RIA nicht auf eine RIA-Kategorie festgelegt.

(

!

!"

#

/0

$%

,,

,---

-,

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

Copyright by Heise Zeitschriften Verlag

Server. Fr grere Datenmenge gibt eseine lokale Datenbank.File-API:HTML5 hat eine mchtigeAPI zum Lesen und Schreiben von Da-teien eingefhrt. 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 verfgbar 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 desGerts 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-gungskrfte darauf einwirken.Web Messaging:Channel Messagingerlaubt die Kommunikation zwischenBrowsern.

Weitere Neuerungen verbessern zu-dem die Interaktion und vergrerndamit die RIA(-Ajax)-Box aus Abbil -dung6 nach rechts.

Das Einfhren neuer Typen fr dasElement input etwa vereinfacht die Ein-gabe von Daten. Smartphones knnen

darauf reagieren und die eingeblendeteTastatur optimieren (bei Zahlen nur Zah-len, bei E-Mail das @-Zeichen an einerschnell auffindbaren Stelle und so wei-ter). Darber hinaus gibt es neue Typenfr Datum, Zeit und Farben. Somit istes fr den Benutzer einfacher, Dateneinzugeben beziehungsweise auszu-whlen. Prinzipiell ging das zwar schonvor HTML5, aber der Webentwicklermusste entweder eine komfortable Ein-gabemglichkeit selbst programmierenoder auf eine Bibliothek zurckgreifen.

Mit HTML5 erhlt 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 ntige Performance wirdber das Ansprechen der lokalen Gra-fikhardware erreicht.

Web-Sockets ermglichen 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-lst. ber Web-Sockets lsst 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 lsen, die vorher nicht oder nurmit Aufwand und unter Einbeziehungproprietrer 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 Trnen). 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 Trnen verbleiben, dadas Verschieben der Grenzen neue Mg-lichkeiten erffnet 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 Abbildung6.Abbildung8 zeigt entscheidende Rah-menbedingungen und Anwendungsflleohne Anspruch auf Vollstndigkeit.

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-wendungsflle auf der rechten Seiteverlangen eine Applikation mit hohemAnteil von Benutzerinteraktion. Auf-grund der Machbarkeits- und Kosten-grenze wird man sich in dem Fall eherfr einen Fat, Smart oder Rich Cliententscheiden oder allenfalls fr eine RIAohne Browser.

Allerdings gehren konkurrierendeund widersprchliche Anforderungenund Rahmenbedingungen zum Pro jekt-alltag. So auch in diesem Fall. ZumBeispiel kann der Anwendungsfall stn-dige Datenerfassung zu den Anforde-rungen gehren und gleichzeitig kei-ne Installation von hheren Instanzenim Unternehmen als Rahmenbedingungvorgegeben sein. Keine Installationund Offline-Fhigkeit werden eben-falls hufig gleichzeitig gefordert.

Drei Manahmen knnen solcheKonflikte lsen:priorisieren (respektive bei einzelnenAnforderungen Abstriche machen),Mehrkanalfhigkeit anstreben, alsomehrere Clients entwickeln undhohen Aufwand investieren, um alleAnforderungen in einem Client zu er-fllen.

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

90 iX 12/2011

REPORT Web-Clients

(

!

!"

#

/0

$%

$%..

$/ &'!"#

0

!!##

0

1/

0

1/0!

Alle Kriterien fr 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

Copyright by Heise Zeitschriften Verlag

Eine sehr spezielle Anforderungskom-bination ist Daten lesen und stndi-ge Interaktion. Wahrscheinlich stehenhier zwei unterschiedliche Arten vonBenutzertypen hinter den Anforderun-gen (siehe Flckiger und Richter zumPersonas-Modell [1]). BeispielsweiseSachbearbeiter (Eingabe) und Manager(Reports). An dieser Stelle ist die ber-legung angebracht, zwei Applikationenzu entwickeln. Eine fr die Reports undeine fr die Erfassung. Die Konflikt -lsungsstrategie mehrere Clients schrei-ben ist hier aus Usability-Grnden amnaheliegendsten.

Will man den Widerspruch zwischenkeine Installation und hohe Datener-fassung auflsen, sollte man priorisie-ren, also eine der Anforderungen ab-schwchen oder fallen lassen. Gewinntdie hohe Datenerfassung, kann vielleichteine RIA-Technik, die nher an Web ist,die Installationsproblematik lsen. Istkeine Installation ein Killerkriterium,muss man besonderes Augenmerk aufdie Benutzerschnittstelle legen. Unzu-friedene Anwender nutzen eine Applika-tion nicht selbst dann nicht, wenn sienichts installieren mssen. Zudem sinktdie Motivation, und die Fehleranfllig-keit steigt, wenn Mitarbeiter schnellerarbeiten knnten, als es die Applikationzulsst.

Mehrere Clients sind sofern es dieFinanzen erlauben ebenfalls eine guteWahl. Was sich auf den ersten Blickverschwenderisch anhrt, kann sich alsWettbewerbsvorteil herausstellen. AlsAnwendungsbeispiel sei die Fotobestel-lung ber das Internet genannt. Oft gibtes einen rudimentren Web-Client, berden Anwender Fotos hochladen undbestellen knnen. Daneben steht hu-fig ein RIA-Client zur Verfgung, derMassen-Uploads und Bildmanipulatio-nen erlaubt. Einige Anbieter haben da-rber hinaus einen Rich Client fr dielokale Bildbearbeitung, mit dem derBenutzer ein Foto beispielsweise zu-schneiden und die roten Augen entfer-nen kann, ohne dass er den Server desLabors bemhen muss. Erst am Endedieser Vorarbeiten werden die Bilderhochgeladen. Dies kann fr 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 hierfr ein weiteres Bei-spiel. Nur einen Rich Client zu habengengt nicht. Web-Clients sind Pflicht.

Ein weiterer Widerspruch ist derzwischen den hufig geuerten Anfor-derungen keine Installation und Off -line-Fhigkeit. Das Bedrfnis nachOffline-Fhigkeit wchst seit Jahrenimmer mehr. So gab es frh Lsungs-anstze 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 frseinen breiten Einsatz mssen sich dieHTML5-fhigen Browser etablieren.

HTML wird jedoch auch dann Tech-niken aus anderen Client-Kategoriennicht verdrngen. Um die richtige Kate-gorie zu finden, muss man weiterhin dieAnforderungen analysieren. Entschei-dend sind Rahmenbedingungen wiekeine Installation und Offline-F-higkeit sowie das Interaktionsverhal-ten des Anwenders, der Daten lesenund stndige Datenerfassung betrei-ben soll. Ignoriert man die Anforderun-gen aus Rahmenbedingungen und Inter-aktionsverhalten der Benutzer zugunsteneiner bevorzugten Technik, muss manmit hheren Entwicklungskosten oderAkzeptanzproblemen rechnen.

Mit HTML5 sind reichere RIAsmglich geworden. Ist aber eine hoheInteraktion oder automatische Hard-ware-Interaktion gefordert, sind RichClients reicher. (ka)

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

Literatur[1]Markus D. Flckiger, 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

Copyright by Heise Zeitschriften Verlag

Recommended

View more >