User Interface Design Adaptation

User Interface Design Adaptation Max Geissler 15. Juni 2014 Zusammenfassung Viele Anwendungen leiden unter dem Problem, dass die Benutzeroberfläche auf zu kleinen oder zu großen Displays nicht oder nur schlecht bedienbar ist. Dieses Paper gibt einen Überblick über verschiedene Prinzipien und Techniken für das Erstellen von Anwendungen mit Benutzeroberflächen, die sich automatisch an unterschiedliche Geräte und Displays anpassen. Besonders wird dabei auf WebApplications eingegangen. Auf Codebeispiele wird verzichtet und stattdessen die Konzepte hinter den Techniken erläutert. 1 Einleitung Mark Weiser hatte bereits 1991 die Vorstellung, dass Personal Computer (PCs) an Bedeutung verlieren und durch viele kleine Computer ersetzt werden [1]. Heute verwenden viele Menschen neben dem PC Tablets, Smartphones oder Wearables, wie z.b. Computer in Armbanduhren. Diese Geräte haben jedoch verschiedene Erscheinungsformen: Es gibt unterschiedliche Arten von Eingabemöglichkeiten, wie z.b. Tastaturen für PCs oder Touch-Displays für mobile Geräte. Die Bildschirmgröße variiert von einigen Zentimetern auf mobilen Geräten bis hin zu Monitoren mit einer Diagonale von einigen Metern. Das stellt Entwickler vor die Herausforderung, eine Anwendung an die verschiedenen Geräte anzupassen, sodass auf allen Geräten eine optimale Benutzung möglich ist. Nach der Definition von User Interface Design Adaptation im nächsten Kapitel gibt dieses Paper in Kapitel 3 einen Überblick über die bisherigen Ansätze. Im darauf folgenden Kapitel 4 wird die Bedeutung von WebApplications zu diesem Thema erklärt und in Kapitel 5 werden aktuelle Techniken und Frameworks für User Interface Design Adaptation auf Basis von WebApplications vorgestellt. 2 Definition User Interface Design Adaptation bezeichnet die Anpassung, also die Veränderung, einer Benutzerschnittstelle an den Benutzer bzw. das Gerät des Benutzers [2, 3]. User Interface Design Adaptation ist grundsätzlich nicht auf visuelle Schnittstellen beschränkt sondern kann bei jeder Art von Benutzerschnittstelle angewendet werden, zum Beispiel auch bei Sprachschnittstellen. Dieses Paper behandelt die Anpassung visueller Schnittstellen. 1

3 Bisherige Ansätze Bereits 2002 wurden Entwicklungsumgebungen wie Damask [4, 5] oder DENIM [6] entwickelt, mit deren Hilfe für unterschiedliche Geräte und Bildschirmgrößen Anwendungsskizzen erstellt werden können. Dabei können verschiedene Detailstufen der Anwendung dargestellt werden, wie in Abbildung 1 zu sehen. Abbildung 1: Entwicklungsumgebung Damask Diese Entwicklungsumgebungen erlauben jedoch keine automatische Erzeugung von Benutzeroberflächen. Außerdem muss jede Benutzeroberfläche einzeln implementiert werden. Abhilfe scha en Werkzeuge wie SUPPLE [7, 8], die aus einem einzigen abstrakten Modell (Abbildung 2) automatisch Benutzeroberflächen generieren. Die von SUPPLE erstellten Anwendungen basieren auf Java und sind somit auf sehr vielen Geräten mit unterschiedlichen Bildschirmgrößen lau ähig, wie in Abbildung 3 zu sehen. Abbildung 2: Eingabe für SUPPLE [7] SUPPLE bietet auch eine Generierung von Webseiten aus dem abstrakten Modell an. Dabei werden statische Webseiten für eine bestimmte Auflösung (z.b. 1024x768) generiert. SUPPLE nutzt dabei nicht die Möglichkeit, die Webseiten automatisch an den Browser anzupassen. Wenn der Benutzer das Browserfens- 2

