stay tuned

LuGo ist nicht die einzige verfügbare API die auf eine Abstraktion hinsichtlich nativen Vektorgrafik-Technologien anbietet. Daher sollte man an dieser Stelle, API’s mit ähnlicher Funktionalität anführen:

• RaphaelJS
• Dojo GFX

Im folgenden sollen nun die beiden API’s bezüglich Skriptgröße & Rendering-Zeit mit Lugo verglichen werden.

Versionen

• Dojo 1.4.0
• RaphaelJS 0.8.6
• LuGo alpha 0.3.1

Skriptgröße

Renderingzeit

In diesem Abschnitt soll nun überprüft werden, wie lange die jeweiligen API’s zum Rendern einer bestimmten Grafik brauchen. Dabei wurde darauf geachtet, dass das Testsetup bei allen API’s gleich ist. So wurden bspw. im Vorhinein benötigte Objekte  und deren Erzeugung von der Zeitmessung ausgeschlossen, sodass nur das eigentliche Erstellen der unten gezeigten Grafik berücksichtigt wurde.

Algorithmen

Folgende Grafik soll von den API’s erzeugt werden:

Mit Hilfe folgender Algorithmen wurden jeweils 360 Kreise mit selben Radius erzeugt. Eine Zeitmessung wurde jeweils vor und nach der Operationsausführung durchgeführt und daraufhin die Differenz, also die benötigte Ausführungszeit ermittelt. Im Folgenden sind nun die detailierten Funktionen der jeweiligen API angeführt, um eine Testreproduktion zu ermöglichen:

RaphaelJS

       function createCircles( quantity ) {
              canvas.clear();
              var radius = 15;
              for (var i=0; i < quantity; i++){
                     var shape = canvas.circle(
                           centerX + (Math.sin( i ) * radius ),
                           centerY + (Math.cos( i ) * radius ),
                           4
                      );
                      shape.attr("fill", "blue");
                      radius += 0.5;
              }//end for
       }

Dojo GFX

       function createCircles( quantity ) {
              canvas.clear();
              var radius = 15;
              for (var i=0; i < quantity; i++){
                     var shape = canvas.createCircle(
                           {
                               cx: centerX + (Math.sin( i ) * radius ),
                               cy: centerY + (Math.cos( i ) * radius ),
                               r: 4
                           }
                      );
                      shape.setFill("blue");
                      radius += 0.5;
              }//end for
       }

LuGo

      public void createCircles( int quantity ) {
              canvas.clear();
              int radius = 15;
              for (int i=0; i < quantity; i++){
                     canvas.add (
                          new Ellipse(
                             centerX + (Math.sin( i ) * radius ),
                             centerY + (Math.cos( i ) * radius ),
                             4,
                             new SolidFill( Color.BLUE )
                          )
                      );
                      radius += 0.5;
              }//end for
       }

Ergebnisse

Fazit

Fairerweise muss man hier anmerken, dass der Vergleich bzgl. IE nicht ganz stimmt. Denn aufgrund der mangeldnen Performance des Internet Explorers, wird hierbei nicht VML wie bei Raphael und Dojo, sondern Flash zur Darstellung der Objekte benutzt. Diese Erweiterung kommuniziert mit dem ExternalInterface von Flash und erzeugt dynamisch zur Laufzeit die notwendigen Objekte im leeren Flash-Film. Dies passiert auf einem sehr generischen Weg, sodass sämtliche Möglichkeiten die Lugo bietet (EventHandling – EventBus, Transformationen, Zoom&Pan Support, geometrische Objekte wie komplexe Pfade, etc.) auch zur Programmierung für IE zur Verfügung stehten.

Dabei sieht der Entwickler aufgrund der angestrebten Transparenz nicht, welche genaue Implementierung (SVG, VML, Flash) nun zur Anwendung kommen. Die API entscheidet abhängig vom Browser des Benutzers und der Komplexität der Anwendung, welche Implementierung am passenden ist.

Zu den Resultaten: Wie man bei den Diagrammen erkennen kann, ist ein sehr deutlicher Unterschied zwischen Raphael und Lugo/Dojo. So ist die Performance im IE zwar sehr ähnlich, bei allen anderen ergibt sich jedoch ein sehr großer Unterschied (Chrome: ~400 ms, Safari: ~270 ms, Firefox: ~400ms).

