Geräteunabhängige Dienste Projektgruppe Location-based Services for Wireless Devices WS 2004/05 Christine Haertl AG Kao Betriebssysteme und Verteilte Systeme Institut für Informatik Universität Paderborn Vorstellen: Name, Tätigkeit, Veranstaltung - Mein Name ist Christine Haertl und meine Aufgabe fuer die Projektgruppe war, Ansaetze fuer eine geraeteunabhaengige Darstellung von Diensten zu finden, zu vergleichen und einen Vorschlag zu machen, wie wir in unserer PG Dienste geraeteunabhaengig darstellen.

Inhalt Motivation Lösungsansätze Vergleich der Ansätze UIML IML ISL DDL Vergleich der Ansätze Ausgewählter Ansatz für die Projektgruppe Ich werde mit einer kurzen Motivation beginnen, in der ich das Problem darstelle, warum eine geraeteunabhaengige Darstellung notwendig ist. Dann werde ich 4 Loesungsansaetze vorstellen. Das sind User Interface Markup Language, Interaction Markup Language, Interaction Specification Language und Dialog Description Language. Nach einem anschliessenden Vergleich, werde ich vorstellen, welchen Ansatz ich fuer die Projektgruppe vorschlagen wuerde. Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Motivation PC PDA Handy Haus Kuh Auto Haus Kuh Auto Unser Ziel ist ja Dienste auf verschiedenen Geraeten verfuegbar zu machen. Die Geräte unterscheiden sich in ihrer Speichergröße, ihrer Rechenleistung und ihrer Leistungsfähigkeit von Benutzerinteraktion und Präsentation. Auf dieser Folie sehen wir jetzt das Beispiel, dass sich die Displaygroessen unterscheiden und dass die Darstellung daher an die einzelnen Geraetetypen angepasst werden muss. Auf einem normalen PC ist genug Platz, um Text und Bilder nebeneinander anzuordnen, wodurch der ganze gewuenschte Inhalt auf einmal dargestellt werden kann. Auf kleineren Displays, wie zum Beispiel bei PDAs, koennen Text dann beispielsweise untereinander angeordnet werden. Bei Geraeten mit winzigen Displays und wenig Speicher muessen die Bilder dann evtl. ganz wegfallen. Auto Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

? Motivation Dienste WML E-mail E-mail E-mail WML E-mail HTML tinyHTML E-mail tinyHTML E-mail WML E-mail HTML Kartendienst Browser HTML Benutzer wollen mit vielen Diensten von vielen verschiedenartigen Geräten kommunizieren (konkretes Beispiel nennen: Dienst - PC, Handy) (verschiedene Dienste mit unterschiedlichen Geräten ansprechen) Geräte haben unterschiedliche Leistungsfähigkeit (Speichergröße, Rechenleistung, ….) Und unterschiedliche Eingabe- / Ausgabearten (Bildschirm – Lautsprecher. Tastatur, Maus, Mikrofon) Einen Dienst für jedes Gerät einzeln zu Entwickeln -> teuer Manuelle Anpassung -> teuer Möglichkeiten: Gleiche Oberfläche auf allen Geräten Gerät mit geringster Leistung begrenzt die Funktionalität Vorteile von gerätespezifischen Eigenschaften werden nicht genutzt (Mikrofon, Scrollrad) Oberflächendesign nicht steuerbar (für wirtschaftliche Aspekte wichtig) Neue Version auf jedem Gerät Hohe Kosten für Implementierung Hohe Kosten für Wartung Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Motivation WML HTML tinyHTML Inhalt E-mail Struktur Struktur Struktur HTML Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