Abbildung 3: Von SUPPLE generierte Benutzeroberflächen [8] ter vergrößert oder verkleinert, verändert sich die Webseite nicht, sondern der Benutzer muss nach einer Größenänderung des Browsers die Webseite erneut anfordern. Mit modernen Techniken wie HTML5 und CSS3 ist es möglich, eine automatische Anpassung des Inhalts einer Webseite bei einer Größenänderung des Browserfensters durchzuführen. Das hat auch den Vorteil, dass eine solche Webseite automatisch für verschiedene Bildschirmgrößen optimiert ist, da die Größe des Browserfensters von der Bildschirmgröße abhängt. 4 WebApplications WebApplications sind Anwendungen, die in einem Browser ausgeführt werden. Sie basieren meist auf HTML, CSS und Scriptsprachen wie Javascript. Diese Anwendungen laufen nicht nativ, sondern werden von einem Webbrowser interpretiert. Da nahezu alle Plattformen einen Webbrowser bieten, sind WebApplications automatisch plattformübergreifend. Es besteht jedoch weiterhin das Problem, dass die Displays der verschiedenen Geräte unterschiedlich groß sind. Die Benutzeroberfläche der WebApplication muss also an die Displaygröße angepasst werden. Es stellt sich die Frage, ob eine WebApplication besser als eine native Anwendung ist. Dazu werden im Folgenden WebApplications mit nativen Anwendungen verglichen. Native Anwendungen profitieren davon, dass sie kompiliert sind. Dadurch ergibt sich ein immenser Geschwindigkeitsvorteil. Für rechenintensive Anwendungen ist also eine native Anwendung immer zu bevorzugen. Bei mobilen Geräten fällt das besonders stark ins Gewicht, da bei intensiven Rechnungen viel Energie verbraucht wird. Das schränkt die Mobilität der Benutzer ein, weil der Akku des mobilen Gerätes weniger lang hält. Außerdem bietet eine native Anwendung direkten Hardwarezugri auf eingebaute Sensoren, Kamera, Audio Einund Ausgabe, Adressbuch und Datenbanken wie SMS [9]. Ein weiterer Pluspunkt für native Anwendungen ist die nahtlose Integration in die bestehende GUI des Betriebssystems. Der Benutzer ist bereits mit dem typischen Layout 3

einer nativen Anwendung vertraut. Er weiß, wie er Standardelemente wie Buttons, Checkboxen oder Auswahllisten benutzen kann. Abbildung 4: Vergleich der Browser von ios und Android Bei WebApplications ist diese Vertrautheit nicht gegeben, weil verschiedene mobile Geräte auch unterschiedliche GUIs haben. Außerdem können GUI- Elemente auf eine andere Art und Weise angeordnet sein. Abbildung 4 zeigt, dass im Browser von ios und Android die Buttons für Zurück und Vorwärts genau auf der anderen Seite gelegen sind. Im Gesamten betrachtet können native Anwendungen also intuitiver bedient werden als WebApplications. Laut Grigsby [10] reicht aber eine native Anwendung nicht aus, sondern es muss unbedingt auch eine WebApplication zusätzlich zur nativen Anwendung oder statt dieser vorhanden sein. Er begründet diese Aussage mit folgendem Ausspruch: Links Don t Open Apps Dieser Ausspruch fasst zusammen, dass auf Internetseiten, Social Media Netzwerken, Emails oder gedruckten Plakaten Links zu Webseiten angegeben werden. Wenn der Benutzer dem Link folgt, möchte er die funktionierende Anwendung sehen. Das ist nur bei WebApplications möglich, denn native Anwendungen müssen vor dem ersten Aufrufen erst heruntergeladen und möglicherweise auch noch installiert werden. Trotz aller Vorteile von nativen Anwendungen sollte daher, falls technisch möglich, zunächst eine WebApplication entwickelt werden. Wenn nach dieser Entwicklung noch Zeit und Budget für eine native Anwendung vorhanden ist, sollte diese zusätzlich entwickelt werden. 4