Des Weiteren kann man erkennen, das LuGo immer eine Spur schneller rendert als Dojo, mit Ausnahme von Firefox, wo Dojo deutlich führt. So könnte man sagen, dass Dojo und Lugo in etwa gleich schnell rendern, sich jedoch bei der Größe der Skriptdateien unterscheiden. Hierbei benötigt Dojo knapp über 300 kB während Lugo mit knapp 110 kB auskommt. (Und dabei ist zu berücksichtigen, dass sämtlicher Code, der für dieses Demo benötigt wird, inkludiert ist.)
Abschliessend muss man anmerken, dass in LuGo noch keinerlei Performanceoptimierungen erfolgten, da sich die API noch im der Pre-Alpha-Phase befindet.

Es befinden sich ständig 50 Particles auf der Bühne, deren Position alle 25 ms neu errechnet wird.
Seht selbst: Demo

Skriptgröße: 14 kB (gzip)

Abb 1. Terminal-Eingabemaske (links), Fullscreen-Beamer-Applikation (rechts)

Lugo vs. Canvas

Code Beispiel

     Canvas canvas = new Canvas(500, 500);

      //Create a rectangle at point {10, 10} with dimension {200, 100}
      Rectangle myRect = new Rectangle(10, 10, 200, 100);

      canvas.add(myRect);

      //set blue fillingcolor
      myRect.setFill( new SolidFill( Color.BLUE ) );

      //set Transparency
      myRect.setOpacity(80);

      //Transformations  e.g. rotation at a specific point
      myRect.rotateAt(90, new Point(250, 250) );

      //Enabling zoom and pan support
      CanvasZoomPanWrapper zoomPan = new CanvasZoomPanWrapper(canvas, true, true);

      //add event listener (zb: zoom Event)
      zoomPan.addZoomEventHandler( new ZoomEventHandler(){

           public void onZoom(int zoomLevel){

                //change opacity
                myRect.setOpacity( zoomLevel * 100 );
           } 

      });

Testcase

Ressources

• LuGo @ google code
• Demo

Source via SVN:

svn checkout http://lugo.googlecode.com/svn/trunk/ lugo-read-only

User Experience Framework

Wie schon aus der Definition und den Elementen hervorgeht, umschreibt User
Experience das Gesamterlebnis des Benutzers bei der Interaktion mit einer
Anwendung. Es liegt auf der Hand, dass das oberste Ziel eines User Experience Life-
Cycles die Schaffung von Anwendungen mit möglichst hohem Nutzungserlebnis ist
[MWBV08]. In diesem Kapitel soll nun der bekannte Life-Cycle nach Jesse James
Garrett beschrieben werden. Er postuliert, dass das User-Centric-Design eine zentrale
Rolle im Life-Cycle spielen muss und dass kein Aspekt ohne die Berücksichtigung
des Benutzers und dessen Erwartungen entwickelt werden sollte [Garr06].

Die Ebenen der User Experience

Garrett teilt User Experience in seinem Life-Cycle in fünf Ebenen: Strategy Plane,
Scope Plane, Structure Plane, Skeleton Plane und Surface Plane. Des Weiteren
unterscheidet er die Betrachtungsweise von Webseiten die entweder als Software
Interface oder Hypertext System angesehen werden können (siehe Abbildung 1).
Aufgrund dieser Betrachtungsweisen teilt er die fünf Ebenen in zwei Hälften, sodass
sich links befindende Element auf das Web als Software Interface, und rechts
stehende Elemente auf das Web als Hypertext System beziehen. Aus Benutzersicht
befindet sich links die Webseite als Tool um Aufgaben zu bewältigen und rechts als
Informationsquelle. Im Folgenden sollen nun diese Ebenen angeführt und näher
erläutert werden.

Strategy Plane