XML-XSL XML HTML Dienst HTML HTML XMLXSL XSL XMLXSL XMLXSL-Dienst verbindet geräteunabhängige XML-Datei mit geräteabhängiger XSL-Datei XSL-Datei spezifiziert welche Teile aus XML benutzt werden Aufgabe des Erzeugers der XSL-Datei: gültige Typen (Button, Textfeld) auf graphische Komponenten der Geräte abbilden Aus einer Architektur rausgegriffen – allgemeines Konzept Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Ansätze UIML ISL XMLXSL IML DDL Extensible Markup Language User Interface Markup Language Interaction Specification Language IML DDL Interaction Markup Language Dialog Description Language Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Anforderungen Trennung von Inhalt, Struktur und Logik Vorteile von gerätespezifischen Fähigkeiten nutzen Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

UIML UIML <peers> <presentation name="VoiceXML"> head interface peers template <peers> <presentation name="WML"> <component name="Container" maps-to="wml:card"> <attribute name="content" maps-to="wml:card.title"/> </component> <component name="String" maps-to="wml:p"> <attribute name="content" maps-to="PCDATA"/> </presentation> </peers> <interface> <structure> <part name="TopHello" class="Container"> <part name="HelloStr" class="String"/> </part> </structure> <style> <property part-name="TopHello“ name="content">Hello</property> <property part-name="HelloStr" name="content">Hello World!</property> </style> </interface> <peers> <presentation name="VoiceXML"> <component name="Container" maps-to="vxml:form"/> <component name="String" maps-to="vxml:block"> <attribute name="content" maps-to="PCDATA"/> </component> </presentation> </peers> <uiml xmlns='http://uiml.org/dtds/UIML2_0e.dtd'> <head> ... </head> <interface> ... </interface> <peers> ... </peers> <template> ... </template> </uiml> <vxml> <form> <block>Hello World!</block> </form> </vxml> <wml> <card title="Hello"> <p>Hello World!</p> </card> </wml> Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Einschränkung durch UIML WML tinyHTML E-mail HTML UIML: direkte Abbildung von abstrakten Dialogelemente anstatt von abstrakten Interaktionen -> Dialogelemente stellen die Schnittmenge der Sprachen dar -> Einschränkung von Darstellung -> Fähigkeiten der Geräte werden nicht ausgenutzt Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

UIML - IML IML UIML Semantics Implementation UIML rendered to WML DOC Interface User Interface Semantics Implementation UIML rendered to WML UIML rendered to HTML Render Engine WML IML UIML: Ähnliche Dialogelementen werden zu einem abstrakten Dialogelement zusammengefasst IML: Ähnliche Interaktionen werden zu abstrakten Interaktionen zusammengefasst Auswahl von einem aus 5 Elementen – Radiobuttons, Auswahl aus einer Liste,…. Gelb: Zwei Pfeile geben an, welche Schritte gemacht werden muessen Blau: UIML Dokument enthält beide Schritte in einem Dokument (es beschreibt Semantik und Implementation) Rot: IML Dokument enthält nur die Semantik, die Renderengine generiert die Implementation Vorteil: IML reduziert nicht auf gemeinsame Schnittmenge von Möglichkeiten aller Technologien und kann leicht erweitert werden Nachteil: komplexer Lösungsidee: semantische Informationen von Bedienelementen trennen und unabhängige Regeln benutzen um Semantik zu beschreiben Render Engine HTML Render Engine Java Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Gibt es nicht! IML Sprachdefinition von IML: IML Sprachdefinition gibt es nicht Aufgabe der Renderengine extrem komplex Keinerlei Anpassung von Layout und Ähnlichem (das Konzept einer Überschrift oder einer Hervorhebung existiert an der Stelle nicht, da nur Interaktionen beschrieben werden) Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

UML – IML Erfüllung von Anforderungen UIML IML UIML IML Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen  Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

