Device Independent User Interfaces

Walter Dees
Philips Research Eindhoven
The Netherlands
walter.dees@philips.com


Abstract
Within Philips Research we are looking at how to create device independent user interfaces for interactive in-home network applications and all kinds of new broadband and wireless services. To achieve this, we use different approaches:

  1. Abstraction: using generalized user interface (UI) concepts within the UI definitions to handle for example different event mechanisms (e.g. touch-based input, speech, etc.)
  2. Prioritization: by using priorities in the UI definitions it becomes possible to leave out the least important UI elements on devices with small screens.
  3. Device capability profiles: matching the device capabilities against so-called multi-level stylesheets enables us to handle diversity in a broad and scalable manner.
Above methods can be used to cope with the complex issues at hand when dealing with the next generation of networked services, for which it becomes increasingly important to achieve device independence.

Introduction
As more and more devices (from high-end PCs to Bluetooth watches) get interconnected, to the internet as well as to each other, handling user interfaces on all these different devices becomes increasingly complex. Service providers, application developers, but also device manufacturers face a huge problem when dealing with interoperability between the enormous variety of devices, which can vary a lot in their display, interaction and processing capabilities. In addition, networked applications will provide more and more functionality, e.g. with the advent of broadband networks and Microsoft’s .NET [1]. So from static content and information exchange (such as web pages) on the Internet, networked applications will evolve into multi-functional highly interactive services, which will bring entertainment and new forms of communication and content exchange to people’s homes, inside their homes and when they are on the move, on a lot of different devices. Therefore, it becomes very important to be able to handle the user interfaces for all these kinds of applications in a device independent way. We will briefly discuss some mechanisms that could be used to achieve this in the remainder of the document.

Device independence
Several mechanisms could be used to achieve (more) device independence with respect to user interfaces, such as:

  1. Abstraction:
    By using abstract user interface definitions, which use general concepts that are common for all kinds of different devices and user interfaces, one can more easily reuse UI definitions amongst different devices. For example, to choose an option from an index is possible to do on devices ranging from high-end televisions to voice controlled gadgets.

  2. Prioritization:
    To handle different screen resolutions, it can be useful to specify a level of importance for each widget used in a UI definition. For example, if in the user interface both a "Sound Off" (i.e. "Mute"-) button and a slider for setting the volume exist, the "Sound Off"-button can be given a lower priority than the volume slider. This is because with a volume slider we can achieve the same effect, i.e. setting the volume to "0". Using this information, a client device which does not have enough space available on the screen to show all elements, can decide not to show this element.

  3. Device capability profiles and multi-level stylesheets:
    Above mechanisms (abstraction and prioritization) are probably not enough to accommodate for a wide variety of visualizations. Also, just using the same UI definition on a different device might not lead to the desired level of usability of the user interface. For example, resizing the fonts to fit on a small screen, might lead to unreadable and unusable user interfaces.

    A possible way of dealing with such visualization issues, is by using a description of the device’s (display-)capabilities [2]. In this way, client devices can be given individual rendering hints. Typically, however, a tailored style sheet needs to be made for every possible client device. This requires a big authoring effort if a lot of devices are involved. Also, when new devices will appear, new style sheets may need to be made. Therefore, it is better to put the style sheet information in some form of device capability hierarchy. We call this multi-level stylesheets.

    For example, suppose that we have graphics capabilities and sound capabilities as the two top classes of capabilities relevant for user interfaces. At that gfx-top level we can for example specify the colours and type of fonts which should be used on all devices which have graphical capabilities. On a level deeper we could for example specify different layout attributes for "portrait" and "landscape" oriented displays, and so on. In Figure 1 an example of such a hierarchy is given. On the right side the device capabilities are listed, and on the left side the style sheet information typically associated with these capabilities.

    Figure 1: example device hierarchy for multi-level stylesheets

    The information in the multi-level stylesheets can be matched against the capability profile of the device in question. This gives the benefit that style sheet information can be more easily reused on different devices. It is also not required for the application developer to specify style sheet information on all levels of the hierarchy, and still create a possibly acceptable user interface for devices which were not taken into consideration in the development track.

    Example
    In the following example we use some of the above techniques to achieve a completely different visualization of the same user interface definition, the results of which are shown in Figure 2.

    Consider the following user interface definition (using XML [3]). Inside the definition, visualization priorities have been specified (i.e. higher means more important). Also, associations have been made with the stylesheet(s) by means of the "class" attribute. 

    <?xml version="1.0"?>
<?xml-stylesheet href="stylesheet.uisl"?>
<ui>
   <container id="main">
      <container id="1" label="Sound settings" class="setting">
         <button id="2" label="Volume Off" class="setting" priority="0"/>
         <container id="3" label="Effects" class="setting" priority="2">
             <toggle id="4" label="Filter" class="effect">
                 <option id="f1" label="High pass" />
                 <option id="f2" label="Low pass" />
             </toggle>
             <entry id="5" label="Echo" defaultvalue="20"/>
             <button id="6" label="Dolby"/>
         </container>
         <toggle id="7" label="Speakers" class="setting" priority="5">
             <option id="s1" label="Right"/>
             <option id="s2" label="Left"/>
         </toggle>
         <range id="8" label="Volume" valuerange="100" priority="5"
                class="setting"/>
         <icon id="9" label="Speakers" class="setting" priority="0"/>
         <button id="10" label="exit" class="setting" priority="10"/>
     </container>
  </container>
</ui>

    If we then specify the following stylesheet for the highest level in the device capability hierarchy:

    <?xml version="1.0"?>
<!DOCTYPE uisl PUBLIC "-//PHILIPS//DTD UISL//EN" "uisl-level1.dtd">
<uisl level="1">
  <gfx>
     <general>
        <bgcolor>
            <container class="effect">dark</container>
        </bgcolor>
     </general>
     <landscape>		
        <layout>
           <container>paneltree</container>
        </layout>
        <level2 stylesheet="stylesheet-landscape.uisl"/>
          ..
     </landscape>
     <portrait>
        <layout>
           ..
        </layout>
        <level2 stylesheet="stylesheet-portrait.uisl"/>
     </portrait>
  </gfx>
</uisl>

    And inside the level 2 stylesheets (i.e. <level2>) we specify the relevant style sheet information for landscape resp. portrait oriented displays. Then we are able to create for example the following two visualizations of the same user interface definition:

       

    Figure 2: two possible visualizations of the same application

    Conclusions
    To achieve device independence with respect to user interfaces, we are looking into several different methods. Methods like device capability profiles and multi-level stylesheets, allow for interactive networked user interfaces to be made, which can be used on a variety of different devices, in an easy way. Therefore, they enable us to cope with the complex issues at hand when dealing with the upcoming generation of in-home and wireless/broadband networked services, for which device independence becomes increasingly important.

    References

    1. Microsoft Corporation, Microsoft .NET development resources, "http://www.msdn.microsoft.com/net/", 2001
    2. W3C World Wide Web Consortium, Composite Capabilities/PreferencesProfiles (CC/PP), "http://www.w3.org/Mobile/CCPP/", 1999-2001
    3. W3C World Wide Web Consortium, Extensible Markup Language (XML) 1.0, "http://www.w3.org/TR/1998/REC-xml-19980210/", 1998

    Contact information:

    Walter Dees
    Philips Research Laboratories
    Prof. Holstlaan 4
    5656 AA Eindhoven
    Building: WDC 3-050
    Phone: +31 40 2745438
    E-mail: walter.dees@philips.com