===========================================================================================================
UIML and XForms
On the surface, UIML and XForms appear to be very similar technologies and
there are some areas where they address similar problems. Therefore, it is instructive to compare
their solutions. In terms of a Venn diagram, the range of UIs (user interfaces)
you can describe with XForms is a strict subset of those you can describe using
UIML. In fact, UIML can be used to
define interfaces that represent not only the XForms sections of the UI, but
also the XHTML in which the XForms tags are embedded. Basically UIML provides flexibility in
form and function that can be used to represent any UI. However a synergy should exist between
UIML and XForms, so it will be useful to explore the differences between the two
technologies and discover where they complement each other.
UIML and XForms were designed from different worldviews:
·
XForms originated to enhance forms in Web pages; to overcome many
of the limitations in look, feel, and functionality of the <form> and
related tags from HTML; to provide a more sophisticated model of interaction
between the server and the browser; to introduce types so that form input can be
validated; and later to support form deployment on different devices. XForms had
to build on the concepts in HTML forms to be familiar to the Web community and
to provide a smooth transition from today's authoring tools, browsers, and
servers to XForms enabled pages.
·
UIML’s initial design perspective emerged from a “clean sheet of
paper” unhindered by any metaphors, and was formed by asking very fundamental
questions of what information is required to describe any user interface,
regardless of device, interface metaphor, or widget set. The language design
goal of UIML was to provide a meta language powerful enough to subsume the
concepts in every language ever designed to describe or implement user
interfaces. This means that UIML would be capable of defining a canonical
representation of any UI. The
ability to create the canonical representation of any UI allows a vision of a
world in which every researcher or product company whose technologies fuel
e-business can interchange and interoperate by using UIML as the common
interchange language. This is very important to facilitating the use of results
coming out of the HCI community in models and transforms. For example, if HCI
people designing transforms created UIML-to-UIML transforms, they could
potentially be applied no matter whether the UI is ultimately translated to Java
or XForms. Similarly, UIML can be
used to serve as an intermediary so that transforms designed by one researcher
from a language or model to UIML can be used in conjunction with transforms
designed by another researcher from UIML to another language or model. An example of this is shown in work by
Ralph Miller and Scott P. Overmyer, where they translate a meta-language called
Requirements Element Language (REL) into UIML and back. In contrast, XForms has a more immediate
objective, and is not powerful enough to serve as this universal interchange
representation.
UIML touches on issues that were not familiar for the HTML world.
·
First, UIML provides strict separation or factorization of the
user interface elements. For example, the words, pictures, videos and other
content of the UI should be separated from the UI structure for other concerns.
This is not done in XForms. Instead, XForms enforces a separation of
instance data from UI controls. The
UI controls still encapsulate all content of the UI, meaning that label text and
UI control content are still integrated into the UI control. This can make internationalization
difficult. More generally, UIML is
based on an extension to the Model/View/Controller model, called the Meta
Interface Model (See http://scholar.lib.vt.edu/theses/available/etd-08122000-19510051/unrestricted/PhanouriouETD.pdf
for details). The MIM provides a six-way separation: UI structure, presentation
style, content, behavior rules, connection of the UI to whatever code is outside
of the UI (e.g., business logic), and mapping of the vocabulary used for
class/property/event names to widget set or XML tags to which the UI is mapped.
·
Second, UIML can describe any method of connection between the UI
and whatever the UI "talks to". In particular, UIML should describe the wiring
of the UI to business logic that uses a procedure call model, or a Web services
server that uses SOAP; or a web server using HTTP GET and PUTs; or a
publish/subscribe protocol using events to push content to the UI; and so on. In
contrast, XForms builds on the HTTP GET/PUT model of the Web.
·
Third, UIML allows any UI metaphor (e.g., card-based, Web
form-based, desktop GUI application, voice dialog, 3D immersive environments,
etc.). In contrast, XForms is restricted to the web-forms model of
interaction.
·
Fourth, UIML should capture author intent. This is possible by
allowing descriptions of UIs expressed using abstractions of the author's choice, rather than the choice of the
language designer or widget designer. For example, someone designing a course or
training may want to think in terms of a UI that has an outline, a list of
objectives, prerequisites, etc.. A UI designer for autos may think in terms of
steering wheel buttons, driver alerts, etc. A UI designer for displays in
factory automation may think in terms of the flow of the manufacturing process.
If these UI designers use a traditional UI development tool (e.g., Visual Basic,
Dreamweaver, Forte), they are forced to translate their thinking to the level of
VB or HTML form or Java widgets, because the palette they use to design the UI
contains widgets. In contrast, because UIML is a meta-language to which one adds
a vocabulary, one can devise vocabularies specific to course designers versus
auto designers versus an industrial engineer and so on, which represent the
author intent independently of the particular widgets used with a particular
target language or device. This view is not really captured in XForms.
·
Fifth, UIML should support behaviors, so that much of the
JavaScript in traditional web pages can be described in a device-independent
form. In contrast, XForms uses XEvents. The event-based description format used
in UIML was based on research in the UIMS literature such as Hartson and Hix’s
1993 book User Interface Development: Ensuring Usability through Product and
Process. In UIML, interface
authors can define a set of rules, like a rule-based system, that are stated in
terms of conditions and actions. These rules are (1) separated from the rest of
the UI, and (2) described in a device-independent format. These rules define a rulebase from which
rules are selected as their conditions are met.
·
Sixth, UIML vocabularies have been created to represent UIs in
many languages: Java, C++ for QT widgets in Linux, C++ for an embedded system, C with PalmOS,
VoiceXML, WML, HTML, CSS, and Visual Basic. This may be a wider range of targets
than envisioned for XForms.
To summarize, UIML is an XML schema targeted to serve as a universal
interchange format that can represent any UI - regardless of UI metaphor,
language, operating system, and device. On the other hand, XForms is an “XML application that represents the
next generation of forms for the Web”.
XForms provides a vast improvement on HTML Forms and begins to address
many of the problems with facilitating interaction with remote systems. Ultimately XForms is tremendously
helpful for UIML, because mapping UIML to XForms is much easier mapping UIML to
HTML forms.
