UIML (User Interface Markup Language)

Daniel Hilkert

Die Initiative eine Plattformunabhängige Beschreibungssprache für Benutzerschnittstellen zu erschaffen, begann 1997. Die Notwendigkeit eine derartige Sprache zu erschaffen entstand durch die immer größer werdende Anzahl von verschiedenen Geräten auf den Benutzschnittstellen für Systeme erstellt werden müssen. Hierfür wurden und werden bis heute hauptsächlich spezialisierte Lösungen verwendet, wie zum Beispiel CSS und HTML für die Gestaltung von Webpages, WML für Inhalte auf Mobilfunkgeräten oder VoiceXML für Sprachgesteuerte Interfaces (1).

UIML basiert daher komplett auf XML (Extended Markup Language) und soll sowohl Plattform als auch Hardware unabhängig genutzt werden können.
Die Sprache soll hierbei konkret drei Dinge leisten (2):
Ersten soll dass Design, also die Art, Form und Anordnung der Ein- und Ausgabe Elemente bestimmt und festgelegt werden. Dies muss falls erwünscht für mehrere Medientypen (z.B. Online, Print, Mobile, etc.) separat erfolgen.
Zweitens soll die Interaktion des Nutzers mit der Benutzerschnittstelle festgelegt werden, also z.B. welcher Button welche Wirkung auf andere Ein- oder Ausgabe Elemente hat.
Drittens wird die Verbindung der Benutzerschnittstelle zur eigentlichen Programm-Logik festgelegt, also z.B. wie eine erfolgte Bestellung innerhalb eines Webshops in die Datenbank einfließt.

Der 2001 veröffentlichte Standard UIML2 enthält dabei nur etwas mehr als zwei dutzend Tags (3) die sehr allgemein gehalten sind, wie z.B.

<interface>, <structure>, <part>

, etc.. Zudem wurden zusammen mit der Veröffentlichung auch Implementierungen für verschiedene Programmiersprachen zur Verfügung gestellt. Dies macht auch den besonderen Reiz dieser Sprache aus, da die mit UIML erstellten Benutzeroberflächen automatisiert in andere Sprachen übersetzt werden können. Laut www.uiml.org stehen daher mittlerweile so genannte Toolkits für die Plattformen HTML, WML, Java, J2EE, .NET, VoiceXML, C++, Visual Basic, CORBA, Symbian und QT zur Verfügung (4). Somit kann also in einer einzigen UIML Datei eine Benutzerschnittstelle sowohl als "Thin-Client" für das Web, als "Fad-Client" in Java aber auch als Barrierefreie Version in VoiceXML zur Sprachausgabe festgelegt werden.

Ein in der Literatur häufig genanntes Beispiel für ein Einsatzgebiet von UIML ist hierbei ein Pizzadienst der ein neues Bestellsystem einführen möchte. Mit diesem sollen mit einem normalen PC, einem Palm Handheld einem modernen Handy aber auch mit einem alten Telefon Pizzas elektronisch bestellt werden können (5).
Hierbei entstehen verschiedene Probleme. Zunächst müsste ein entsprechender Programmierer vier verschiedene Plattformen und die dazugehörigen Programmiersprachen beherrschen, das wären im oben genannten Beispiel Java für den Desktop PC, C für den Palm, WML für das Handy und VoiceXML für das sprach-gesteuerte Telefon. Zudem müsste in allen vier Sprachen in der Programmlogik festgelegt werden wie die entsprechenden Bestellungen in die Datenbank einfließen.
Falls der Funktionen hinzugefügt oder verändert werden muss dies natürlich allen Systemen umgesetzt werden.
Um die Entwicklung genau solche Systeme zu vereinfachen wurde UIML geschaffen.
Falls es in Zukunft ein neuartiges Gerät geben sollte würden sich die genannten Probleme natürlich noch vergrößern.

Die Grundstrucktur von UIML ist sehr einfach gehalten, es werden nur sehr wenige "Befehle" in Form von Tags verendet. Zudem handelt es sich wie eingangs erwähnt um eine auf XML basierte Sprache. Wie eine solche Datei aussehen kann soll folgendes Beispiel veranschaulichen (6):

	<?xml version="1.0"?>
	<!DOCTYPE uiml PUBLIC "-//Harmonia//DTD UIML 2.0 Draft//EN" "UIML2_0g.dtd">
        <!--
          Basic Java UI with two parts and a <behavior> section. JButton presses change the button label.
          -->
		<uiml>
			<interface>

				<structure>
					<part id="Top" class="JFrame">
						<part id="Button" class="JButton"/>
					</part>
				</structure>

				<style>
					<property part-name="Top" name="title">
						<reference name="WindowTitle"/>
					</property>
					<property part-name="Top" name="bounds">100,100,300,100</property>
					<property part-name="Button" name="text">
						<reference name="ButtonText.Regular"/>
					</property>
				</style>

				<content>
					<constant name="WindowTitle">UIML Example</constant>
					<constant name="ButtonText">
						<constant name="Regular">Press Me</constant>
						<constant name="Pressed"> Button pressed.</constant>
					</constant>
				</content>

				<behavior>
					<rule>
						<condition>
							<event class="actionPerformed" part-name="Button"/>
						</condition>
						<action>
							<property part-name="Button" name="text">
								<reference name="ButtonText.Pressed"/>
							</property>
						</action>
					</rule>
				</behavior>

			</interface>

			<peers>
				<presentation base="Java_1.3_Harmonia_1.0"/>
			</peers>
		</uiml>