Die Grundlage erfolgreichen User Experience ist eine klar kommunizierte Strategie
[Garr06]. Auf dieser Ebene stehen die strategischen Ziele der Webseite und die
Benutzerbedürfnisse an erster Stelle. Das Ziel hierbei heißt Benutzerbedürfnisse zu
befriedigen. „Man muss verstehen, was Kunden verlangen und versuchen sie mit
anderen Kundenwünschen zu kombinieren.“ [Garr06]
Die Ziele des Unternehmens (meist wirtschaftlicher Natur) müssen mit den
Benutzerbedürfnissen abgeglichen werden. Da die Bedürfnisse der Benutzer (User
Needs) sehr breit gefächert sind, ist es schwierig diese zu identifizieren. Eine
Möglichkeit diese Bedürfnisse zu befriedigen ist es, ‚personas‘ (user models) zu
verwenden (siehe 4. Methoden und Techniken).
Die grundsätzlichen Fragen die zu klären sind: „Was wollen wir an Output von
dieser Seite?“ und Was wollen unsere Benutzer von ihr haben?“ [Garr06]. Diese
beiden Fragen müssen gegenübergestellt und eine Lösung für beide Seiten gesucht
werden. Auf der einen Seite, die Ziele der Webseite, auf der anderen die Ziele des
Benutzers. Wie bereits erwähnt, gibt es primär Business Ziele, d.h. Umsatz, Gewinn,
Marke, etc. Wichtig bei der Markenidentität ist jedoch nicht nur die Marke bzw. das
Logo, sondern auch der visuelle Faktor, d.h. wenn eine Webseite ihre visuelle Marke
besitzt und diese den Benutzer anspricht, wird er wieder kommen.
Der nächste Schritt ist, zu wissen, wann man sein Ziel erreicht hat. Es gibt
bestimmte Indikatoren, wie Erfolgsmetriken, die man dafür einsetzen kann [Garr06].
Diese Metriken beeinflussen nicht nur die Entscheidungen während der Erstellung
einer Webseite, sondern sie liefern auch Kontrollwerte für User Experience, wie z.B.
Besucheranzahlen der Webseite.
Eine große Herausforderung ist die Webseite den Benutzern optimal anzupassen.
Das Problem dabei ist, dass es nicht nur DEN Benutzer gibt, sondern dass jeder
Benutzer unterschiedliche Erwartungen und Bedürfnisse an eine Webseite stellt. Es
wäre nun naheliegend, die Webseite für einen idealen Benutzer zu erstellen, wie z.B.
dem Designer. Die Webseite muss jedoch für alle Benutzer ‚ideal‘ gestaltet werden.
Um nun Benutzer zu gruppieren und einschätzen zu können, wird eine
Benutzersegmentierung vorgenommen, d.h. demographisch, psychographisch, usw.
Weiters werden Untersuchungsgruppen gebildet, welche die Webseiten testen. Diese
Gruppen werden aus verschiedenen Benutzern zusammengesetzt, d.h.
unterschiedlicher demographischer sowie psychographischer Herkunft [Garr06].

Scope Plane

Um die Entscheidung treffen zu können, welche Elemente, Fähigkeiten,
Eigenschaften, Besonderheiten und Merkmale auf einer Webseite untergebracht
werden sollen, muss man Klarheit darüber schaffen, was man selbst als Unternehmen
möchte und der Benutzer von der diese Webseite erwartet. Erst damit kann man alle
oben genannten strategischen Ziele erfüllen. D.h. Scope Plane beschreibt die
Selektion von Features und Inhalten einer Webseite und versucht diese optimal an alle
Bedürfnisse anzupassen. Eine Strategie wird erst dann zu einem konkret formulierten
Inhalt, wenn man die User Needs und die Ziele des Unternehmens in detaillierte
Anforderungen für den Inhalt und die Funktionalität der Webseite übersetzt [Garr06].
Dabei grenzt man die Anforderungen insofern ab, in jene die man erfüllen möchte,
und jene die man dezidiert nicht möchte. Das bedeutet man stellt Funktionalität und
Inhalt gegenüber und prüft, welche Elemente man realisieren möchte. Die einfachste
Methode um Anforderungen herauszufinden ist die Benutzer schlicht und einfach zu
befragen. Wichtig dabei ist, dass man beim Thema und dem eigentlichen Inhalt bleibt
und gezielt auswählt. Garrett schlägt folgende drei Maßnahmen vor um dies zu
erreichen: Positiv formulieren, spezifisch formulieren, subjektive Sprache vermeiden.

Structure Plane