5 Responsive web design Ethan Marcotte benutzte den Begri Responsive web design erstmals 2010 in einem Aufsatz, der diesen Begri auch als Titel tra gt [11]. 2011 ruft Marcotte in einem Buch zu diesem Thema [12] dazu auf, die Vorteile einer Webseite gegenu ber einem gedruckten Medium zu nutzen; insbesondere den Vorteil, dass das Medium nicht mehr eine fixe Gro ße hat, sondern flexibel geworden ist. Responsive web design leitet er aus Responsive architecture ab. Das ist eine Art der Architektur, in der sich die Umgebung, wie Wa nde oder Glasscheiben, an die Menschen darin anpasst. Beispielsweise kann eine Glasscheibe automatisch undurchsichtig werden. Eine solche Glasscheibe, auch Smart Glass genannt, ist in Abbildung 5 zu sehen. Abbildung 5: Smart Glass kann undurchsichtig werden [12] Marcottes Ideen haben große Verbreitung und Zuspruch gefunden. Laut dem Magazin Mashable war 2013 das Jahr des Responsive web designs [13]. Auch in der Zukunft wird dieses Konzept wegweisend sein. 5.1 Adaptive web design Adaptive web design wird oft als Synonym fu r Responsive web design verwendet. Aaron Gustafson beschreibt in seinem Buch mit ebendiesem Titel Techniken des Responsive web designs [14]. Jedoch gibt es auch eine andere Interpretation, auch Adaptive delivery genannt [15], die in diesem Kapitel kurz vorgestellt wird. Bei dem Ansatz des Adaptive web designs wird die Version der Webseite als Hauptseite angesehen, die auf einem Desktop Computer oder einem Notebook dargestellt wird. Klassischerweise bieten die Displays von solchen Gera ten viel Platz und somit la sst sich sehr viel Inhalt auf einmal darstellen. Zusa tzlich zum CSS Stylesheet der Hauptseite existiert ein weiteres CSS Stylesheet fu r eine mobile Version der Webseite. Die CSS Stylesheets der Hauptseite und der mobilen 5

Seite sind getrennt voneinander gespeichert, zum Beispiel in getrennten.css Dateien. Durch den User-Agent-String, der den Browser und das Betriebssystem identifiziert, kann der Server entscheiden, ob ein mobiles Gera t oder ein Desktop System bedient werden soll. Abbildung 6: Von SUPPLE fu r 640x480 und 800x600 generierte WebApplication Abbildung 6 zeigt die Web-Version von SUPPLE. Bei SUPPLE kann die Auflo sung, fu r die die Webseite generiert werden soll, ausgewa hlt werden und der Server u bertra gt anschließend die angepasste Webseite. Diese Art der Anpassung ist aber nicht dynamisch. Es treten zum Beispiel Probleme auf, wenn der Benutzer im Nachhinein die Fenstergro ße des Browsers a ndert. Die Seite wird bei einer Gro ßena nderung nicht neu geladen und somit ist das Design fu r die vorherige Fenstergro ße weiterhin aktiv. Diese Probleme ko nnen mit Hilfe von Scripts, die die Seite neu laden oder anpassen, umgangen werden. Jedoch bieten moderne Browser schnellere und zuverla ssigere Techniken. Diese Techniken werden im Responsive web design angewendet. Somit stellt Responsive web design eine Verbesserung der Techniken des Adaptive web designs dar. 5.2 Techniken des Responsive web designs Marcotte stellt fest, dass es fu r eine responsive Webseite drei wichtige Techniken gibt [12]: Ein flexibles, auf Gittern basierendes Layout (Flexible Grid Layout) Flexible Bilder und Medien (Flexible Media) Media Queries Diese Techniken werden in den folgenden Kapiteln vorgestellt. 6

5.2.1 Flexible Grid Layouts Die Grundlage für ein Flexible Grid Layout ist Flexible Typesetting [12], auch Responsive Typography genannt [9, 16]. Flexible Typesetting ist die dynamische Anpassung der Schriftgröße an die Umgebung, in der sich der Benutzer befindet. Ausgangspunkt ist dabei die im Browser festgelegte Standardschriftgröße. In Desktop Browsern ist die Standardschriftgröße meistens 16 Pixel. Von dieser Standardschriftgröße ausgehend werden nun alle Schriftgrößen auf der Webseite nicht in absoluten Pixelwerten angegeben, sondern in relativen Werten. Die relativen Werte werden gekennzeichnet mit der Einheit em. Die Schriftgröße in Pixeln wird vom Browser berechnet, indem der em-wert mit der Schriftgröße des übergeordneten Elements, auch Container-Element genannt, multipliziert wird: Schriftgröße in Pixel = Schriftgröße des Container-Elements em-wert Wenn die Schriftgröße des Container-Elements ebenfalls als em-wert gegeben ist wird die obige Formel solange angewendet, bis ein Container-Element erreicht wird, für das die Schriftgröße als absoluter Wert gegeben ist. Das ist spätestens beim obersten Container-Element der Fall, für das die Standardschriftgröße des Browsers gilt. Abbildung 7: Beispiel für Flexible Typesetting In Abbildung 7 ist für das Element von Text A die Schriftgröße 2em vergeben. Da bis zum obersten Element der Webseite keine Schriftgrößenangaben mehr gegeben sind, gilt für das Container-Element die Standardschriftgröße des Browsers, in diesem Fall 16 Pixel. Nach der Formel ist die Schriftgröße von Text A also 16 Pixel 2 = 32 Pixel. Text B hat eine Schriftgröße von 0.5em. 7

