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:
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 . 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.
Several mechanisms could be used to achieve (more) device independence with respect to user interfaces, such as:
A possible way of dealing with such visualization issues, is by using a description of the device’s (display-)capabilities . 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.
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 ). 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
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.
Philips Research Laboratories
Prof. Holstlaan 4
5656 AA Eindhoven
Building: WDC 3-050
Phone: +31 40 2745438