Beziehungen zwischen den ermittelten Anforderungen und Abläufen auf einer
Webseite werden im Structure Plane festgelegt. Navigationsabläufe, flüssige und
inhaltlich zusammenpassende Bereiche sowie der Informationsfluss einer Webseite
sind für den Benutzer wichtig [Kalb07]. Aus der Softwareentwicklung ist diese
Modellierungsart als ‚Interaction Design‘ bekannt, während hingegen im Content
Development diese als ‚Information Architecture‘ (Informationsarchitektur)
bezeichnet wird.
Bei der Entwicklung dieser Architektur ist es von Bedeutung auf mehrere Faktoren
zu achten, wie etwa die Einhaltung von Konventionen, da der Wiedererkennungswert
für Benutzer wichtig ist, und sie mit Bekanntem besser umgehen können. Ein weiteres
Element ist die Fehlerbehandlung; wohin wird der Benutzer nach Auftreten eines
Fehler verwiesen, und kommt die Webseite in einen konsistenten Zustand zurück?
Um diese Punkte sicherzustellen sind drei Elemente von Bedeutung, nämlich
Prävention, Korrektur und Wiederherstellung [Garr06].
Für die Darstellung von Information ist bei der Structure Plane die Einhaltung von
Organisationsprinzipien (Daten) notwendig. Damit ist die hierarchische Struktur etwa
von Daten in einer Baumdarstellung gemeint. D.h. nach welchen Inhalten wird
gruppiert, welche Werte stehen oben im Baum, etc. Zum Beispiel bei einer Newsorientierten
Seite wird wahrscheinlich chronologisch gruppiert werden.

Skeleton Plane

Auf dieser Ebene wird die konzeptuelle Struktur detailliert betrachtet und es werden
spezifische Aspekte des Interfaces, der Navigation und des Informationsdesigns
identifiziert. Diese drei Elemente sind eng miteinander verbunden und legen den
Grundstein für den Skeleton Plane. Beim Skeleton Plane wird der Fokus auf
individuelle Seiten und deren Komponenten gelegt im Gegensatz zum Structure
Plane. [Garr06]

Erfolgreiche Webseiten sind jene, wo ein Benutzer nach betreten
einer Seite sofort den wichtigen Inhalt erkennt und den unwichtigen ausblendet bzw.
nicht beachtet. Um das zu erreichen, sind mehrere Schritte notwendig [Garr06]:

• Interface Design: Der Inhalt von Checkboxen, Radio Buttons, Textfelder,
  Dropdownlisten, Listboxen, etc. ist wichtig und soll gezielt gewählt und deren
  Verwendung und Anordnung an das Gesamtbild der Teilseite angepasst werden.
• Navigation Design: Globale, lokale, kontextuelle und die ‚zuvorkommende‘
  Navigation sollen geplant und an den Benutzer angepasst werden.
• Information Design: Welcher Inhalt wird wie angeordnet und vermittelt.
• Wayfinding: Das erfolgreiche Finden eines Weges durch die Website mit
  schlüssigem Inhalt, ist für den Benutzer wichtig. Dazu können Farben oder andere
  Hinweise verwendet werden, sollen aber dem Benutzer genug Freiraum zur eigenen
  Entscheidung lassen.

Surface Plane

Inhalt, Funktionalität und Ästhetik müssen zu einem fertigen visuellen Design
welches alle Erwartungen und Ziele erfüllt, zusammengeführt werden [Garr06]. Dabei
ist es nicht einfach nur wichtig eine ‚coole‘ Webseite zu gestalten, sondern sich
seinem strategischen Ziel klar zu werden und den Nutzen daraus zu ziehen, z.B. bei
der Vermittlung einer Markenphilosophie.
Um die Elemente einer Webseite nun bestmöglich anzuordnen und zu gestalten,
sind Methoden wie Eyetracking hilfreich, welche feststellen wo die Blickpunkte eines
Benutzers auf einer Webseite sind. Weiters sind Faktoren wie Kontrast und
Einheitlichkeit wichtig um z.B. Bereiche zu trennen und gewissen Objekten einen
höheren Stellenwert beizumessen [Garr03].

Methoden und Techniken

Nachdem der theoretische Hintergrund zu User Experience erklärt wurde, soll nun der
Frage nach Techniken und Methoden im Zusammenhang mit User Experience
nachgegangen werden. Aufgrund der Seminarrichtlinien beschränken wir uns hierbei
auf ausgewählte Methoden und Techniken. So wird ausgehend vom, unter Punkt 3
beschriebenen Modell, pro Ebene, eine Methode bzw. ein Technikansatz beschrieben.
Da der Begriff des Web 2.0 bereits in aller Munde ist, soll dieser Abschnitt mit einer
näheren Betrachtung des Web 2.0 im Kontext der User Experience abschließen, was
die Methodik für die obersten beiden Ebenen des Frameworks von Garrett darstellt.
Für die Ebene „Scope Plane“ werden keine Methoden angeführt, da diese aus dem
Web-Engineering übernommen werden können.