Das Container-Element von Text B ist das Element von Text A. Die Schriftgröße von Text A wird wie vorhin berechnet. Anschließend kann die Schriftgröße von Text B ausgerechnet werden: 32 Pixel 0.5 = 16 Pixel. Wenn die Seite in einem Browser mit einer anderen Standardschriftgröße angesehen wird, werden Text A und Text B automatisch skaliert aber die Verhältnisse der Schriftgrößen bleiben immer gleich. Abbildung 8: Struktur eines Webseitendesigns [12] Dasselbe Prinzip kann auch auf die ganze Webseite statt nur auf Schriftgrößen angewendet werden. Dafür wird zunächst die Struktur des Webseitendesigns, in Abbildung 8 zu sehen, betrachtet. Um die Struktur dieses Designs mit einem Gitter (Grid) zu beschreiben, braucht das Grid 12 Spalten. Die Spaltenbreiten werden mit Prozentwerten angegeben. Die Prozentwerte beziehen sich dabei auf die Breite des Container-Elements. Auch die Abstände zwischen zwei Elementen (margin und padding in CSS) können als Prozentangaben gegeben werden. 5.2.2 Flexible Media Medien wie Bilder, Videos oder Adobe Flash Objekte können flexibel in das Design eingebunden werden. Moderne Browser können beim Skalieren von Medien das Seitenverhältnis beibehalten [12]. Somit reicht eine relative Breitenangabe wie beim Flexible Grid aus, um die Mediengröße dem restlichen Inhalt anzupassen. Diese Technik wird auch Fluid images genannt. Besonders wichtig ist bei dieser Vorgehensweise, dass die Medien in hoher Auflösung vorliegen. Moderne Browser können nahezu ohne Qualitätsverluste eine Verkleinerung der Medien vornehmen und durch die hohe Auflösung der Medien ist eine scharfe Darstellung auch auf sehr großen Displays möglich. Noch besser ist es, statt Rastergrafiken Vektorgrafiken zu verwenden, die bei jeder Auflösung scharf dargestellt werden können. 8

Es empfiehlt sich zusätzlich zur relativen Breitenangabe auch eine minimale Breite zu definieren. Das verhindert, dass die Darstellung auf kleinen Displays zu klein und damit unlesbar wird. Analog dazu sollte auch eine maximale Breite definiert werden, sodass auf großen Displays das Medium nicht zu viel Platz einnimmt und den Text erschlägt. Außerdem wird mit einer maximalen Breite der Unschärfee ekt durch eine Vergrößerung von Rastergrafiken verhindert. 5.2.3 Media Queries Mit Hilfe von Flexible Grids und Flexible Media können bereits Designs erstellt werden, die nicht mehr von einer bestimmten Auflösung abhängen, sondern sich anpassen. Bei sehr kleinen oder großen Displays tritt jedoch das Problem auf, dass die Struktur des Designs stark gestaucht oder auseinandergezogen wird. Bei großen Displays werden die Textzeilen so breit, dass das Lesen erschwert wird, weil man in der Zeile verrutscht. Auf kleinen Displays werden Elemente, die nebeneinander positioniert sind, teilweise untereinander positioniert. Abbildung 9: Bei zu kleinen Displays geht die Menüstruktur verloren [12]. In Abbildung 9 ist zu sehen, wie auf zu kleinen Displays die Menüstruktur des Designs verloren geht. Der Contact us Link sollte eigentlich auf der Höhe der anderen Links stehen, wurde aber aufgrund von Platzmangel unter den anderen Links angeordnet. Eine Lösung für dieses Problem ist die Verwendung von Media Queries. Media Queries sind Teil der CSS3 Spezifikation und erlauben, bestimmte CSS Styles nur dann zu aktivieren, wenn bestimmte Voraussetzungen erfüllt sind [12]. Media Queries bestehen aus zwei Komponenten: 1. Medientyp 2. Query Als Medientyp können in der Media Query beispielsweise screen, print oder handheld angegeben werden. Der Browser legt fest, welcher Medientyp vorliegt. Wenn eine Webseite auf einem Desktop Computer aufgerufen wird, legt der Browser den Medientyp screen fest. Wird die Webseite ausgedruckt, ist der Medientyp print. Auf mobilen Geräten wie Handys sollte der Medientyp handheld sein, allerdings setzen viele Browser für mobile Geräte den Medientyp trotzdem 9

