Authors:
Guido Grassel, Nokia Research Center, Helsinki (Finland)
email: guido.grassel@nokia.com
mobile: +358 40 7499206
St=E9phane Coulombe, Nokia Research Center, Dallas TX (USA)
email:
stephane.coulombe@nokia.com phone: +1 972 894 5488
This position paper focuses on device independent content authoring and multimedia WAP phones. We give requirements on device independent content authoring and also requirements on the mechanism that should be used to generate content that is suitable for this category of devices.
=A major strength of mobile phones is that they are always with their owner, the phone provides instant access to timely and up-to-date information. Also, users regard their mobile phone as a personal trusted device. Therefore, applications that people want to use from their phones often provide timely and up-to-date information that is highly personalized. The time the user wants to spent on a site will typically not be more than seconds or few minutes. These criteria need to be considered when deciding whether it makes sense to support mobile phones in a new application. In short, there are some applications that only make sense on a mobile phone, and there are other applications that do not make sense on a phone at all (and many more applications somewhere in the middle).
A mobile phone is supposed to be light and fit into any pocket. The resulting small form factor restricts the size of the display and the of number of keys on the keypad. For instance, the display of the Nokia WAP phones, the Nokia 6200 series, displays one line for the heading of the WML card plus four lines of text, and one extra line is used to label two softkeys. Scrolling up and down can be used for longer cards. When filling-in forms the user will have to manage with the phone keypad. Hence, an application should neither require frequent nor long text input.
The download speed over the mobile access network can vary significantly. The bitrate of normal GSM data connections is up to 14400bps, High Speed Circuit Switched Data (HSCSD) can go up to around 40kbps (depending on the number of parallel channels used and network conditions). However in practice, high error rates and long round-trip delays reduce the actual bandwidth available for downloads even further.
When combining the differing device capabilities and the requirements of what is an interesting application for the mobile phone environment we conclude that many application will need to be re-designed entirely when porting them from the Internet-PC domain to the mobile phone domain. For instance, it is not enough to convert formats and to tweak the layout to obtain a suitable mobile phone application from an Internet-PC version.
WML is the mark-up and WMLScript is the scripting language defined by WAP. Hence WML and WMLScript is the type of content that needs to be sent to these device. We will call this content final format content in this paper. When a device independent format is used for authoring that format needs to be translated into the WML and WMLScript. The final format content needs to be efficient and needs to make full use of WML and WMLScript features. This does not come easy because WML and WMLScript differ significantly from for instance HTML and JavaScript. Hence the format used for device independent authoring needs to be expressive enough.
WML and WMLScript will evolve and get more feature rich over time to support new categories of phones. The author believes that it would be benefitial if WML and XHTML would eventually merge into one mark-up language. XHTML allows that different categories of devices support different profiles of XHTML. Since WML has some features that can not be found in XHTML the author expects that one or several XHTML modules specially for mobile multimedia phones would be needed. As a conclusion, the requirements on device independent authoring essentually remain the same.
Another point regarding device independent authoring and evolution of WML/WMLScript that we believe is important is that an application should ensure backward compatibility to older versions. This leads to the requirement to generate content according to multiple (older and current) WAP versions.
Device independent authoring must also consider inline media content such as images and graphics. In the final format content, hyperlinks need to refer to suitable versions of the media content. Generating image content suitable for mobile phones includes some of the following operations and others: scaling, croping, color conversion, format conversion, reduction in file size (i.e. reduction in image quality). Hence, device independent authoring needs to define which version of the content to choose for which final content format. Ideally, device independent authoring also gives support for creating various versions of media content for the targeted devices.
=For the mobile phone environment, the process that creates final format content should be located to a large extend on the server side (i.e. not on the phone). We speculate, however, that the phone will play some role in this process as well. For instance the phone might adapt the presentation style as needed.
To generate correct final format content, information on the characteristics and capabilities of the phone and of the network is needed. From our experience, the relevant parameters to describe the capabilities and characteristics of a mobile phone are as follows:
Which parameters are really relevant depends on the concrete= application.
Agreement on a core set of parameters is required that an application= developer can assume to be available. Definition of this core set must be precise enough to ensure interoperability. The definition of parameters must be extensible to meet the needs of different devices, manufactures and applications.
Furthermore, definition is needed how the application obtains device and network capabilities and characteristic parameters. We could imagine an extension to the Java Servlet API and/or similar APIs of other application server products for this purpose. For use in XSLT scripts an XSLT engine could make these parameters available as well.
How an application uses the parameters does not need to be defined, this can be left to the application.
Another question is how the application server obtains device profiles. This problem can either be solved locally on the application server for instance by maintaining a device profile database. The more flexible and technically more elegant solution is to have the phone send its own device profile to the server.
WAP UAProf defines both the mechanism of interchange as well as a set of descriptors. The idea is that UAProf is mapped to W3C CC/PP for use with over the Internet (e.g. over HTTP). The author believes that UAProf and CC/PP will be helpful in the future for two purposes: (a) sending device and network characteristics paramerters from the mobile phone to the application server and (b) downloading the device capability parameters e.g. from the Web site of the device manufacterer to the application server. To make UAProf and CC/PP fully interoperable a core set of descriptors need to defined in detail. The arguments are the same as in section 5.
How to use device profiles to obtain final format content should be left to the application. Mechanisms for content negotiation should not be defined. This is an area where products should compete for the best solution.
Multimedia Mobile WAP phones require special attention when aiming to support also this category of devices in an application. It is not enough to convert formats to WAP and to tweak the page layout to get a good mobile phone application. First of all, it needs to be decided if the user will actually be interested to use this application while he is on the move. Secondly, the structure of the application needs to be modified so that pages are small enough to fit the display and users will manage to get their job done quickly.
For mobile phones, the process to obtain final format content must reside on the server side. Device and network capabilities and characteristics are essential parameters to be used in this process. It is enough if we agree on the definition of a core set of these descriptors and on the mechanisms of interchange from the phone to the application residing on the server.