Personas

Auf der untersten Ebene des Frameworks stellt sich die wesentliche Frage nach den
Benutzeranforderungen. Das Ziel dieser Ebene ist die Erfüllung der
Benutzerbedürfnisse. Da dieser Ebene ein sehr hoher Stellenwert beigemessen wird
und sie wesentlich zum Erfolg einer Webseite beiträgt, findet man in der Literatur
auch dementsprechend viele unterschiedliche Ansätze zur Erhebung der
Benutzerwünsche. Eine allseits beliebte und nützliche Methode sind Personas (vgl.
[Sinh03]).

Unter Personas versteht man das Entwickeln von fiktiven Benutzern die
eine oder mehrere Ausprägung der Zielgruppe darstellen. Diese Personas
repräsentieren dann einen Benutzer oder eine Benutzergruppe mit ihren Erwartungen,
Zielen und Wünschen. Des Weiteren beschreibt man Charakteristika, Einstellungen
und Verhaltungsweisen des fiktiven Benutzers. Danach wird dem ein Foto und Name
zugeordnet, um der fiktiven Person „Leben“ einzuhauchen.

Abbildung 2 zeigt ein Beispiel für einen fiktiven Benutzer. Obwohl Personas nur
fiktiv sind, werden sie aufgrund Charakteristiken realer Benutzer entwickelt. Daher ist
es notwendig, Umfragen und andere Datenerhebungstechniken (vgl. [McKo08])
anzuwenden um herauszufinden, wer die wirklichen Benutzer sind und welche
Eigenschaften sie haben. Hat man einen Pool von Personas erstellt, kann man diese
zur Entscheidungsfindung heranziehen und sich in die Lage des Benutzers versetzen.

Card Sorting

Um zu verstehen wie Menschen bestimmte interaktive Elemente gruppieren und um
sicherzustellen dass für die Webseite oder ein Produkt wichtige Elemente schnell
gefunden werden, gibt es Card Sorting. Man versucht dadurch eine Struktur erkennen
zu können und eine bessere Anordnung von wichtigen Items auf einer Webseite zu
erreichen. Manche Items sind schwer zu kategorisieren oder werden unbewusst von
Menschen ignoriert oder nicht erkannt.

Dabei notiert man Bezeichnungen und Typ der Elemente einer Webseite auf
kleinen Notizzettel und legt sie auf einen Tisch. Nun sollen die testenden Benutzer die
Elemente so an-/umordnen, wie sie es für wichtig und richtig halten. Man kann auch
Varianten hinzufügen indem man den Benutzer notieren lässt ob er einzelne Teile
verstanden oder nicht verstanden hat. Diese Technik wird zur Erstellung einer
Struktur verwendet und ordnet sich im Ebenen-Modell von Garrett bei „Structure
Plane“ ein.

GOMS Analysis

Die Methode GOMS Analysis wurde anfangs der 80er entwickelt mit dem Ziel,
Voraussagen zu treffen, inwieweit ein Benutzer gewisse Vorkenntnisse besitzen muss,
um Aufgaben innerhalb eines Interfaces zu lösen. Somit lässt sich diese Methodik in
die Ebene „Skeleton Plane“ (siehe Abschnitt 3.5) eingeordnet werden. Dabei steht
GOMS für Goals, Operators, Methods und Selection Rules (vgl. [JoKi96]). Das
bedeutet, es werden in jedem System Methoden benötigt um Ziele zu erreichen. Diese
Methoden bestehen aus einzelnen Operationen die ein Benutzer ausführt. Die
Methoden haben eine hierarchische Anordnung, da es Methoden geben kann, die
vorher durchgeführt werden müssen um die übergeordnete Methode durchzuführen.
Beispielsweise muss bei einem Suchfeld zuerst ein Suchbegriff eingegeben werden
um die möglichen Suchergebnisse zu erhalten. Es liegt auf der Hand, dass es in der
Praxis mehrere Methoden existieren um eine Aufgabe zu bewältigen. Dabei kommen
die Selection Rules ins Spiel. Diese repräsentieren die Kunst eines guten Interfaces
um den Benutzer eine intuitive Auswahl der geeigneten Methode zu ermöglichen.
Dabei ist anzumerken, dass es nicht immer leicht ist, eindeutige Ziele eines
Benutzers zu identifizieren, da der jeweilige Nutzungsrahmen miteinbezogen werden
muss. Also in welchem Kontext wird ein System, an welchem Ort von welcher Person
verwendet. Hat man jedoch diese Aufgabe gemeistert, sind die weiteren Schritte
relativ einfach, indem man die Frage „Wie erreiche ich diese Ziele auf diesem
System?“ beantwortet. Daraus lassen sich dann die Methoden und die dazu benötigten
Operationen ableiten.

