Der folgende Text soll dem Leser einen kurzen Überblick über die XML1 basierte Auszeichnungssprache für Benutzerschnittstellen UIML2 verschaffen. Die Entwickler von UIML haben es sich zur Aufgabe gemacht eine Sprache zu entwickeln, die - geräte- und plattformunabhängig - Schnittstellen zwischen dem Anwender und der logischen Computeranwendung beschreibt. Desktop PCs, PDAs, SmartPhones, Handies und all die anderen Geräte, worauf computergenerierte Benutzeranwendungen laufen, besitzen bestimmte Eigenschaften und unterschiedliche Rahmenbedingungen. Ein PDA hat zum Beispiel einen viel kleineren Bildschirm als ein PC und ein Handy hat womöglich Schwierigkeiten damit grafische Elemente darzustellen, weshalb text- oder stimmenbasierte Schnittstellen günstiger wären. Um eine Anwendung für verschiedene Geräteklassen verfügbar zu machen, müsste der Schnittstellen-Designer verschiedene Programmiersprachen beherrschen, damit er für jedes Gerät und dem darüberliegenden Betriebssystem eine entsprechende Benutzerschnittstelle entwerfen kann. Diesem Problem der Inkonsistenz und der Plattformabhängigkeit will man mit einer höheren Abstraktion des Schnittstellenentwurfs entgegenwirken.
UIML ist eine universale(insb. portable), geräteunabhängige Auszeichnungssprache, die auf eine natürliche Weise die Trennung zwischen dem logischen Code und der Benutzerschnittstelle bietet. Weiterhin soll sie dadurch die Zeit reduzieren, die bei der Entwicklung von Benutzerschnittstellen für mehrere Endgeräte verloren geht und das Entwerfen eines Prototyps beschleunigen. Eine wichtige Anforderung bei der Entwicklung von UIML war es, dass diese Sprache beliebig für neuartige Geräte erweiterbar ist. Um diese Ziele erreichen zu können existieren in UIML Elemente bzw. Ebene die teilweise aufeinander liegen.
In einem UIML Dokument gibt es fünf Elemente, oder besser gesagt Schnittstellen auf fünf verschiedenen Ebenen - Structure element, Content element, Behavior element, Style element, Peer element -. Der Strutcure element Teil des UIML Dokuments umfasst die Angabe der Interaktionselemente mit deren eindeutigen Namen, der Elementklasse und deren Hierarchie, wodurch das ganze Gerüst aufgespannt wird. Dieses Gerüst kann dann in einem seperaten XML Element mit Inhalt(Text, Ton, Bild) gefüllt werden. Dies geschieht im Content element Teil. So ist es möglich Benutzerschnittstellen für verschiedene Sprachen zu entwerfen, da nur der Content element Teil ausgetauscht werden muss. Im Behavior element Teil wird das Verhalten der Benutzerschnittstelle auf die Interaktion des Benutzers beschrieben. Dieses Verhalten kann nur interne Auswirkungen - also auf die Eigenschaften und Werte der Benutzerschnittstellen - haben, oder aber auch externe Auswirkungen auf den darunterliegenden Skript oder Programm. Damit aber der Strukturierte Inhalt auch in jeder Plattform dargestellt werden kann, bedarf es einer Übersetzung der allgemeinen Beschreibung der Elementklasse auf die plattformspezifische Sprache. Dieses Mapping findet im Style element Teil statt. Und damit die Benutzerschnittstelle auf die logische Anwendung aufgesetzt werden kann müssen einzelne Elemente der Benutzerschnittstelle mit den Methoden bzw. Funktionen der Programms verknüpft werden. Der Teil in dem dies geschieht heißt Peer element. UIML ist eine Metasprache wie XML und beinhaltet keine Plattformspezifische Tags wie "<WINDOW>" oder "<MENU>". Stattdessen werden eine Reihe allgemeiner Tags wie "<part>" oder <property>" zur verfügung gestellt. Somit hat der Schnittstellen-Designer die Freiheit die Instanz- und Klassennamen intuitiv zu setzen. Die Übersetzung der Klassennamen auf ein Vokabular einer konkreten Plattform erfolgt dann in einem anderen Teil des UIML Dokumentes. UIML beinhaltet das plattformspezifische Vokabular nicht, sondern trägt dieses nur im Attribut der Tags, weshalb die weiter oben angesprochene Erweiterbarkeit der Sprache gewährleistet ist.
Es gibt verschiedene Möglichkeiten ein UIML Dokument zu verwenden. Eine Möglichkeit ist es, das UIML Dokument oder den gerendert bzw. kompilierten Code mit dem Programm auszuliefern. Die andere Möglichkeit ist es das UIML Dokument auf einem Server zu speichern, welcher auf eine Anfrage eines Clients den clientplattformabhängigen Code produziert und abschickt. Der Server kann dem Client auch einfach ein UIML Dokument zuschicken, unter der Voraussetzung, dass der Client das Dokument interpretieren kann. Dieser Vorgang wäre dann analog zur Funktionsweise eines Webbrowsers. Das hat den entscheidenden Vorteil, dass kein ausführbarer Code heruntergeladen muss. Die ganze Programmlogik würde auf dem Server verbleiben und der Client würde nur eine Interaktionsschnittstelle bekommen. Kleine portable Endgeräte (z.B. Handies), würden weniger Probleme durch ihre beschränkte Bandbreite oder Speicherplatz haben. Außerdem steckt der Aspekt der Sicherheit im Netz eine wichtige Rolle. Da ein UIML Dokument nur ein Text Dokument ist, ist es unmöglich einen schädlichen, ausführbaren Code in das Endgerät einzuschleusen.
Ein Beispiel eines Mappings:
<style>
<property class="MenuItemOrIcon" name="rendering" value="MenuItem" />
...
</style>
Übersetzung für Java
<peers>
<presentation name="Java-AWT">
<component name="MenuItem" maps-to="java.awt.MenuItem">
</presentation>
...
<peers>
Das Grundgerüst eines UIML Dokumentes:
<?xml version="1.0"?>
<!DOCTYPE uiml PUBLIC
"-//UIT//DTD UIML 2.0 Draft//EN"
"http://uiml.org/dtds/UIML20.dtd">
<uiml>
<head> <meta> ... </meta> </head>
<peers>
<presentation> <component> ... </component> </presentation>
<logic> <component> ... </component> </logic>
</peers>
<template> ... </template>
<interface> ... </interface>
</uiml>
Das Grundgerüst des interface Elementes:
<interface>
<structure> <part> ... </part> </structure>
<style> <property> ... </property> </style>
<content> <constant> ... </constant> </content>
<behavior> <rule> ... </rule> </behavior>
</interface>
Im Großen und Ganzen eignet sich UIML in der Interaktionsdesign-Phase um ein einheitliches "Look and Feel" für mehrere Plattformen zu entwerfen. Dadurch, dass ein Mapping in eine konkrete Plattform ermöglicht wird, können Benutzerschnittstellen für nicht-grafische Ausgabegeräte mitentworfen werden. Die Idee einer universellen Sprache ist zwar fortschrittlich aber noch nicht am Endpunkt der Entwicklung angelangt. So muss man immer noch beachten, dass jede Plattform ein anderes Vokabular mit sich bringt. Versuche man ein generisches Vokabular, d.h. ein Allzweck-Vokabular wie Javas AWT, zusammenzustellen, wäre der größte gemeinsame Nenner zu klein, um jede Geräteklasse richtig auszureizen. Weiter muss man sich auf den Renderer - also dem Programm, der das UIML Dokument in Code umwandelt - vertrauen, der womöglich etwas anders darstellt, als man es sich vorgestellt hat. Generalisierung hat zwar Plattformunabhängigkeit gebracht, aber bringt auch die Artenvielfalt mit sich. Um die wilde Wucherung in Grenzen zu setzen, ist abzuwarten, ob bestimmte Vokabulare standardisiert werden.
Dieses Dokument ist auch als PDF vorhanden.
http://www.cip.ifi.lmu.de/~kimdav/mmi/kim_uiml.pdf
Quellen
1 UIML: An XML Language for Building Device-Independent User Interfaces , XML '99, Dec. 1999, Philadelphia
http://www.harmonia.com/resources/papers/xml99Final.pdf (15.11.2005)
2 UIML: An Appliance-Independent XML User Interface Language, WWW8, May 1999, Toronto
http://www.harmonia.com/resources/papers/www8_0599/index.htm(15.11.2005)
3 UIML und XML als Modellierungssprachen für User Interfaces, Christian Köpke
http://wwwcs.uni-paderborn.de/cs/ag-szwillus/lehre/ss02/seminar/semband/ChristianKoepke/html/index.html(15.11.2005)