ISL - Interaction Specification Language Geräte - unabhängig Geräte - abhängig Dienst - unabhängig Geräte - abhängig Dienst - abhängig Interaction Acts User Interface Dienst Interaction Engine Customization Form Interpretiert ISL Generiert UI Codierung in ISL Interpretiert Benutzeraktion Benutzer- Schnittstelle ISL UI Spez. (HTML) Benutzer-aktion Dienst Interaction Engine Customization form input output selection modification create destroy start stop Interaction acts Customization Form beinhaltet geräte- und dienstspezifische Informationen Dienstanbieter können Präsentation ihres Dienstes kontollieren kein Customization Form vorhanden  Standardeinstellungen Interaction act abstraktes Element für Interaktion zwischen Benutzer und Dienst beinhaltet keine Informationen über die Art und Weise der Präsentation Annahme: Die meisten Interaktionen können durch begrenzte Menge von interaction acts ausgedrückt werden Für jedes Gerät eine interaction engine Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

ISL - Interaction Specification Language <out> <name>select_dest_O</name> <string>Please specify destination!</string> <meta>null</meta> </out> <select> <name>select_dest_S</name> <alt> <string>Stockholm</string> <retval>ARN</retval> </alt> <string>London</string> <retval>LHR</retval> <string>New York</string> <retval>JFK</retval> </select> </isl> <isl> <data> <name>select_dest_S</name> <value>LHR</value> </data> </isl> Abbildung von abstakt dargestelltem Interaction act auf gerätespezifische Bedienelemente anhand des Typs (out / select) oder aus Kombination Von Typ und Name Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

ISL – Resultat eines Customization Forms Beispiel-Implementierung: Kalender Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

ISL - Erfüllung von Anforderungen Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben  Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität () Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

DDL – Dialog Description Language include head DataType Def Data- instance dialog class content part property constant Automatische Inhaltsanpassung benötigt Abbildung der Elemente einer geräteunabh. Inhaltsrepräsentation auf eine gerätespezifische Inhaltssprache Semantik der Eigenschaften nicht in DDL, nur DDL-renderers für Anpassung an gerätespez. Sprache muss erweitert werden können oder angepasst, um neue Eigenschaften zu interpretieren -> Syntax muss nicht verändert werden reference #PCDATA Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

DDL – Dialog Description Language frameset container label image source form <part> <property name=“type“>label</property> <property name=“content“> TU-Dresden </property> <property name=“link“> http://www.tu-dresden.de </part> select submit textinput checkbox option Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

DDL – Dialog Description Language container container atom atom container container part part part part part part part part part Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Ausgabe auf Displays verschiedener Geräte DDL WAP Handy PC - Standardbildschirm Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

DDL - Erfüllung von Anforderungen Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an verschiedene Geräte Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Zusammenfassung der Ansätze UIML ISL gibt viel des Layouts durch abstrakte Dialogelemente vor Layoutinformationen durch Customization Forms IML DDL passt Informationsgehalt der Bildschirmgrösse an verwendet wie UIML abstrakte Dialogelemente überlässt nur die Layoutgenerierung dem Computer UIML: Probiert sehr viel des Layouts durch abstrakte Dialogelemente vorzugeben IML: Versucht Layout komplett zu generieren ISL: Probiert IML durch Customization Forms mit Layoutinfos zu versehen DDL: Kuemmert sich nur um Display-orientierte Elemente und versucht Informationsgehalt der Bildschirmgrösse anzupassen. (verwendet wie UIML abstrakte Dialogelemente, überlässt nur die Layoutgenerierung dem Computer) Versucht Layout komplett zu generieren Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Vergleich der Ansätze   Trennung von Inhalt, Struktur und Logik UIML IML ISL DDL Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen  Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Möglicher Ansatz für die Projektgruppe Interaction Acts (ISL) VoiceXML Dienst Interaction Engine Interaction Engine HTML Customization Form Customization Form DDL Fragment- ierung tinyHTML interaction engine und Customization Form nicht mehr geräteabhängig, da in abstrakte Sprache DDL übersetzt -> weniger aufwendig -> weniger Anpassung an Geräte möglich Für jede Gerätefamilie eine interaction engine Für jede Gerätefamilie u. jeden Dienst ein Customization Form WML Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Interessenkonflikt einfach kompakt Flexibilität Anpassung ISL DDL Da wenig Dienste und Geräte würde ich die Qualität der Anpassung vorziehen Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Wichtigste Anforderungen für die Projektgruppe UIML IML ISL DDL Trennung von Inhalt, Struktur und Logik  Vorteile von gerätespezifischen Fähigkeiten nutzen  Darstellung durch Dienstentwickler beeinflussbar Validation gültiger Benutzereingaben Erweiterbarkeit Wiederverwendbarkeit von Code durch Vererbung Keine Komplexität Automatisierte Anpassung an Displaygröße Zeile 2: Oberfläche und Funktion optimal an Geräte anpassen Zeile 3: Design der Dienste beeinflussen Zeile 4: Zeile 5: Erweiterbarkeit auf andere Geräte und Dienste sehr wichtig Letzten beiden Zeilen: für unser Projekt haben wir 3 Dienste geplant und auch nicht so viele verschiedene Geräte, deshalb ist das Erzeugen einer interaction engine pro Gerät nicht so tragisch und customization forms pro Gerät u. pro Dienst Auch ok, um die gerätespezifischen Fähigkeiten zu nutzen Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Möglicher Ansatz für die Projektgruppe ISL Geräte - unabhängig Geräte - abhängig Dienst - unabhängig Geräte - abhängig Dienst - abhängig User Interface Interaction Acts Dienst Geräte- bibliotheken Interaction Engine Customization Form XSL- Stylesheet ISL für Projektgruppe gut Zusätzliche Anforderungen einbauen Validation von Benutzereingaben Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