In der obigen Tabelle wird ein Beispiel für die Methode „Datei löschen“ angeführt. Dabei
werden die einzelnen Operationen in einer Liste angeführt. Bei diesem einfachen,
etwas älteren, Beispiel erkennt man sofort eine Möglichkeit die einem das GOMSModell
zur Verfügung stellt. Es wird möglich, verschiedenste Systeme aufgrund des
Aufwands für den Benutzer zu unterscheiden und zu bewerten. Des Weiteren wird es
dadurch auch möglich, Loops innerhalb von Operationen zu erkennen und
Operationsketten auf andere Methoden zu übertragen (reuse) um ein hohes Maß an
Konsistenz des User Interfaces (vgl. Elemente der UX – Nutzbarkeit) zu erreichen.

[Garr06] J. J. Garrett: The Elements of User Experience - User-centered design for the
web, New Riders 2006 

[HPB+00] M. Hassenzahl, A. Platz, M. Burmester, K. Lehner: Hedonic and Ergonomic
Quality Aspectes Determine a Software’s Appeal. In: Proceedings of the CHI 2000
Conference on Human Factors in Computing, 2000

[Jaza07] M. Jazayeri: Some Trends in Web Application Development, in: Future of
Software Engineering, IEEE Computer Society, May 2007

[JeGe06] H. C. Jetter, J. Gerken: A Simplified Model of User Experience for Practical
Application, in: The 2nd COST294-MAUSE International Open Workshop “User
eXperience – Towards a unified view”, Oslo, 2006

[JoKi96] B. E. John, D. E. Kieras: The GOMS Family of User Interface Analysis
Techniques: Comparison and Contrast, in: ACM Transactions on Computer-Human
Interaction, Vol 3 (4), pp. 320-351, December 2006

[Jord00] P. Jordan: Designing pleasurable products. An introduction to the new human
factors. Taylor & Francis, London, 2000

[Kalb07] J. Kalbach: Designing Web Navigation - Optimizing the User Experience,
O'Reilly, 2007

[Lewi06] D. Lewis: What is Web 2.0?, in: Crossroads, Vol. 13, September 2006

[LRV+08] E. Law, V. Roto, A. Vermeeren, J. Kort, M. Hassenzahl: Towards a Shared
Definition of User Experience, in: Proc. of the 26th SIGCHI conference on Human factors
in computing systems, Florence, Italy, July 2008

[Kier94] D. Kieras: A Guide to GOMS Task Analysis, University of Michigan Technical
Report, Spring, 1994

[KTNH 07] N. Khalayli, T. Terum, S. I. Nyhus, K. Hamnes: Persona Based Rapid Usability
Kick-Off, in: Proc. of the 25th SIGCHI conference on Human factors in computing systems,
California, USA, May 2007

[McKo08] J. McGinn, N. Kotamraju: Data-driven Persona development, in: Proc. of the
26th SIGCHI conference on Human factors in computing systems, Florence, Italy, July
2008

[Miln07] D. Milne: Exploiting Web 2.0 for Knowledge-Based Information
Retrieval, in: PIKM’07, November 9, Lisbon, Portugal, 2007

[MiRo06] D. E. Millard, M. Ross: Web 2.0: hypertext by any other name, in: Proc. Of the
17th conference on Hypertext and Hypermedia, August 2006

[MWBV08] P. Merholz, T. Wilkens, B. Schauer, D. Verba: Subject to change: Creating
Great Products & Services for an Uncertain World, O'Reilly, 2008

[Niel93] J. Nielsen: Usability Engineering, in: Academic Press, San Diego, 1993

[Norm04] D. A. Norman: Emotional Design: Why we love (or hate) everyday things.
Basic Books, New York, 2004

[Oreil05] T. O’Reilly: What Is Web 2.0, O'Reilly Network.
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html (13.
Nov 2008)

