Materials for the October TC meeting.

[James Helms <jhelms@harmonia.com>]

As part of the OASIS UIML TC meeting today we will discuss some advanced uses of templates and explore how we can accelerate the standardization of UIML.   If possible, please review the materials below before the meeting. 

 

Advanced Template topics:

There are two topics relating to templates that we want to discuss: 1) the parameterization of templates so that they may affect items outside of the template, and 2) optional template elements that can be removed by a sourcing document without removing them from the template.

 

Issue 1 is prevalent in interfaces where templates are used extensively for controls.  For example, assume that we have a template that consisted of a panel containing two buttons.  This panel may be used in several dialogs as "OK/Cancel" buttons or "Yes/No" buttons.  In either case, we want the buttons to close the overall dialog containing the panel.  Therefore we want to define the behavior of the buttons in the template as well.  Currently, UIML does not provide a way for an action in a behavior to affect something except by id, but in our template case, we have no way of knowing the id of the container.  We propose adding a method to parameterize the templates so that they can use placeholder id's in the behaviors and then map those id's to the actual sourcing id.  This would add a new level of flexibility to the template mechanism and has been requested by users of UIML in industry.

 

Issue 2 involves the deletion of template component from the sourcing document.  For example, suppose we wished to import a button panel that sometimes had three buttons ("OK", "Cancel", and "Apply") and sometimes only two ("OK" and "Cancel").  In this case, the third button is optional.  Currently we would have to define two separate templates to handle the two cases above, but it would provide better modularity and less redundancy to define one template with an optional part. 

 

Solutions to both of these issues will help to further enhance the descriptive and representational power of UIML.  We will discuss mechanisms for implementing them in the TC meeting today.

  

Accelerating Standardization:

 

Our TC charter needs to be revised to reflect the work we have done and any new directions we plan to follow.  The original charter is included below for reference.

 

#BEGIN CHARTER

The charter for this TC is as follows.

Name

User Interface Markup Language (UIML) Specification Technical Committee

Statement of Purpose

The purpose of the User Interface Markup Language (UIML) Specification Technical Committee is to develop a specification for an abstract meta-language that can provide a canonical XML representation of any user interface (UI). The language should be capable of specifying the requirements, design, and implementation of any UI.

The committee will use the UIML3 specification created by Virginia Tech's Center for Human Computer Interaction, Harmonia, Inc., and other organizations on uiml.org as a starting point [1]. The owners/creators of this specification claim no intellectual property with regard to UIML and will not seek licensing reparation for its use in this TC, nor will they seek ownership of any work produced by the TC.

The TC differs in scope from other committees and working groups that address concrete UI implementation languages (e.g., assembly language, C, C++, CSS, Java, HTML, VoiceXML, WML, XForms, XHTML, XSL-FO). Instead, this TC focuses on an abstract language, UIML, which expresses UIs at a higher level than the concrete languages. UIML's goal is to subsume in expressive power all concrete languages, and to permit efficient mapping from UIML to any concrete language.

The TC has a secondary purpose -- to use UIML to bridge UI-related fields:

• Techniques from the Human Computer Interaction field. These include UI models, transformational techniques, techniques for computer automation of UIs, usability engineering, generalization of the Model-View-Controller, and new UI metaphors.
• UI designers that want to think in terms of domain-specific abstractions (e.g., navigation maneuver for an automobile UI, material path for a factory automation UI), rather than at a widget level.
• UI designers that want a way to capture author intents and map UIs to different devices to create accessible UIs.
• Techniques to internationalize UIs. Techniques that help integrate UIs with Web Services (e.g., WSDL).

A general motivation for a canonical UI representation language is to accelerate the development of tools for UI development. If practitioners from these fields build tools with UIML, then the tools can interoperate. Just as XML made toolbuilders more efficient (because tools built for XML work for any XML vocabulary), so can UIML make UI toolbuilders more efficient (because tools built for UIML work for any vocabulary representing any concrete UI implementation language). Thus the TC's work will serve to assemble the jigsaw puzzle pieces of UI and HCI technology that have been created.

The TC will evaluate UIML3 and other UI initiatives to formulate a plan for creation of a specification, develop the specification, create compliance tests and implementations, and submit the specification to the OASIS membership for approval.

Relationship to Existing Activities:

Many efforts related to use of XML to describe UIs are underway throughout the industry. The following work may be relevant to this TC:

• Many W3C Working Groups and Activities, including Accessibility, CSS, Device Independence, Voice, XForms, XHTML
• Mozilla XUL
• OASIS HumanMarkup TC

List of Deliverables

• Assessment of how UIML fits other committees and working groups addressing user interfaces (projected for completion 90 days after first meeting)
• List of open issues in the UIML 3.0 specification (projected for completion 120 days after first meeting)
• Revised specification based on issues list (projected for completed 240 after first meeting)
• Implementations of the specification by different parties
• Compliance test suite
• Best implementation practices
• Revised Specification based on implementation experience

Optional deliverables

• Documents describing requirements for UIML
• Analysis of using UIML to make interfaces accessible
• Document giving UIML examples 

#END CHARTER 

Thank you!

James Helms

Director of Research and Development
Harmonia, Inc. 
P.O. Box 11282
Blacksburg, VA 24062

Office: (540) 951-5900 x 3
Cell: (540) 558-9722