Annotating Content for
Device Feature Utilization
Alamgir Farouk,
Nokia Wireless Software Solutions
Boston, MA
01803
Email: alamgir.farouk@nokia.com
Hand held devices are evolving! Some might even say, it is chaotic. This situation is quite different from the desktop market place where the basic format of a computer display appears to be quite stable. The factors affecting this evolution are complex and hard to predict; and anyone involved in this area is probably aware of the challenges inherent in creating applications for such devices.
As a consequence of this 'chaos', application developers who are designing content and services for hand-held devices are left with rather harsh choices to make. On the one hand, they may attempt to address each individual handset type and customize the application so that it works very well on each device. Essentially this will mean one application per device type. On the other hand, the developer may chose the 'least common' feature set and write to that, so that the application works minimally on every type of device. This implies that the application will not be able to take advantage of features that are attractive and new but specific to a certain device type. The first choice, that of customizing to each device type, is not feasible. The second choice, ignoring device types completely, is not desirable either. In this paper, we propose a third choice which is a compromise that requires developer participation, but in reduced scale, which is more likely to be accepted practically.
The concept we are proposing is based on 'preparing for chaos' in advance but without attempting to predict it completely. In essence, the application developer or content generator will be aware of the possibility of different types of displays and other features on devices. However, instead of requiring a thoroghgoing classification of all devices, we use an approximate classification, and the content is 'annotated' with such 'classification annotations' (or meta-data). At run time, an intermediate agent may detect and determine the 'classification' of the device being used and 'adapt' the content for this device using the annotations embedded in the content.
In the following sections we provide some further details on this concept, its possible implementation challenges, the advantages to be gained, and the requirements for its success.
There is, of course, the possibility that standards will be established for devices and that everyone will follow them. Standardization, however, has its own pace of evolution and acceptance. To attempt to apply standards too early will definitely stifle evolution and the benefits that would be gained from it. More importantly, it is not possible to enforce standards when the market is not finished experimenting and improving because someone will design a solution that is so much better that no one will care about the standard. So, we assume for the purposes of this paper that standardizing hand-held devices to obviate the need for content adaptation is not a realistic solution yet, although it is possible in the near future.
Before we discuss generation of content which has some form of annotation regarding device features, we first need to define what device features mean, particularly in this context. Defining features and classifying devices according to these features is not a new idea. There has been a considerable amount of effort in the standards arena on this topic, the most relevant of which is the CC/PP (Composite Capability/Preference Profiles) standards proposal. It is our hope that we will be able to use such a standard for our purposes eventually. However, in this document, our focus is on the use of some such classification in content generation and the basic ideas will be equally applicable to either a standard classification (e.g., CC/PP) or our own, as described here .
For this document, we define the term Device Feature to include a wide and expandable list of characteristics of hand held devices, consisting primarily of display characteristics. For example, the screen size varies from device to device, as well as its resolution. If we now propose some basic discretization of the screen size continuum, we may come up with ranges of size and call them, for example, small, medium and large. Thus, we define screen size in terms of these discrete values rather than the absolute size. Just as the device may have 'soft-keys', it can also have a small, medium or large view area.
Some device features are quite intuitive and need no further explanation. For example, the ability to show color is quite self explanatory. However, some features require some effort to define and categorize: -for example, a scorllable square display and a non-scrollable 'portrait' display may have the same effective viewing area, but do we consider them to be identical feature-wise ? Is one more user friendly but bulky, while the other is more compact and less user friendly? Should our content generator/adapter differentiate between the two ?
Device features may also include characteristics such as voice recognition, flashing LED or other secondary form of display, voice output (which may augment the display), etc. Determining a list of possible features that satisfies everyone is difficult, so compromises have to be made. What we propose here is therefore tentative and subject to change.
For now we propose to recognize the following features:
1. Display density or resolution (e.g., number of lines, small, medium and large)
2. Display aspect ratio (portrait, landscape or square)
3. Display color capability (mono, gray, color)
4. Display graphics capability (pixel-wise access or predefined characters, Boolean)
This is a short list and just a starting point, but we hope it to be a sufficient test to see if the concept is acceptable or even practical.
Once possible device features are identified, any existing device may be classified according to these features, or to the lack of them as they case may be. For example, the Nokia 7110 has a small resolution, portrait, monochrome, graphics capable display, while the communicator Nokia 9110 has a medium resolution, landscape, color, graphics capable display.
If a new device is introduced, we attempt to classify it first according to the features defined, however, it is possible that it may have new features which are not in the current list. In that case, we introduce a new feature to our feature list (after some deliberation and study of course). Since the default of all features is their absence, there is no need to re-classify previous classifications. It should be pointed out that this classification works by assigning attributes to a device type with values which are mutually exclusive. However, the features themselves do not have to have to mutually exclusive. For example, a device can be color (color feature and large (size feature) but not large and small (two values of the size feature) at the same time.
The content generated by an application now needs to be annotated using the feature definitions described above. This annotation may be considered as meta-data embedded in the content. The concept is not dependent on any specific content type, but for illustration purposes we need to choose a mark-up language, WML in this case, and provide the examples using WML.
One possible means of annotating WML is to use an existing attribute and setting it to a value specific for a particular a particular wml element (or tag). For example, if there are six selection items in a 'card', the last three may be annotated for a 'portrait' type display, by adding the 'portrait' attribute to these elements (via the 'class' attribute already available in WML). Since such attributes are not recognized by browsers, this type of content is compatible with existing browsers, and should not cause problems to existing setups. However, we do not intend to send it to the browsers without further processing.
Example
(prolog omitted)
<wml>
< card id=card1>
<select
title="Selection">
<option class="DISPLAY_SMALL">
Option_1 </option>
<option class="DISPLAY_SMALL"> Option_2 </option>
<option class="DISPLAY_SMALL"> Option_3 </option>
<option class="DISPLAY_LARGE"> Option_4 </option>
<option class="DISPLAY_LARGE"> Option_5 </option>
<option class="DISPLAY_LARGE"> Option_6 </option>
</select>
</card>
</wml>
When this document is processed using a device specific filter (say, DISPLAY_SMALL only filter), it can strip out the elements which are annotated with DISPLAY_LARGE attributes, thereby effectively producing a different type of content based on the display type.
Note: We have used the 'class' attribute here, which is available for all wml tags, and is ignored by the browser. It is not certain that the 'class' attribute was meant to be used in this way, but so far we have seen no evidence to the contrary. However, in the event that this causes some conflict with existing conventions, we could find an alternative means of annotating the wml source. Since all such annotations will be stripped before the document is either encoded or sent to the browser, no browser or device incompatibilities will result.
At run time, a content adapter may modify the content by detecting the device type (user-agent), determining its recognized 'features' from a mapping, and acting upon the annotations embedded in the WML. Thus, if the device type is 'square', then the selection items previously marked for 'portrait' could be removed and a put in a separate card, while in the case of a landscape display they may be placed in a second column within the same card, to take advantage of the increased real-estate and obviate the need for the user to scroll down. Transformation will operate only on content with annotations, leaving unannotated content unchaged.
Referring back to our previous WML example, the examples show the transformations performed on that WML content bsed on the attribute values (DISPLAY_LARGE or DISPLAY_SMALL) as specified in the class attributes.
Transformed output for SMALL_DISPLAY device:
<wml>
< card id=card1>
<select
title="Selection">
<option> Option_1 </option>
<option> Option_2 </option>
<option> Option_3 </option>
</select>
</card>
</wml>
Transformed output for LARGE_DISPLAY device.
<wml>
< card id=card1>
<select title="Selection">
<option> Option_1 </option>
<option> Option_2 </option>
<option> Option_3 </option>
<option> Option_4 </option>
<option> Option_5 </option>
<option>
Option_6 </option>
</select>
</card>
</wml>
This example assumes that the 'options' are simply truncated. However, depending on the use case, the 'options' could be repackaged into a second card, and made available to the device so that they are compatible with the small display. The logic will depend on conventions we adopt or agree upon.
One easy way to implement these kind of transformations is to use an XSL processor and supply appropriate XSL transformations rules in the form of a stylesheet. However, any mechanism can be used for implementing such a transformation, the choice being influenced by other factors.
The proposed scheme described above is a cooperative system where the content generator, or application developer, and the service provider work together to provide a possible solution to the otherwise difficult problem of adapting content to specific devices. It does not require the application developer to track the features of newly available devices. Instead, we do this using a mapping to its device specific feature list. This list must be updated to take into account new devices, but since this is shared by the entire server network, it is much easier to maintain than the alternative of having every application update itself.
This scheme does not provide a perfect solution, but rather a feasible and approximate one. The benefits can be substantial, however. Applications can be developed for new features which are announced but not yet available. These applications will be fully backward compatible, and will be able to take advantage of new devices immediately when the are available. Thus, device manufacturers will have a higher assurance of their new devices being accepted or even desired, since they can now provide additional functionality in 'existing' applications. Additionally, application developers can concentrate on creating applications in the abstract but stable world of 'features' rather than the dynamic and possibly chaotic world of devices.
The success of such a system will depend on many factors, the most important of which will be the robustness of the feature classification that is proposed. Another important factor is cooperation between service providers and application developers. It is a dance of partnership, and both parties must agree that there are benefits to be gained, otherwise, it will not succeed. We welcome comments and criticisms of our ideas as described here, please contact the author with any feedback.