[Pilg08] C.J. Pilgrim: Improving the Usability of Web 2.0 Applications, in: HT’08, June
19–21, Pittsburgh, Pennsylvania, USA, 2008

[Rask00] J. Raskin: The Humane Interface, Addison-Wesley, 2000

[Ruth08] I. Ruthven: The context of the Interface, in: IIiX '08 Proc. of the 2nd international
symposium on Information interaction in context, London, October 2008

[Sinh03] R. Sinha: Persona Development for information-rich Domains, in: Proc. of CHI
'03 extended abstracts on Human factors in computing systems, Florida, USA, April 2003

[Stoj05] N. Stojanovic: On the Role of a User’s Knowledge Gap in an Information
Retrival Process, in: Proc. of the 3rd international conference on Knowledge capture,
Canada, October 2005

[Tree06] W. Treese: Web 2.0: is it really different?, in: Networker, Vol. 10 (2), June
2006

[Zaji07] M. Zajicek: Web 2.0: hype or happieness?, in: Proc. Of the 2007 international
cross-disciplinary conference on Web accessibility, Canada, 2007

leider sind die 5 Wochen zu schnell vergangen :-( und es ist wieder an der Zeit in die Heimat zurueckzukehren.

Wie bereits erwaehnt sind wir gestern wieder in Bangkok angekommen. Da wir uns in dieser Stadt so ziemlich alles gesehen haben (Sehenswuerdigkeiten) erkundeten wir heute die Shopping-Malls. Unglaublich, wir sind um 11:00 Uhr vormittags weggefahren und erst um 19:00 Uhr von unserem Shopping-Ausflug zurueckgekehrt. Dabei haben wir nur 2 Einkaufszentren und einen Markt besucht…

Da unser Flug uerbermorgen frueh (00:50 Uhr) startet werden wir den morgigen Tag ebenfalls mit Shopping verbringen

Mehr Geschichten, Fotos und Videos gibts dann in ein paar Tagen persoenlich.

Liebe Gruesse
Dave & Pez

diesmal nur ein kurzes Update:

Wir waren jetzt 2 Tage im Mekong Delta unterwegs und sind gerade zurueckgekommen. Morgen frueh startet unser Flieger nach Bangkok. Da werden wir dann mehr berichten…

Greetz
Dave & Pez

PS: Endlich haben wir auch schoene, unverblasste Postkarten

nach 4 Tagen ist es wieder mal Zeit fuer ein kurzes Update. Im Grunde gibt es nicht sehr viel zu berichten, da wir die letzte Zeit nur faul am Strand lagen und uns nur zum Abendessen von diesem entfernten.

Die Bungalowanlage ist sehr schön gestaltet und ruhig, und für 14$ ein wahrer Geheimtipp. Auch der Strand ist grundsätzlich in Ordnung, jedoch hat das gestrige Unwetter Unmengen an Plastikhuellen, Teile von Fischernetzen und ähnliches angespült, das sich bei Ebbe natürlich am Strand ansammelt und so das Baden ziemlich unangenehm wird.

Heute war der letzte Strandtag und wir brechen morgen mittag, also wann ihr gerade aus dem Bett steigt, im Bus nach Saigon (oder Ho Chi Minh City). Dort wollen wir 2 Tage die Stadt erkunden und eine 2-tägige Tour ins Mekong-Delta unternehmen. Danach gehts wieder zurück nach Bangkok wo wir den restlichen Platz in unseren Rucksäcken mit Gütern aller Art befüllen möchten. Natürlich sind auch noch ein oder mehrere Abstecher zum indischen Strassenstand unseres Vertrauens geplant (Curries – lecker)

Bei uns ist es jetzt gerade 19:00 Uhr und Zeit ein Restaurant aufzusuchen, denn ab 22:00 schläft hier fast alles.

Liebe Grüße aus Mui Ne
Dave & Pez

leider hat im vorigen Internet-Cafe das Veroeffentlichen der Fotos nicht funktioniert. Ab jetzt sind alle Fotos hier verfuegbar.

Morgen brechen wir nach Mui Ne auf. Haben uns dort einen Strandbungalow fuer 4 Tage gemietet und hoffen, dass das Wetter so schoen bleibt wie es derzeit ist.
Am 20. August fahren wir dann weiter nach Saigon…

Liebe Gruesse
Dave & Pez