[humanmarkup-comment] Fwd: [uiml-discuss] academic perspective on UIML

[Rex Brooks <rexb@starbourne.com>]

Hi Folks,

I am passing this along because it highlights some considerations
early in the message that has general applicability to our effort.
The low-threshold, low complexity nature of superficial preferential
information our specification can provide COULD make it widely used.
This widespread adoption will use a very low percentage of the total
features set, IF we can get industry to perceive THAT out of the
background of misinformation which could occur once our specification
begins to make the rounds for approval. (We still have the
mischaracterized journalism in the press section of our website.)

The Primary Base Schema does not contain any controversial elements
and should not create the kind of perception I fear, (I hope
needlessly), but it won't hurt to be careful now. This is just a word
to the wise.

The message below is very well drawn. We are providing the tools for
model-type applications. That was why I was originally drawn to the
Web Services TCs, because they were initially aimed at the
Model-View-Controller architecture which may yet resurface in v.
1.1-2.0, but does not look like it is going to be a part of v. 1.0
Sigh. I now wish I had the time to play with the UIML effort since it
looks like they will be reviewing their spec and submitting it for
standard status.

Ciao,
Rex



>Date: Wed, 16 Oct 2002 09:12:21 -0400
>From: "Manuel A. Pérez-Quiñones" <perez@cs.vt.edu>
>Subject: [uiml-discuss] academic perspective on UIML
>To: uiml-discuss@lists.oasis-open.org
>
>
>I have followed the discussion on UIML on the sidelines. I figure I
>put  my two cents worth on it, from an academic/research point of
>view.
>Here it goes.
>
>UIML shares some common aspects with some earlier research on model
>based tools. It might be premature, however, to discount UIML's
>contribution to UI research and development on the basis of the lack
>of  acceptance of these earlier models.  A brief look at the history
>of UI  research explains the difference.
>
>According to Myers, Hudson and Pausch [1], user interface tools that
>have made an impact share the following characteristics (among
>others  mentioned in the paper): low threshold, high ceiling, and
>predictability.  Model-based tools failed, according to the authors,
>because they had high threshold, low ceiling, and were
>"unpredictable".  The high threshold was because it often required
>the developer to  learned specialized languages. The low ceiling was
>because many of  these tools worked for only a class of user
>interface applications, so  developers quickly ran into the
>limitations of the tools.  Finally, the  unpredictability of many of
>these tools was due in part to their  approach. All or most of the
>model based user interface tools applied  sophisticated artificial
>intelligence algorithms to generate their  interface. As a result it
>was difficult for the developer to know what  to modify in the high
>level notation to produce a desired change.
>
>UIML, while similar in nature to some of the model-based tools, has
>a  few new twists that make it interesting from a UI research and
>development point of view. First, the language is designed to be
>used  for multiple platforms and family of devices. This is done
>without  attempting to define a common subset or common denominator
>of the  functionality. Instead UIML uses generic vocabulary and
>other  techniques to produce the interfaces for the different
>platforms (some  of these are still at the research stage).  The
>advantage of this  approach is that while developers will still need
>to learn a new  language (namely, UIML), this new language is all
>they would need to  develop for multiple platforms.  This helps
>lower the threshold of  using UIML. Also, because UIML provides
>mapping to the platform's  toolkit, UIML in and of itself does not
>restrict the type of  applications that can be developed for the
>different platforms.  Therefore, UIML should have a high ceiling.
>Finally, predictability is  not an issue because UIML does not use
>sophisticated artificial  intelligence algorithms to generate
>interfaces, it simply relies on a  set of transformations (taking
>advantage of its XML representation)  that produce the resulting
>interface. For the developer, it is clear  what part of the UIML
>specification was used to generate the resulting  interface.
>
>Uses of UIML in my research
>I have several students doing research in user interface tools that
>are  related to UIML.  One student, Mir Farooq Ali, is defining a
>task  representation model that can serve as the initial starting
>point for  UI development for multiple platforms. This
>representation is used to  generate Generic UIML for different
>platforms. The representation and  its use present us with many
>interesting challenges of the usability  engineering process used to
>build multi-platform projects. For example,  many usability
>engineering methodologies start with screen sketches  very early in
>the development cycle. These are used for some of the  early
>usability evaluation techniques. However, screen sketches are not
>appropriate when you are dealing with very different platforms such
>as  desktop, pda and voice. Can we define some usability evaluation
>techniques that can be used with a task-based representation for
>building multiplatform interfaces, that does not rely on screen
>sketches? Can developers use this higher level, task-based
>representation to generate UIML and produce "good" interfaces?
>
>A second project involves the development of an integrated
>development  environment to be used with UIML.  In our work, this
>transformation-based IDE (or TIDE), has support for specification in
>a  high level language (see previous paragraph)  and generation of
>UIML-based interfaces for multiple platforms.. What sets this
>environment aside from others is that the developer is shown the
>relationships between the high level code and the generated code,
>thus  allowing the user to see what needs to be modified in the high
>level  specification to produced the desired change on the generated
>interface. This is done by selecting parts of the high level
>specification and seeing the generated portions of the interface.
>But  more importantly, the developer is also allowed to select a
>generated  "part" and the related UIML and task-description is
>highlighted.
>
>It will be interesting to see what comes out of the discussions
>here.  The idea of exploring how to combine UIML with XEvents and
>other  technologies is interesting.  It would continue to support
>multiple-platform specifications and development, while lowering
>even  further the "entry cost" (threshold) of the UIML language.
>
>
>1. B. Myers, S. E. Hudson, R. Pausch, "Past, Present and Future of
>User  Interface Software Tools" ACM TOCHI V7, N1, March 2000, pp
>3-28.
>
>-M
>------------------------------------------------------------------------
>-------
>Manuel A. Perez-Quinones, DSc. Email:perez@cs.vt.edu
>Web:www.cs.vt.edu/~perez
>Dept. Computer Science, Virginia Tech, Blacksburg VA  24061-0106
>Office (McB621) Ph: (540)231-2646, Dept: (540)231-6931, Fax:  (540)231-6075


--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com