In der Mitte der neunziger Jahren des letzten Jahrhunderts war das Leben des Software-Entwicklers einfach. Das dominierende Betriebssystem auf dem Markt war Windows 95, die dominierende Entwicklungsumgebung war Microsoft Visual C++ oder Visual Basic. Mobile Geräte waren noch Zukunft, Web-basierte Anwendungen selten (PHP3 erschien erst 1997). Plattformunabhängigkeit war kein wichtiger Anspruch. Deshalb konnte die Benutzeroberfläche auf eine Weise erstellt werden, in der der Programmierer die absoluten Koordinaten aller Elemente bestimmte, d.h. für jede Taste, Eingabefeld etc. sowohl die Position als auch die Größe in Pixel angab. Die Folge war natürlich eine völlige Abhängigkeit vom Window Manager. Selbst die Änderung der Größe des Systemfonts bewirkte, dass alle Fenster unrichtig erschienen.
Der nächste Schritt war Java, genauer gesagt: Swing. Die mit Swing erstellten Programme konnten unter fast allen Betriebssystemen für den PC funktionieren. Der Nachteil war, dass die Controls nicht nativ waren, d.h. sie wurden nicht vom Window Manager gemalt, sondern von der JVM. Sie sahen zwar auf allen Plattformen gleich aus, aber Swinganwendungen unterschieden sich optisch stark von anderen Programmen. Dieses Problem wurde durch SWT gelöst - eine Technologie, die als Teil des Eclipse-Projekts enstand. Alle Klassen, die die Benutzerschnittstellenelemente darstellten, waren nur eine abstrakte Ebene, die in verschiedenen Betriebssystemen unterschiedlich realisiert wurde - in Windows als Windows-Controls, in KDE als Gnome-Controls usw. Die absoluten Koordinaten konnten nicht bestimmt werden, denn man kannte die Dimensionen der Controls nicht im Voraus. Stattdessen mussten die relativen Positionen angegeben werden, die genauen Standorte aller UI-Elemente wurden während der Programmierarbeit durch LayoutManager berechnet.
Kurz gesagt: man kann die Geschichte der Entwicklung von UI-Technologien als eine fortschreitende Abstrahierung betrachten - in der ersten Stufe korrespondiert ein Objekt "Button" einem Button in einem bestimmten Window Manager, in der zweiten entspricht es einem Button in einem beliebiegen PC-Betriebssystem.
Mit der rasanten Verbreitung der mobilen Geräte und Web-basierten Anwendungen, wurde die Unabhängigkeit vom Betriebssystem, unzureichend. Es entstand das Bedürfnis, Programme auch Device-unabhängig zu machen. Diese Forderung ist teilweise auch durch Java erfüllt, obwohl es wegen der Unterschiede zwischen J2SE, J2ME und J2EE immer problematisch ist, einen wesentlichen Teil des Quellcodes auf allen Plattformen zu benutzen. Jedoch, selbst wenn die Business-Logic eines Systems sowohl in Fensterversion als auch in Webversion gleich ist, ist die Benutzerschnitstellenebene immer verschieden - auf der einen Seite Swing oder SWT, auf der anderen Seite HTML. Man kann daher die Frage stellen, ob es möglich ist, eine neue Abstraktionsstufe zu schaffen.
UIML (User Interface Markup Language) ist ein solcher Versuch. Die Absicht der Urheber ist es, eine Technologie zu schaffen, die es ermöglicht, die Benutzerschnittstelle für alle Plattformen auf dieselbe Weise zu erstellen. Die Konzeption von UIML besteht darin, dass die Benutzeroberfläche in einem XML-Dialekt definiert wird, der nur die abstrakte und plattformunabhängige Beschreibung der UI ermöglicht. Aus dieser Definition wird später das Fenster oder die HTML-Seite gerendert. UIML unterscheidet sich von anderen XML-Dialekten zur Definierung der Benutzerschnittstelle (Microsoft Extensible Application Markup Language, Mozilla XUL, die XML-Dateien von Gnome Glade generiert) dadurch, dass es theoretisch alle Plattforme umfasst - von typischen Windowsanwendungen bis zum Voicecontrol.
UIML definiert drei Dinge:
<interface>
<structure>
<part id="Top" class="JFrame">
<part id="Button" class="JButton"/>
</part>
</structure>
<style>
<property part-name="Top" name="title">UIML Example</property>
<property part-name="Top" name="bounds">100,100,300,100</property>
<property part-name="Button" name="text">Press Me</property>
</style>
<behavior>
<rule>
<condition>
<event class="actionPerformed" part-name="Button"/>
</condition>
<action>
<property part-name="Button" name="text">Button pressed.</property>
</action>
</rule>
</behavior>
</interface>
<peers>
<presentation base="Java_1.3_Harmonia_1.0"/>
</peers>
</uiml>
In dem ersten Teil der Datei (structure) werden alle verwendeten Benutzerschnittstellenelemente aufgezählt. Diese Elemente sind "Top" und "Button". An demselben Ort wird definiert, als welche Controls sie realisiert werden sollen (JFrame und JButton) - dieser Teil ist plattformabhängig. Im nächsten Abschnitt werden die Eigenschaften der Controls bestimmt (Titel, Position, Etikett). Die "behaviour"-Sektion enthält die UI-Logik: beim Anklicken der Taste wird ihr Text geändert. In dem letzten Teil wird den Pfad zu der Datei angegeben, die die Information darüber enthält, wie die Eigenschaften der abstrakten Controls zu den Eigenschaften der wirklichen zugeordnet werden. Ein Fragment dieser Datei:
<d-property id="bounds" maps-type="setMethod" maps-to="setBounds">
<d-param type="java.awt.Rectangle"/>
</d-property>
<d-property id="bounds" return-type="java.awt.Rectangle" maps-type="getMethod" maps-to="getBounds"/>
Um ein auf diese Weise definiertes Fenster aufrufen zu können, braucht man einen Java Renderer. Man ruft ihn auf, als Kommandozeileparameter den Name der Datei angebend (der Java Renderer kann auch in eigene Programme integriert werden).
Noch ein anderes Beispiel, dieses Mal mit HTML. Das ist ein Teil einer Datei, die eine einfache Seite mit einem Bild definiert:
<structure> <A_href ref"="http://uiml.org" > <Img src="violets.jpg" lowsrc="smviol.gif" height="180" width="120" alt="UIML" align="CENTER" space="40" border="2"/> </A_href> </structure>
Wie man schon sieht, sind die beiden Beispiele stark plattformabhängig. Ich werde zu dieser Sache noch zurückkommen.
UIML ermöglicht eine abstrakte Beschreibung der Benutzerschnittstelle. Diese Beschreibung enthält Informationen darüber, welche Bestandteile die Benutzeroberfläche umfassen wird. Die genaue Bestimmung, wie diese Bestandteile realisiert werden sollen, ist davon getrennt. Ein "Button" kann beispielweise ein echter Windows-Button sein, aber auch ein Element von voice-controlled-UI. Die Informationen über die logischen Funktionen der Controls sind daher nicht mit den Informationen über deren äußere Erscheinung gemischt. Es ist dadurch einfach, neue Varianten der UI zu erstellen (z.B. für Behinderte), und ein einheitliches Aussehen zu wahren (ähnlicher Mechanismus wie CSS in HTML).
Wie sich bei beiden oben genannten Beispielen gezeigt hatte, sind die Benutzerschnittstellendefinitionen in UIML nicht plattformunabhängig. Sowohl die Namen der Klassen, denen die Controls zugeordnet werden, als auch deren Eigenschaften hängen von Betriebssystem und Gerät ab, auf dem die UI-Beschreibung später gerendert wird. In der Tat gehören sie nicht einmal der Sprachdefinition an. Die Autoren von UIML zugeben offen, dass UIML kein "Silver bullet" ist, und dass, wenn man die Benutzerschnittstelle für verschiedenen Plattformen anfertigen will, muss man eine UIML-Datei für jede Plattform getrennt schreiben. Das resultiert unter anderem daraus, dass der Bildschirm auf verschiedenen Plattformen verschiedene Auflösungen haben kann, dass auf einer Plattform LayoutManagers erforderlich (Swing) sind, auf einer anderen müssen die absolute Koordinate angegeben werden (PalmOS) usw.
Ist mithin eine echte Plattformunabhängikeit der Benutzerschnittstelle überhaupt möglich? Ist UIML nützlich?
Die Spezifikation von UIML ist sehr arm. Nur ein Paar Keywords (part, property, structure) gehört der Spezifikation an. Alle Eigenschaften, Klassennamen usw. sind plattformabhängig. Deshalb ist es unmöglich einfach UIML zu lernen und dann Benutzeroberflächen für alle Geräte zu erstellen - man muss HTML kennen, um eine HTML-Seite in UIML zu definieren, man muss Swing kennen, um ein Swing-Formular in UIML zu machen. Die Aussage, die ich in den Werbematerialien gefunden habe, dass es mit Hilfe UIML für nicht-Informatiker viel einfacher ist, eine UI zu erstellen, ist grundsätzlich falsch.
Was UIML bietet ist daher nur eine kleine Menge einfacher Konstrukte, die bewirken, dass die in UIML geschriebenen UI-Definitionen für verschiedene Plattformen ähnlich sind (die Dateien haben dieselbe Struktur), alle entscheidenden Einzelheiten sind aber für jede Plattform verschieden. Die wirklich mühsame und beschwerliche Arbeit, d.h. das Bestimmen, wie die Benutzerschnittstelle eigentlich aussehen soll, muss jedes Mal unabhängig gemacht werden. Überdies hilft das Wissen, das ein Entwickler vom Erstellen von UIs für Swing mit UIML hat, dem Entwickler in keinerlei Hinsicht, wenn er eine Benutzerschnittstelle für PalmOS machen will.
Die technischen Details verschiedener Plattformen (die Auflösung, LayoutManager) machen eine volle Plattformunabhängigkeit unmöglich. Es gibt keine Möglichkeit, wie z.B. ein kompliziertes Fenster, das bei Auflösung 1024x768 den ganzen Bildschirm füllt, leicht auf Palm dargestellt werden kann, ohne gegen eine Reihe einfacherer Screens umgetauscht zu werden. Außerdem ist nur eine begrenzte Anzahl von typischen Controls in PC-Anwendungen auch in anderen Technologien zugänglich. Es gibt keine Kontextmenüs in HTML, keine Toolbars auf Palms, keine Dialogfenster in VoiceXML (eine Sprache für das Definieren von Voice-controlled-UIs, die in UIML übersetzt werden kann). In welcher Richtung sollen also die Versuche auf diesem Gebiet gehen?
Ich denke, man soll sich nur auf die Plattformen beschränken, auf denen eine echte Portabilität überhaupt möglich ist. Die Unabhängigkeit von Window Manager ist schon durch SWT realisiert worden, der nächste Bereich könnte die Portabilität zwischen Windows-UI und Web-UI sein. Eine solche Technologie ist schon vorhanden - sie heißt Abstract User Interface Markup Language und ist von IBM entwickelt worden (die Ähnlichkeit der Name zum Name von UIML ist nur ein Zusammentreffen von Umständen). Mit AUIML kann man Benutzerschnittstellen erstellen, die ohne kleinste Änderungen als Swing- oder Web-Anwendung eingesetzt werden können. Das ist daher ein viel weiterer Schritt nach vorne, wie UIML.
Wie hilfreich in manchen Projekten AUIML auch sein mag, diese Art von Portabilität hat ihre Nachteile. Es gibt einen grundsätzlichen Unterschied zwischen Windows- und Web-Benutzerschnittstelle, nämlich die erste ist dynamisch, die zweite statisch. Man sehe z.B. eine sehr nützliche Eigenschaft von Eclipse - wenn man etwas in einem Fenster falsch einträgt, erscheint im oberen Teil des Fensters eine Warnung und die Ok-Taste wird ausgeschaltet. Eine sofortige Reaktion des Systems auf die Handlung des Anwenders ist mit HTML nicht zu erreichen (nur wenige fortgeschrittene Informatiker würden sich trauen, JavaScript an dieser Stelle zu benutzen). Die Portabilität zwischen Window Manager und Browser erzwingt daher eine Vereinfachung der Benutzerschnittstelle, mit der sie dem Mechanismus angepasst wird: request page - send page - send response - process response. AUIML taugt nur für Programme, deren UI nur aus einfachen Formularen besteht.
Meine Beurteilung von UIML ist mit Skepsis erfüllt. Ich kann kann mich des Eindrucks nicht erwehren, dass der Unterschied zwischen einer Seite in z.B. HTML definiert und einer zweiten in UIML nur formal ist, denn alle technische Einzelheiten bleiben sichtbar, und man kann nicht die zweite ohne gutes Wissen von HTML verstehen. Die Portabilität ist nur scheinbar, das Abstraktions-Niveau ist niedrig, weil nur die Struktur der Dateien auf verschiedenen Plattformen gleich ist, der eigentliche Inhalt nicht, sogar für Plattformen, die große Ähnlichkeit zueinander erweisen (Swing und HTML).