Tabelle 1: Auswahl von möglichen Queries Query aspect-ratio color height orientation resolution width Bedeutung Beschreibt das Seitenverhältnis des Displays und damit das Verhältnis von width und height. Diese Eigenschaft beschreibt die Anzahl der Bits, die ein Gerät pro Farbkanal verwendet. Wenn das Display keine Farben anzeigen kann, ist der Wert 0. Höhe des Displays. Als Einheit kann px (Pixel), cm (Zentimeter), in (Inch), oder em verwendet werden. Kann die Werte portrait (Hochformat) oder landscape (Querformat) annehmen. Diese Merkmal gibt die Auflösung, also die Bildpunktdichte, des Displays an. Als Einheit kann dpi (dots per inch) oder dpcm (dots per cm) verwendet werden. Breite des Displays. Als Einheit kann px (Pixel), cm (Zentimeter), in (Inch), oder em verwendet werden. auf screen. Der Grund dafür ist, dass nicht die Webseite für veraltete mobile Geräte, wie z.b. PDAs, dargestellt werden soll, sondern die moderne Version der Webseite. Die mit dem Medientyp angegebene Query gilt nur dann, wenn der Medientyp der Query mit dem Medientyp des Browsers übereinstimmt. In der Query können Details über das Display des Gerätes abgefragt werden. Tabelle 1 zeigt eine Auswahl von möglichen Queries, die in Media Queries verwendet werden können. Mit Hilfe dieser Queries kann auf bestimmte Werte getestet werden. Queries wie width oder height erlauben es auch, auf Oberbzw. Untergrenzen der Eigenschaft zu testen. Beispielsweise kann mit min-width getestet werden, ob das Display eine bestimmte Mindestbreite hat. Außerdem kann in einer Media Query auf mehrere Eigenschaften gleichzeitig geprüft werden, indem mehrere Queries hintereinander gehängt werden. Wenn die von der Media Query getesteten Anforderungen erfüllt sind, werden die mit der Media Query verbundenen CSS Styles aktiviert. Auf diese Art und Weise können eigene CSS Styles für bestimmte Medientypen und Displayeigenschaften erstellt werden. Erst durch Media Queries wird eine Webseite wirklich responsiv, da sie für den Benutzer auch auf unterschiedlichen Geräten und Displays optimal angezeigt werden kann, wie in Abbildung 10 gezeigt ist. Mit Hilfe von Flexible Grids, Flexible Media und Media Queries ist es also möglich, wirklich responsive Benutzeroberflächen zu erstellen, die sich an den Benutzer und die Umgebung des Benutzers anpassen. Die Anpassung erfolgt zudem automatisch. Der Benutzer muss nicht mehr, wie beim Adaptive web design, auswählen, welche Version der Seite dargestellt werden soll. Das steigert die Benutzerfreundlichkeit der Benutzeroberfläche. 10

