OVID to AUIML - User-Oriented Interface ModellingCopyright 2000 IBM United Kingdom Limited
This paper is a condensed version of a larger technical report. Please contact Pedro Azevedo if you would like more information about it.
This paper aims to describe the importance of UML in representing object-oriented user interfaces. It does so by discussing the OVID to AUIML project, in which UML provided the basis for unambiguously representing the OVID user interfaces and effectively coding enough information in them to allow AUIML rendering.
The objective of the OVID to AUIML project was to link the OVID (Object, View and Interaction Design) method to AUIML (Abstract User Interface Markup Language). This would allow object-oriented interface designers who chose to use the OVID user-oriented interface design method to effectively see immediate visual representations of the interface they are modelling in OVID UML notation. Simultaneously, their interface models would also be automatically checked for consistency with the data model. The result of using the OVID method should be better interfaces; the aim of this project is to help OVID become a more effective tool for everyday use.
Three steps needed to be fulfilled in order to achieve this:
This project focused on the first two aforementioned steps. The third step was fulfilled through the use of existing AUIML renderers.
From the user's perspective, the tool developed in this project would allow him to see what the interface he is modelling in UML following the OVID method might look like once it has been implemented. The AUIML code generation and rendering would be invisible to the user, who would simply need to press a button to be given the visual representation. The potential users of such a tool would essentially be object-oriented interface designers.
"The OVID methodology (Object, View, and Interaction Design) is a set of techniques for designing object-oriented user interfaces." It is focused "on three elements of user interface design: the objects that the user perceives, the views that are provided of these objects, and the interactions that the user has with these objects." It is "a formal methodology for designing the user experience based on the analysis of users' goals and tasks."
Objects are the main "building blocks" in Object, View and Interaction Design. Views of such objects are required so the user can see them and have an interface for performing actions on them. Interactions must then be defined for performing those actions.
OVID is applied once user goals, tasks and objects have been identified. Its input comes from requirements and user task analysis, whereas its output consists of "an abstract diagram that describes the architecture of the desired design, from the users' point of view." Being an iterative method, OVID can handle changes in requirements and design refinements.
Throughout product development, more advanced design prototypes should be regularly produced and tested, so that user feedback may be increased.
When time for implementation arrives, programmers should have little difficulty interpreting OVID diagrams, as they can build "the implementation classes based on the model that has already been captured."
For more information please follow the Object, View and Interaction Design link in the IBM Ease of Use website.
AUIML (Abstract User Interface Markup Language) is "an XML vocabulary which has been designed to allow the intent of an interaction with a user to be defined." This clearly contrasts with the conventional approach to user interface design, which focuses on appearance. With an intent based approach, designers are able to "concentrate on the semantics of the interactions without having to concern themselves with which particular device type(s) need to be supported."
Being an XML vocabulary, AUIML allows device independent encoding of information. All the interaction information can be encoded once and subsequently rendered using "device dependent rendering" so that users can actually interact with the system. AUIML is therefore "intended to be independent of the client platform on which the user interface is rendered, the implementation language and the user interface implementation technology."
The following example describes an interface that simply asks the user for his name. In the actual working version of the interface, the user should be given the four listed choices for his title, and also entry fields for first name, initial and last name.
<GROUP NAME="PersonName">
<CAPTION><META-TEXT>Person's complete name</META-TEXT></CAPTION>
<CHOICE NAME="PersonTitles" SELECTION-POLICY="SINGLE">
<CAPTION><META-TEXT>Title</META-TEXT></CAPTION>
<HINT><META-TEXT>This is a set of valid titles you may choose from.</META-TEXT></HINT>
<STRING NAME="MR">
<CAPTION><META-TEXT>Mr.</META-TEXT></CAPTION>
</STRING>
<STRING NAME="MRS">
<CAPTION><META-TEXT>Mrs.</META-TEXT></CAPTION>
</STRING>
<STRING NAME="MISS">
<CAPTION><META-TEXT>Miss</META-TEXT></CAPTION>
</STRING>
<STRING NAME="MS">
<CAPTION><META-TEXT>Ms.</META-TEXT></CAPTION>
</STRING>
</CHOICE>
<STRING NAME="FirstName">
<CAPTION><META-TEXT>First Name</META-TEXT></CAPTION>
</STRING>
<STRING NAME="Initial">
<CAPTION><META-TEXT>Initial</META-TEXT></CAPTION>
</STRING>
<STRING NAME="LastName">
<CAPTION><META-TEXT>Last Name</META-TEXT></CAPTION>
</STRING>
</GROUP>
The following is an example of what the interface described by the AUIML code above might look like after being implemented:
On one hand, the OVID method enables the interface designer to produce a high-quality, consistent user- and object-oriented model of the interface that can be understood and used by programmers as well.
On the other hand, AUIML is an intent-based language for defining interactions with users, focusing on semantics rather than implementation details. AUIML renderers have already been created which effectively produce visual representations of what is defined by the AUIML code.
This project aims at linking OVID to AUIML.
So what is there to be gained from that? The answer is: the possibility of seeing a visual representation of the interface defined by a given OVID UML diagram whenever necessary, while at the same time automatically validating the diagram. Indeed, by linking OVID to AUIML, the interface designer can both automatically check whether his OVID views and interactions are consistent with his data model objects and also produce unambiguous "sketches" of the views contained in an OVID UML diagram. In summary, linking OVID to AUIML can help the interface designer essentially by:
As the OVID model grows, more difficult and time-consuming its validation becomes. However, it is important to ensure that the views presented to the user do accurately reflect the object model, in order to prevent inconsistencies that may prove very harmful to the final usability level. While reading the diagram before the AUIML code is produced, automatic validation can be achieved as a result of this project and greatly increase the designer's peace of mind and time available for other tasks.
The considerable importance of automatic validation notwithstanding, the main goal of this project is the ability to automatically translate your abstract OVID model into a rendered interface with which one can even interact to a certain degree.
Visualising a large abstract diagram can often be complicated. And the more frequently this is required, the more time-consuming and error-inducing it becomes. Designers will tend to resort to hand-drawn sketches of the interface based on the OVID model whenever significant changes have been made that justify a less abstract update. Besides time-consuming, these hand-drawn sketches may contain errors due to misinterpretation of the OVID model or simple overlooking of certain model details. A quick, accurate and more realistic visual representation should therefore be very useful for the designer.
For similar reasons, this can also enhance user feedback. A selected group of users will be able to frequently analyse the actual look and feel that the interface defined by a given diagram might have once implemented, instead of looking at an abstract diagram or a far less suggestive and potentially error-ridden, non-interactive hand-drawn sketch.
Testing the structure and functionality of the interface described by the OVID diagram is also greatly enhanced by the output of this project, both because of its highly increased fidelity compared to a hand-drawn sketch and its ability to behave dynamically, by branching between views, for example.
Consequently, this generation of automatic visual representations will be equally useful for producing proof of concept - something that can be analysed by everyone in the team, shown to potential users or clients, etc.
Overall, in the frequently needed task of producing visual representations of the OVID diagram, both accuracy and realism will increase while inconsistencies and time consumption will decrease. Simultaneously, OVID diagram consistency validation becomes automated, causing very significant improvements in terms of reliability and efficiency.
To illustrate what can be achieved by linking OVID to AUIML, the "Send Fax" example was built to reflect a simple interface in which information is requested for sending a given fax. In terms of views and interactions, this can be modelled as follows in an AUIML-enhanced OVID UML diagram:
The Send Fax view is defined as having two attributes, Economy and Subject (respectively an AUIML Choice and String) and one operation, Send. Similarly, the Person view has attributes Name and Organization (both Strings) and operation Look Up. Finally, the Telephone Number view only has an attribute of type Hint.
Documentation, however, further details these elements. For example, in the Economy attribute documentation, the available choices are listed; in the Telephone Number class documentation, the view is defined as being of type String (the other two are of type Group by default).
The aggregations (the first two of which are numbered for sorting) specify that Send Fax has a From Person and a To Person view, while each Person view has a Phone Number and a Fax Number, both of which are Telephone Number views.
By linking OVID to AUIML, the following visual representation is one mouse click away:
Had a more complex OVID UML diagram been defined, the Look Up buttons could branch to a view of an address book table, for example, as indicated in section 3.1.
In more general terms, as the example illustrates, views are represented as UML classes using a "view" stereotype. Interactions are then defined through the attributes, operations and associations of each view class. UML view class attributes map directly into rendered OVID view attributes. Similarly, view class operations and OVID view interactions are also closely related.
The associations between views also define the structure of the interface in terms of how the different views are nested and how some views may be reached from others. Aggregation relationships can also be used in order to specify that a certain view should be nested within another (i.e. that view A has a view B within it). Dependency relationships between views induce the creation of an action button that allows branching from one view to another.
AUIML details can then be specified in class, attribute and operation documentation.
The OVID to AUIML process is divided in three stages:
The program, which has been implemented in Visual Basic 6, will recursively read information from the UML diagram, using the associations it finds to create the aforementioned recursivity. Class, attribute, operation and association information and documentation are retrieved and stored in an intermediate internal data structure: a collection of AUIML-enhanced OVID views. This first stage has been implemented for use with Rational Rose only; however, this intermediate representation of the information is Rose independent, as is the rest of the process.
From the information contained in that intermediate data structure, AUIML markup is created. The markup language structure is reproduced by recursively processing the stored view elements.
Finally, an external AUIML renderer is invoked to produce the visual representation of the OVID UML diagram through the AUIML markup that has been created.
Scope for future improvement can still be found, however. Two main areas can be distinguished:
The fact that the first half of the program has been implemented exclusively for use with Rational Rose may be seen as an undesirable handicap. Despite the fact that the AUIML code producing half of the program is indepdent of the UML tool being used, there is currently no alternative to the Rose-dependant half that reads the OVID diagrams.
However, this Rose-dependant first half both acts as proof of concept and simultaneously already supports the most widely spread UML editor today. Adding to this a general, Rose-independent AUIML code producing second half should, on the other hand, greatly facilitate the creation of a more general, Rose-independent OVID UML reading section.
Not all funcionality and detail of AUIML can currently be included in AUIML-enhanced OVID diagrams as they have been defined. Certain aspects of AUIML proved to be very difficult to represent in an intuitive manner in OVID diagrams and, as such, were not implemented. These include the When-event tags and their item-manipulation verbs and Tree Node structures.
AUIML itself is still evolving, and its future enhancements will also potentially benefit OVID to AUIML's UML diagrams.