Möglicher Ansatz für die Projektgruppe ISL XSL A1 HTML XML A eine XSL-Datei pro Dienst und pro Gerät XSL A2 WML XSL B1 XML B XSL B2 CF A1 XML A HTML E 1 eine Engine pro Gerät ein CF pro Dienst ISL für Projektgruppe gut Zusätzliche Anforderungen einbauen CF A2 CF B1 XML B WML E 2 CF B2 Motivation Lösungsansätze Vergleich der Ansätze Ansatz für die PG 28.10.2003

für die Aufmerksamkeit! Vielen Dank für die Aufmerksamkeit!  28.10.2003

Backup Dienste WML E-mail E-mail E-mail WML E-mail HTML Kartendienst tinyHTML E-mail tinyHTML E-mail WML E-mail HTML Kartendienst Browser HTML Benutzer wollen mit vielen Diensten von vielen verschiedenartigen Geräten kommunizieren (konkretes Beispiel nennen: Dienst - PC, Handy) (verschiedene Dienste mit unterschiedlichen Geräten ansprechen) Geräte haben unterschiedliche Leistungsfähigkeit (Speichergröße, Rechenleistung, ….) Und unterschiedliche Eingabe- / Ausgabearten (Bildschirm – Lautsprecher. Tastatur, Maus, Mikrofon) Einen Dienst für jedes Gerät einzeln zu Entwickeln -> teuer Manuelle Anpassung -> teuer Möglichkeiten: Gleiche Oberfläche auf allen Geräten Gerät mit geringster Leistung begrenzt die Funktionalität Vorteile von gerätespezifischen Eigenschaften werden nicht genutzt (Mikrofon, Scrollrad) Oberflächendesign nicht steuerbar (für wirtschaftliche Aspekte wichtig) Neue Version auf jedem Gerät Hohe Kosten für Implementierung Hohe Kosten für Wartung Motivation Lösungsansätze Vergleich der Ansätze Ausgewählter Ansatz Zusammenfassung 28.10.2003

Backup WML E-mail HTML tinyHTML Struktur Struktur Struktur Inhalt Motivation Lösungsansätze Vergleich der Ansätze Ausgewählter Ansatz Zusammenfassung 28.10.2003

? Backup WML E-mail HTML tinyHTML Inhalts-beschreibungssprache Optionale Elemente HTML Motivation Lösungsansätze Vergleich der Ansätze Ausgewählter Ansatz Zusammenfassung 28.10.2003