Abbildung 10: Automatische Anpassung der Benutzeroberfläche an verschiedene Geräte und Displays [12]. 5.3 Responsive web frameworks Es existieren Frameworks um Webseiten zu erstellen. Einige davon bauen auf dem Prinzip des Responsive web design auf. Im Folgenden werden zwei populäre Responsive web frameworks verglichen: Bootstrap in Version 3 und Foundation in Version 5. Beide Frameworks werden aktiv weiterentwickelt. Das rege Interesse an diesen beiden Frameworks ist unter anderem an der Anzahl der Sterne auf dem Softwareentwicklungs-Dienst github.com zu sehen: Bootstrap hat über 68000 Sterne und Foundation über 17000 Sterne von github Benutzern bekommen. 5.3.1 Einheiten Bootstrap benutzt Pixel als Einheit. Wie im Kapitel 5.2.1 besprochen, ist es besser, relative Einheiten wie em zu verwenden. Foundation verwendet relative Einheiten, jedoch rem statt em. Die Einheit rem (root em) ist eine erst seit Kurzem 11

von Browsern unterstu tzte Einheit, bei der sich die relative Angabe nicht auf das Container-Element bezieht, sondern auf die Schriftgro ße des obersten Elementes, also des html Elementes der Webseite. Durch rem wird der sogenannte EM cascade e ect [17] umgangen. Dieser E ekt bewirkt, dass em Werte unerwu nschterweise mehrmals hintereinander angewendet werden. Wenn beispielsweise eine Liste als Schriftgro ße 1.5em hat, und als Listenpunkt wiederum eine Liste angegeben wird, ist die Schriftgro ße der inneren Liste 1.5em 1.5em = 2.25em und somit viel gro ßer als eigentlich erwu nscht. 5.3.2 Layout Abbildung 11: Flexible Grid Layout in Bootstrap. Sowohl Bootstrap als auch Foundation basieren auf einem Flexible Grid Layout. Es existiert jeweils ein Standard-Grid-System, das aber auch angepasst werden kann. In Abbildung 11 ist das Grid-System von Bootstrap gezeigt. Es ist zu erkennen, dass die Spalten bei viel Platz nebeneinander angeordnet sind und bei wenig untereinander. Das Grid System von Foundation verha lt sich genauso. 5.3.3 Mobile First Beide Frameworks verfolgen die Strategie Mobile First [18]. Beim Gebrauch von Foundation wird der Entwickler sogar dazu gezwungen, da CSS Code, der nicht in einer Media Query eingeschlossen ist, als CSS fu r die mobile Version der Webseite interpretiert wird. Durch die Strategie Mobile First wird also die mobile Version der Webseite zuerst entwickelt und im Nachhinein wird durch zusa tzliche CSS Styles die Desktop Version erstellt. Das hat den Vorteil, dass sich Designs fu r kleine Displays einfacher fu r große Displays umbauen lassen, als umgekehrt. 5.3.4 Standardelemente Beide Frameworks bieten CSS Styles fu r Standardelemente wie Buttons, Checkboxen oder Auswahllisten. Die CSS Styles in Foundation sind auf das No tigs12

te beschränkt, während Bootstrap für alle Standardelemente ein konsistentes Design bietet. Der Vorteil von Bootstrap ist, dass die Standardelemente ohne Anpassung sofort in einem Projekt verwendet werden können. Der Nachteil ist jedoch, dass Projekte auf Basis von Bootstrap in Gefahr laufen, einheitlich auszusehen. Bei der Verwendung von Foundation ist zwar das Stylen der Standardelemente mit mehr Aufwand verbunden, das Ergebnis ist dafür meist einzigartig. Es gibt aber sowohl für Bootstrap als auch für Foundation Themes, die die Standardelemente neu stylen. Wenn Themes verwendet werden, sind beide Frameworks gleichauf. 5.3.5 Verbreitung Bootstrap ist momentan weiter verbreitet, was sich unter anderem an der Community auf github zeigt. Es gibt viele Plugins für Bootstrap. Die Seite bootsnipp.com listet über 380 Ressourcen und mehr als 350 Snippets für Bootstrap. Das Projekt ZURB Foundation Sublime Text Snippets [19] enthält nur 20 Snippets. Durch die große Verbreitung von Bootstrap existieren für viele Komponenten, wie Kontaktlisten, Benutzerprofile oder Menüstrukturen, bereits fertige Lösungen von der Community. Dadurch sinkt der Entwicklungsaufwand. 5.3.6 Fazit Foundation ist interessant für Webseiten, die viele Standardstyles des Frameworks ändern, denn Foundation ist mit 58 KB (Version 5.2.3, minified) sehr viel kleiner als Bootstrap mit 142 KB (Version 3.1.1, minified). Allgemein ist aber Bootstrap die bessere Alternative, insbesondere wenn der Entwicklungsaufwand gering gehalten werden soll. Der Grund dafür ist neben der großen Verbreitung die Menge an Komponenten, die bereit gestellt werden. 6 Ausblick Die ersten Ansätze für adaptive Benutzerschnittstellen waren noch nicht ausgereift. Aber heute ist es durch die vorgestellten Techniken für WebApplications möglich, Benutzeroberflächen zu entwickeln, die sich automatisch an den Benutzer bzw. an das Gerät des Benutzers anpassen. Durch die Verwendung von Responsive web frameworks ist die Entwicklung solcher Oberflächen zeite zient und damit kostensparend möglich. Zusätzlich zu WebApplications können native Anwendungen entwickelt werden. Allerdings muss für jede Plattform eine eigene Anwendung erstellt werden, was wiederum sehr kostenintensiv ist. In Zukunft könnten WebApplications und native Anwendungen näher zusammen wachsen, indem native Anwendungen die Prinzipien von responsiven WebApplications verwenden. Damit würden plattformunabhängige native Anwendungen möglich werden, die ihre Benutzeroberfläche automatisch anpassen. 13

