Re: Definition of adaptation policy

Hi Jose,

You mention that MyMobileWeb is using CSS for mapping between the 
abstract and concrete UI layers, and I wonder whether you have used 
CSS3's UI module?

The draft CSS3 UI module has been in CR since May 2004 and covers 
the rendering of HTML4 form fields and XForms UI elements as radio 
buttons, checkboxes, menu items, menubars, tabs, pull down menus 
etc. See

   http://www.w3.org/TR/css3-ui/

However, as far as I know, there has been little implementation 
support for this from both browser and authoring tool vendors. The 
key section is section 5 "System Appearance", see:

   http://www.w3.org/TR/css3-ui/#system

It has a large set of controls, but lacks sliders and spin controls, 
and as such isn't comprehensive. The WhatWG and HTML5 includes 
proposals for some of these, but I don't know whether the browser 
vendors intend to implement the CSS3 UI features or whether the 
module will require a major rewrite.

CSS relies on the structure in the markup it applies to, although 
you can move things around using CSS positioning.

From the perspective of a declarative authoring framework, it would 
be easier to have a pure XML representation, rather than having to 
deal with the CSS selector syntax and the associated precedence 
rules. CSS currently has deficiencies when it comes to layout, and 
this has resulted in a rich set of workarounds. Newer mechanisms are 
being proposed, but these will only add to the complexity of CSS and 
the pitfalls for unwary or inexperienced authors.

It therefore seems interesting to explore the use of XML for the 
concrete UI layer. There are several examples of such markup we 
could look at, e.g. XUL and the following gives illustrated examples 
of the different kinds of widgets available in XUL:

  http://www.mozilla.org/docs/xul/xulnotes/xulnote_cheatsheet.html

In addition to widgets, there is a notion of layout, with 
hierarchically arranged layout managers, and a combination of 
outside-in and inside-out constraints. On a mobile device, where it 
is awkward or impossible to scroll horizontall, the usable width of 
the screen forms an outside-in constraint. By way of contrast, the 
minimum readable width of a graphic, or the width of a word might be 
examples of inside-out constraints.

The physical realization of a concrete UI generally involves the 
notion of "skinning" the UI where the positions, appearance and 
behaviors of the concrete UI elements are applied. This process 
builds upon the basic layout assumed by the concrete UI itself. 
Coming back to XUL as an example, XUL makes use of CSS, graphics and 
JavaScript for defining skins, see:

  http://developer.mozilla.org/en/docs/A_XUL_Bestiary#XUL_Parts

I am not suggesting that we standardize XUL, but it is useful to be 
able to refer to concrete examples for concrete UI markup languages, 
especially ones that are widely deployed.

I would very much like to get the sense of the UWA working group for 
what people do want to standardize when it comes to a layered 
architecture for authoring web applications. Do we want to 
standardize markup for the concrete UI layer, or do we want to leave 
this to CSS?  Do we care about the problems that arise when markup 
languages mix layers? How can we move beyond XForms for more 
flexible descriptions of application behavior involving explicit 
task models?

p.s. XBL provides yet another way to bind abstract UI markup to a 
concrete realization, but would still benefit from a standard for 
concrete UI as otherwise you are stuck with rolling your own, e.g. 
in SVG, or using a proprietary solution.

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

On Mon, 8 Oct 2007, José Manuel Cantera Fonseca wrote:

> Hi,
>
> Good point. I think that we are going to need to think in different kind of 
> policies suitable for different delivery contexts:
>
> + Pagination policies
> + Layout policies
> + Rendering policies (i.e. the mapping between the abstract and concrete UI)
> + Content selection policies, i.e . how do you guide a content selection 
> process in order to select the most appropiate content under certain 
> circumstances.
> + Style policies i.e. how the look and feel of your application might change 
> depending on different delivery contexts
> + Interaction policies i.e. how the user interface and the input methods 
> might change depending on the available modes of interaction
>
> Currently in the MyMobileWeb project we implement policies as a CSS 
> properties and redefining CSSs for different delivery contexts. We do not use 
> XSLT
>
> Best Regards
>
> Dave Raggett escribió:
>> On a different point, I was wondering about adaptation policies for mapping 
>> from the abstract UI layer to the concrete UI layer.
>> 
>> One idea that I believe Rhys floated was to extend DIAL with new markup for 
>> concrete UI constructs, e.g. panels, radio buttons, tabbed controls, 
>> sliders and the like.
>> 
>> Authoring at such a level would still be a nuisance as you would have to 
>> deal with the mixing of different levels of abstraction. It would therefore 
>> seem like a good idea to explore how adaptation policies can map between 
>> levels of abstraction in a way that simplifies the author's task by keeping 
>> the layers separated.
>> 
>> XSLT offers one such route e.g. when combined with the XPath access 
>> functions for the delivery context. Have you explored using XSLT as a means 
>> to translate between levels of abstraction, and if so could you please 
>> offer us comments on your experience?
>> 
>> I am also interested in going beyond XPath's simple declarative event 
>> handlers to a richer description of application behavior that takes into 
>> account an explicit model of application tasks. SCXML seems very promising, 
>> and I am looking for reports on work on using XML for dialogue modeling as 
>> part of layered descriptions of UI.
>> 
>> p.s. this is all stuff we need to cover in the wiki.
>> 
>> Cheers,
>>
>>  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>> 
>> 
>
>
>
>