Eine UIML Datei ist dabei grundsätzlich in zwei Blöcke eingeteilt, den Block < interface> ... </interface> sowie den Block < peers> ... </peers>.
Wie der Name bereits vermuten lässt wird im ersten Block die Schnittstelle selbst definiert. Dieser hat Grundsätzlich die Struktur (7):

	<structure> ... </structure>
	<style> ... </style>
	<content> ... </content>
	<behavior> ... </behavior>

In <structure> wird dabei die Struktur der Oberfläche festgelegt, also im angegebenen Beispiel dass es sich um einen Java JFrame mit einem Button darauf handelt.
In <style> werden die Eigenschaften, im Beipiel also Fenstertitel sowie Position, Größe und Beschriftung des Buttons, für die in <structure> festgelegten Elemente gesetzt. Die Beschriftungen könnten hierbei direkt eingegeben werden, eleganter sind jedoch die verwendeten Verweise ( <reference ... /> ) auf Konstanten.
Diese Konstanten werden in <content> deffiniert. Hierbei können einfache Elemente deffiniert werden, jedoch auch verschachtelte Elemente wie im Beispiel für die beiden Zustände "Regular" und "Pressed" des Buttons. Diese Form der Referenzierung ermöglicht ein konsequente Trennung von Style und Inhalten was zum Beispiel im Hinblick auf eine möglicherweise notwendige mehrsprachige Version des Interfaces große Vorteile bietet.
In <behavior> wird dann das eigentliche Verhalten der Benutzerschnittstelle durch Regeln ( <rule> ) definiert. Diese Regeln bestehen aus einer Bedingung ( <condition> ), hier also dass eine Aktion mit dem "Button" ausgeführt wurde, die erfüllt sein muss damit eine Aktion ( <action> ) ausgeführt wird, hier also die Beschriftung des Buttons verändert wird. Auch hier kann natürlich wieder auf die im <content> deffinierten Konstanten zurückgegriffen werden. Im zweiten großen Block < peers> ... </peers> wird dann die Zuordnung ("one's peers" entspricht "seinesgleichen" im Deutschen) der in Interface definierten Elemente zu den Elementen in der jeweils verwendeten Programmiersprache festgelegt. Dies geschieht im Beispiel über ein Standard-Toolkit für Java das im UIML Standard bereits enthalten ist.
Die hier beschriebene Schnittstelle würde sich also so darstellen (Zweites Bild: drücken des Buttons):

Link zu Bild 1
Link zu Bild 1

Dieser Weg mag sich für geübte Java Programmierer als reichlich unnütz darstellen, entscheidend ist jedoch die Möglichkeit dieselbe Schnittstelle mit geringem Aufwand auch in andere Programmiersprachen für andere Plattformen zur Verfügung zu stellen, und all dies ohne konkrete Kenntnisse der jeweiligen Programmiersprachen. Auch eine Änderung des Interfaces sowohl bei der Darstellung als auch in Bezug auf Funktionalitäten wird durch UIML erheblich vereinfacht, da die entsprechenden Änderungen nur einmal ausgeführt werden müssen und nicht für jedes System einzeln.
Selbst für Plattformen der Zukunft wird es lediglich notwendig sein, einmalig ein entsprechendes Toolkit zu entwickeln um vorhandene Benutzerschnittstellen auch für diese zu adaptieren.

Um somit noch mal auf das weiter oben beschriebene Beispiel des "Pizza Lieferanten" zurückzukommen erscheint es nun einleuchtend dass UIML für alle genannten Probleme eine adäquate Lösung bietet.

Kritisch zu betrachten ist jedoch, dass in UIML spezifische Elemente entsprechend des verwendeten Toolkits verwendet werden und somit erneut Insel Lösungen entstehen können. Zudem lehrt die Erfahrung der Vergangenheit, dass das automatische generieren von Oberflächen häufig Probleme birgt (8).

Zusammenfassend lässt sich also sagen, dass UIML im Ansatz sicher äußerst interessant ist und zahlreiche Vorteile bietet, es wird jedoch möglicherweise sehr schwierig werden es als Plattform-übergreifenden Standard zu etablieren, da der Funktionsumfang von speziellen Lösungen wie zum Beispiel HTML und CSS bzw. XHTML und XSLT nur sehr schwer oder gar nicht erreicht werden kann.

Quellen:

1.) http://www8.org/w8-papers/5b-hypertext-media/uiml/uiml.html
2.) Analog zu http://xml.coverpages.org/uiml.html (Abgerufen am 12.11.2005)
3.) Siehe http://www.uiml.org/tools/index.htm (Abgerufen am 12.11.2005)
4.) Siehe http://www.uiml.org/tools/index.htm (Abgerufen am 12.11.2005)
5.) Beispiel analog zu http://mit.iddl.vt.edu/courses/cs5244/coursecontent/mod5/lesson2/uiml2.html (Abgerufen am 13.11.2005
6.) Beipiel aus http://mit.iddl.vt.edu/courses/cs5244/coursecontent/mod5/lesson2/uiml6.html jedoch leicht verändert (Abgerufen am 13.11.2005)
7.) Siehe http://mit.iddl.vt.edu/courses/cs5244/coursecontent/mod5/lesson2/uiml5.html
8.) siehe dazu http://www.heise.de/newsticker/foren/go.shtml?list=1&forum_id=5257