Literatur [1] M. Weiser, The computer for the 21st century, Scientific american, vol. 265, no. 3, pp. 94 104, 1991. [2] F. Paterno, User Interface Design Adaptation. Aarhus, Denmark: The Interaction Design Foundation, 2013. [3] M. Schneider-Hufschmidt, U. Malinowski, and T. Kuhme, Adaptive user interfaces: Principles and practice. Elsevier Science Inc., 1993. [4] J. Lin and J. A. Landay, Damask: A tool for early-stage design and prototyping of multi-device user interfaces, in In Proceedings of The 8th International Conference on Distributed Multimedia Systems (2002 International Workshop on Visual Computing), pp. 573 580, 2002. [5] J. Lin and J. A. Landay, Employing patterns and layers for early-stage design and prototyping of cross-device user interfaces, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 1313 1322, ACM, 2008. [6] M. W. Newman, J. Lin, J. I. Hong, and J. A. Landay, Denim: An informal web site design tool inspired by observations of practice, Human-Computer Interaction, vol. 18, no. 3, pp. 259 324, 2003. [7] K. Gajos and D. S. Weld, Supple: automatically generating user interfaces, in Proceedings of the 9th international conference on Intelligent user interfaces, pp. 93 100, ACM, 2004. [8] K. Z. Gajos, D. S. Weld, and J. O. Wobbrock, Decision-theoretic user interface generation., in AAAI, vol. 8, pp. 1532 1536, 2008. [9] E. Harb, P. Kapellari, S. Luong, and N. Spot, Responsive web design, 2011. [10] J. Grigsby, Links don t open apps. http://blog.cloudfour.com/ links-do-not-open-apps/, 2011. Zugri sdatum: 30.05.2014. [11] E. Marcotte, Responsive web design, Alistapart, vol. 306, 2010. [12] E. Marcotte, Responsive web design. A Book Apart, 2011. [13] P. Cashmore, Why 2013 is the year of responsive web design. http://mashable.com/2012/12/11/responsive-web-design/. Zugri sdatum: 12.05.2014. [14] A. Gustafson, Adaptive web design. Pearson, 2013. [15] R. Pratap, Responsive design vs. adaptive delivery: Which one s right for you?. http://venturebeat.com/2013/11/19/ responsive-design-adaptive/. Zugri sdatum: 12.05.2014. [16] C. Coyier, Why ems?. http://css-tricks.com/why-ems/. Zugri sdatum: 18.05.2014. 14

[17] J. Snook, Font sizing with rem. http://snook.ca/archives/html_and_ css/font-size-with-rem. Zugri sdatum: 14.06.2014. [18] L. Wroblewski, Mobile first. Editions Eyrolles, 2012. [19] Zurb foundation sublime text snippets. https://github.com/zurb/ Foundation-5-sublime-snippets. Zugri sdatum: 14.06.2014. [20] J. Lowgren, Interaction Design - brief intro. Aarhus, Denmark: The Interaction Design Foundation, 2013. [21] J. M. Carroll, Human Computer Interaction - brief intro. Aarhus, Denmark: The Interaction Design Foundation, 2013. 15