Adaptive Ajax Architecure for Mobile
By Rotan Hanrahan, Chief Innovations Architect, MobileAware.
The purpose of this short presentation is to alert the Ajax community to a new opportunity. By taking advantage of recent developments in delivery context metadata, new Ajax-based solutions can be developed that will optimise the end-user experience on a wide range of Web-enabled devices, including fixed, mobile, automotive and embedded.
The W3C and the OMA, and many representatives of the Web and Mobile industries, are developing a suite of technologies to anable access to both static and dynamic delivery context metadata. This information will be available at run-time to Ajax-enabled applications via standardised interfaces, giving them the opportunity to adapt to a variety of environments and changing conditions.
The combination of static and dynamic delivery context metadata with Ajax suggests a simple but interesting design architecture that is particularly useful for Ajax on the mobile Web, where contextual diversity is greatest.
This architecture will be called the Adaptive Ajax Architecture for Mobile, or AAA4M for short.
The completely expanded name would be: "Adaptive Asynchronous Javascript and eXtensible Markup Language Architecture for Mobile," which is a bit of a mouthful.
Several commercial companies and open source projects already use delivery context information to adapt content for the mobile Web. Typically, the solutions detect the type of browser from the HTTP request headers, infer the type of device upon which the browser is executing, and then look up a set of properties relating to the device (as recorded in a proprietary database).
The main adaptive techniques are well known, and have been documented by the W3C's Device Independence Working Group (now succeeded by the Ubiquitous Web Applications group). Each content adaptation solution will build upon the main techniques to provide enhanced and novel end-user experiences. In general, each solution will attempt to maximise the use of device-specific capabilities while working around various known device limitations.
Generally, the information held in the various proprietary databases, and in public repositories such as the open source WURFL, relate to browser presentation capabilities and limitations. It is possible for any of these technologies to be extended to cover additional non-presentation or non-browser information. It is also possible for this data to be used to adapt more than content.
One common Javascript technique is to execute a series of browser-specific methods until the identity of the browser is revealed, this fact is recorded in a global variable, and subsequent methods employ conditional statements based on this variable. The technique is sometimes called client-side browser sniffing.
This has certain obvious drawbacks:
If browser sniffing can be achieved at the server, it is possible to deliver tailored scripts to the browser. This avoids all of the aforementioned drawbacks.
It is even possible to use the server's device discovery capability to be very selective about the aggregation of script fragments as part of the tailoring process.
For example, the server may discover from its own repository of device information that the browser is running on a mobile device that has a touch sensitive screen but no keyboard. In this case, methods based on mouseover events would be avoided, and interactive data entry would concentrate on selection events rather than textual input.
Document construction via scripting presents another opportunity for contextual adaptation. In this situation, script uses information about the browser (and the device in which it executes) to modify how a document is rendered.
For example, some mobile devices contain an ambient light sensor with which it may be possible to determine if the device is being used in daylight, or at night in dark conditions. This information can be used to select an appropriate colour contrast for maximum visibility.
Further expanding on the previous example, it is possible to communicate ambient information via Ajax callbacks to the server, which in turn can tailor subsequent interaction and the behaviour of the application in general. Thus it would be possible from static delivery context data for the server to determine that the device can display in both portrait or landscape modes, and then deliver a script to the browser with which it can determine which of the two modes is currently in effect. This is especially useful in the rendering of tabular data.
While these possibilities for adaptive Ajax applications seem interesting and plausible, their widespread adoption is being hindered by the absense of standard means of accessing the delivery context. Fortunately, the W3C and OMA are working to address this shortcoming.
It is expected that in 2008 there will be a set of interoperable specifications that will define how both static and dynamic context metadata can be accessed. Commercial, free and open source projects are expected to make use of these new technologies. Ajax developers are strongly encouraged to take interest in this work, and participate where possible.
Three projects are of particular interest:
DCCI defines a platform and language neutral programing interface for Web applications to access dynamic properties (including device capabilities, configurations, user preferences and environmental conditions). As of July 2007, the specification has been published as a working draft, and it has already been demonstrated through prototyping.
The DCCI API can be exposed via Javascript, thus giving an Ajax method direct access to the dynamic device information.
The specification includes a worked example in Javascript where GPS data is retrieved from a GPS receiver in the device, and subsequently used to indicate the postal address of the person carrying the device. The example suggests that the postal address could be retrieved via a Web Service, passing the GPS coordinates as a parameter, though obviously this could also be achieved via an Ajax callback.
DCCI was published by the W3C's Ubiquitous Web Applications Working Group. The group is also responsible for a general purpose ontology of device/browser contextual information. It is hoped that many technologies in the field of Web adaptation will develop vocabularies to contribute to the growing ontology and in this way facilitate data interoperabilty between the various technologies.
The OMA Device Profile Evolution enabler is intended to provide a standard means of conveying dynamic device capability data to an application provider. This gives the server another means of tailoring the presentation it delivers to mobile devices.
The OMA is working with the W3C to ensure that device properties used in the DPE enabler will be compatible with the UWA ontology. Similarly, the OMA is contributing to the W3C's Device Description work to ensure that appropriate static device properties are represented in the W3C's core vocabulary.
The typical DPE enabler workflow involves the DPE client registering with the DPE server so that the server-side application can request property data from the client. The application can also set triggers on the client so that dynamic updates can be handled. Content requests and responses can be executed by any means, including HTTP, which provides an opportunity for combining Ajax techniques with DPE.
Within the W3C's Mobile Web Initiative is the Device Description Working Group, whose responsibility is the creation of a language-neutral API to access a repository of static device descriptions, for the purpose of facilitating Web content adaptation.
The group is creating a core vocabulary of essential device properties, to be part of the W3C UWA's delivery context ontology. Early drafts of the IDL-based specification of the DDR API are available for inspection. In early 2008, the group expects implementations to be available, both in public and incorporated into individual application solutions.
The DDWG is working in concert with the W3C UWA group, and the OMA DPE group, to ensure an interoperable solution.
The DDWG's Device Description Repository (DDR) is intended to be extensible, with additional standard and custom vocabularies. It is therefore possible to construct a standard repository that contains information about the operational characteristics of a device, including its scripting capabilities and limitations. With such information available, a server-side application can adapt its use of scripting according to known parameters.
A vocabulary of device/browser properties for Ajax applications has not (yet) been proposed. This would likely be out of scope for the W3C, but thanks to the planned extensibility of the DDR, other groups (such as the OpenAjax Alliance) are free to define new vocabularies, and to subsequently populate the repository with data from commercial or community sources.
The imminent availability of delivery context metadata through standardised interfaces presents us with a unique opportunity to realise an Adaptive Ajax Architecture for Mobile contexts. This AAA4M approach would involve the following components:
Like Ajax itself, AAA4M is a design pattern. When the various context technologies (such as DCCI, DDR and DPE) become widely available, AAA4M is likely to establish itself as a mainstream approach for mobile Web applications.
To illustrate AAA4M, here are a few simple deployments to consider.
In a server-side AAA4M solution, all of the application adaptation is achieved on the server. The approach will work in any scripted environment, including non-Ajax.
As this is a server-side only deployment, all of the contextual information is assumed to be static. The server may discover, for example, the size and resolution of the screen and the default orientation, but cannot discover if the screen orientation has been changed or if some of the available screen space has been occupied by other applications (e.g. a "soft keyboard").
Device recognition takes place when the browser makes a request to the server. The HTTP headers are the most obvious source of clues as to the identity of the browser, and generally also suggest the physical environment in which the browser is executing. This is not a foolproof mechanism given that some browsers will masquerade as others, and some browsers reveal nothing about their execution environment.
Fortunately, experience from content adaptation solutions shows that the majority of contexts can be determined from the HTTP headers, so this is generally a good way to proceed.
Based on the browser and device that has been recognised, the server brings together a set of scripts. This could involve a list of JS files, which will be linked into the delivered page, or could be a dynamically constructed set of Javascript definitions that are placed into a session-based script, or embedded into the delivered page.
Once all the scripts have been identified and aggregated, they are delivered to the client along with the main page. The delivered methods may be accompanied by a set of data describing the target device (e.g. supported image formats) so that the scripts can execute in a contextually sensitive manner.
In this client-side AAA4M solution, all of the adaptation takes place on the client. The DDR may still be accessed through Ajax callbacks to the server (where there is a link to the DDR), but the scripts now also have access to client-side dynamic information.
The first stage of the application involves the discovery of client-side access to dynamic contextual information. A simple attempt to bind to either a DCCI interface or a DPE interface will suffice.
Both of these interfaces should reveal the supported vocabulary, thus indicating the range of dynamic properties that may be interrogated.
Based on the set of available dynamic properties, the initial script can now retrieve additional property-specific methods. For example, if the DCCI interface supports access to a gravity-based orientation sensor, then the initialiser can retrieve a special hander script to deal with changes in orientation, and bind the handler to the appropriate orientation event.
There are two ways in which the initialiser can retrieve additional support scripts:
The initialiser has a list of scripts/methods associated with the various DCCI/DPE properties and it iterates over these. As support for each property is discovered, the corresponding script is loaded. Alternatively, the scripts are noted during the iteration, and then loaded en masse at the end.
The initialiser identifies classes of support (e.g. support for input modalities) and loads separate scripts that further refine the interrogation of the client-side vocabulary. In this way the support scripts are loaded in a chain.
The hybrid approach is an AAA4M pattern that employs both server-side and client-side adaptation. There is a discovery phase at the beginning where, in addition to the normal static properties, the server can determine if the client supports DCCI and/or DPE.
The server should then know, via information stored in its DDR, that the client provides access to a particular set of dynamic properties. With this knowledge, the scripts delivered to the client are tailored to take advantage of such information.
Because all of the delivery context technologies have adopted a common ontology, it is possible to mix data from one source with data from another. For example, the representation of screen resolution will be compatible across the DDR, DCCI and DPE, enabling the correct sizing of images. The DDR would indicate the maximum size needed (un-zoomed), while DCCI/DPE could provide information to scale the image down if less than the full screen is available. As such operations would probably share information; the use of a common ontology ensures no loss in translation.
The Ajax design pattern has provided an astounding degree of interactivity, flexibility and responsiveness to the Web. The impact of Ajax has been felt mainly in the fixed Web, where desktop browsers dominate.
Desktop browsers have many subtle, and some not-so-subtle, differences. This includes their support for scripting, which has an impact on Ajax. In most cases, however, some simple browser sniffing and conditional logic in the scripts enables Ajax to function across most desktop browsers.
The same cannot be said of browsing on mobile devices. In this environment, diversity is significantly greater. With the aid of advanced content adaptation technologies, this diversity has become an opportunity, where once it was solely an unwelcome challenge.
New standardised interfaces to delivery context metadata will enable adaptation to extend beyond content, where it has been successful to date. Ajax solutions can include delivery context metadata as a means of adapting the scripts and their behaviour.
By taking advantage of DCCI, the DDR API and OMA DPE, we can create a new Adaptive Ajax Architecture for Mobile:
"AAA4M"
On-line References
(c) Rotan Hanrahan, 2007.