It is obvious to anyone holding a mobile device in one hand and the Web in another that the potential in making one available to the other (and vice-versa) can barely be imagined. However, it will also be clear to anyone with any mobile device and subscription that that promise is one that has yet to be fulfilled. This paper briefly touches on a number of issues that I believe to be currently standing in the way of fuller cross-pollination between the Web and mobile technologies.
About Expway:Expway is a company with an initial background in Audio/Video metadata. Over the years it has applied its experience gained there to other fields, the most relevant to this workshop being binary XML and EPG/ESG (Electronic Program/Service Guide) applications. Expway participates actively to the XBC, SVG, and CDF (when it'll be there) WGs, as well as in various industry fora such as MPEG, DVB, TV-Anytime, and 3GPP.
As a content and service provider our experience has been mostly in the development of programs to access Electronic Guides and various types of audio/video metadata. In doing so we have found that the hardest part of such projects was the creation of user interfaces that were at once appealing, usable, portable, and supportive of the required functionality, as well as well integrated (or at least integratable) into the surrounding information ecosystem (which for us is heavily based on XML and Web technologies).
Problems pertaining to usability are mostly independent from the technologies being used, though scalable formats do help to a degree in adapting UIs to the variety of screen size ratios. Generally they boil down to the ways in which one may expose the desired functionality within the bounds of a small screen, and be friendly to users that for the most part do not have pointer devices. The experience that was gathered over the years in designing UIs for fixed devices has not yet found its equivalent for the mobile world. It could be that the acquisition of such experience may be sped up if the industry were to work together on the creation of best practices documents.
Regarding the ability to create appealing and portable UIs that integrate well with XML and Web technologies, after having reviewed a number of options our current preferred solution is SVG Tiny, and the arrival of APIs such as JSR-226 to integrate it further into the devices' OS strengthens that choice. That being said, we regularly need to emulate functionality that would be readily available using XHTML or a small subset of XForms. As such, we would be much enthused to see the arrival of a standard combination of at least these three. This would however require some work, notably on the XForms side since its "Basic" profile is already hard to implement on mobile devices, not to mention it being combined with other vocabularies.
The Use Cases for the Web on mobile devices cover almost the entirety of those that apply to fixed devices — with the possible exception of the more complex uses — and add to those needs specific to mobility. A prime example of such needs is location-based services: one is rarely lost in a city looking for a friendly bar while carrying one's desktop computer, but in such situations one is likely to be carrying a mobile phone. Location-based services are currently heavily underused despite the fact that they could easily provide a killer-app for mobile users. It may be that what is missing in this area is a standard way of integrating location information into existing Web technologies.
Similarly, despite their limited textual input abilities mobile devices could constitute very powerful data gathering apparels. Voice notes, pictures, location information — a wealth of new applications could be built atop these capacities that are not as readily available to, or useful on, fixed devices.
The two most frequently cited differences are screen size and input methods, and while these certainly influence the user's experience they may not be the most useful aspects to look at. In fact, considering these limitations first is part of the problem more than the solution: altogether too often we look at mobile devices as "limited" or "constrained" devices when it might be far more productive to look at them from a different angle. Indeed, in many ways they present solid advantages over their Personal Computer ancestors. You can keep them around at all times, take pictures with them, talk into them in ways that are far less frustrating than desktop or laptop computers. There is evident value in making what is available to fixed devices present on mobiles as well, but this shouldn't come to the detriment of putting those devices' specific advantages to use, something we feel is altogether too often a limitation of many vendors' approaches.
Another major difference that is rarely touched on is that the vast majority of connected mobile devices are currently heavily phone-orientated, which is a starting-point very different from that of other end-user computers. Two things can be done about this fact. One is to try to eliminate it, effectively creating a type of PDA that you happen to be able to plug a headset into. This alleviates the design constraints on the device and is a path that is being attempted by some constructors. Another is to use it as an advantage in order to develop new voice-based interfaces. It is surprising that little has been done based on this latter approach, despite the fact that the mobile user's experience is often primarily vocal.
Overall, the different experience that is the mobile one is only a problem if we attempt to constrain it (eg to a phone with some extras) or work against its specificities (eg by trying to get concepts from a desktop OS onto it).
Despite recent improvements, the "Desktop Web" experience can barely be called seamless, uncomplicated, and reliable. When it is, it happens thanks to massive amounts of heuristics and processing power thrown at the problem of broken content, a strategy not readily portable to devices with less processing power.
Making the "Mobile Web" experience seamless, uncomplicated, and reliable would require content producers to provide content that is more standards-based so that more of the devices' power could be used for rich UIs and interesting applications. This of course brings about the problem that existing Web content producers will not take mobile users into account before a given critical mass is reached, while at the same time that critical mass will not happen while the content remains as dreadfully insufficient as it is today in most countries. This leads us directly into the next question.
There are two ways in which mobile-available Web content can be made desirable to mobile users. One is to bring the Web to mobile devices, and hope that the mass of content available there will be sufficiently appealing. While this is certainly desirable, it is a path that is fraught with technical issues, and may not eventually be the most appealing one to end-users in short term. For entire classes of content (eg text-intensive resources) one, given a choice, is likely to prefer accessing them on a larger screen than available to mobiles. That is to say, if the content is the same there will be only marginal incentive to access it using a mobile device.
Another approach is to take the specificities of mobile devices into account, and produce content that, while it will be equally available to desktops, will be more useful to mobile users. Examples of such content include location-based services (I'm lost and hungry, give me a map of where I am and a list of Mongolian restaurants close-by), survival-based services (it's 11PM, what subways can I take to get as close as possible to Shinjuku), or data acquisition services (how can I recommend this smoky dive I just scouted to my beer buddies). In the end, it is not so much about bringing the horse to water than it is about making it thirsty. I may eventually get used to doing Le Monde's crosswords on my mobile device instead of on paper, but that won't be before I've become enticed into using it for reasons exclusive to that class of device.
But before that becomes possible, the "Mobile Web" must become a platform in its own right that authors can reliably write content to without having to target specific devices or operators. This alone will make it desirable for content providers — especially non-professional ones — to produce mobile-accessible content.
There are two possible kinds of fragmentation: content-based fragmentation, and technological fragmentation. The former happens when a given kind of content is more or solely appropriate for a given use, and is by and large not a problem: one does not expect Chinese content to be read by non-sinophones, equally one does not expect a desktop to want to scan bar-codes in a supermarket to know if the same product is cheaper elsewhere. Technological fragmentation on the other hand is a more serious problem, part of a larger set of axes:
There is no ideal solution to the above set of tensions, but there may be a way to partition the problem-space so as to provide technological continuity over the gradient of device capacities and uses in such a way as to favour the development of the Web as the all-encompassing platform that it should be.
First, stop "down-profiling" technologies. It may be just a naming issue, but names reflect intent. One shouldn't have "Foo" and "Foo Basic", "Foo Tiny", or "Foo Lite". If the core technology doesn't work on mobile devices, then it's bloated. This doesn't mean that all the complex and, ultimately, fun and innovative features found in such languages as SVG or XForms must be eliminated. They correspond to the needs of real users that shouldn't be excluded. But the norm, or at least the baseline, for these technologies should be what is available to the greater number. Currently, content creators are asked to downgrade their content to be available to all, when the brunt of extra work and complexity should be carried by those that have advanced needs — especially so as they are the users with the best ability to develop or install more advanced software. For the current spectrum of W3C technologies we would thus have on one hand "Foo Core" technologies, able not only to be implemented and used on mobile devices but that in unison with other "Core" technologies, and on the other hand a variety of "Foo Advanced" technologies that would build atop the core ones. There would indeed be fragmentation at the advanced side, but it would be situated where people are able and motivated to deal with it.
This could lead us to a gradient of technological levels. I do not mean to imply that the gradient below is the best or only option, but it has a general shape that appears to be practical to me in resolving the tensions between the various axes along which technology can be specified. Implementation details are left as an exercise to the Web community at large.
The Web community has recently been through fits of tension between various W3C working groups, between the latter and initiatives such as the WHAT WG, or in debates that surrounded the creation of the CDF and WebApp WG/Activity. In hindsight it appears that the blame for these commonly unconstructive behaviours is distributed amongst players — equally or not is not the question. One thing that we can learn from these tensions is that none of the entrenched positions will convince any of the others, and that by sticking to them we are only adding further fragmentation and delaying a viable Web encompassing more than one class of devices. This outline is an imperfect attempt at burying the hatchet and inviting discussion towards reaching a middle ground acceptable to all parties.
It is a simple fact that the vast majority of content creators work based on implementations and not on specifications — likewise tool-makers, who are only indirect content creators. Content compliance therefore stems directly from implementation conformance.
It has been mentioned on several occasions that conformance certification would be a way to make user-agents more standards-compliant, at least on mobile devices. This is an avenue of thought that needs to be re-explored in the light of a new situation that is different from that that existed when the W3C was created. It may be that today's user-agent makers are not as reticent to certification as the tagsoup eaters of olde were. Certification, of course, requires fairly heavy resources if only in the creation of complete and coherent test suites, and would pose problems in terms of possibly excluding Open Source implementations, of who gets to validate test suites, or faced with inconsistencies in specifications who gets to decide how they are resolved. If sufficient interest can be demonstrated, it would be desirable for the W3C to make a decision as to how certification of compliance to Web technologies can be carried out, whether within its bounds (and perhaps only for technologies for which there is consensus to do so) or in a separate organisation that would nevertheless need to have very strong links to the Consortium.
Testing as a whole will simply never go away, but by enforcing stronger conformance — possibly through certification — it could be alleviated. The current W3C process is insufficiently strict on testing and in fact Working Group resources tend to suddenly thin as test production starts to loom on the horizon. If certification is eventually not retained as an option, the process needs to be strengthened to enforce the production of tests in a far more stringent fashion.
Discoverability on the Web currently happens through search engines, which are very biased towards textual content: audio, video, multimedia content in general, and services are poorly discoverable. Such problems are not exclusive to the Web however. For instance, the television industry, faced with a sharp increase in the number of available channels — and, hopefully, services — have needed to create technology in order to provide electronic guides to users.
It would be strongly desirable for the Web community to coordinate with other players that have encountered this problem already in order to converge towards a common solution. Current standards such as TV-Anytime provide first building bricks that could be further Webized (TVA is already XML based, which helps) in order to integrate them with Web technologies such as RDF and enable the production of such metadata in a distributed manner.
In terms of higher-level technology, a lot of what is needed is already present, but needs to be far more integrated, as well as trimmed down in some cases. As such, the work being started in the CDF WG is encouraging but needs to be maintained under pressure in order to produce results in a timely manner. Also, it would desirable for it to be more ambitious in practice than its charter indicates and for it to pay special attention to satisfying both "evolutionary" and "revolutionary" requirements.
In terms of data and interfaces there is a need for more than what is currently available. Common access to location information, and common ways in which mobile applications can manipulate Web content are required. Convergence of electronic guides technology with what has been developed for AV content is strongly desirable.
Finally, at the infrastructural level it is likely that the volume and complexity of information will require a common standard for binary XML, as currently being investigated by the XBC WG.
In theory, there is no such thing as the Mobile Web. Any notion of a "Foo-specific Web" is dubious at best, and very likely an oxymoron in the end. The Web is meant to be fully inclusive, and being specialized to any device class, industry, country, language, or usage is antithetic to its very essence.
That having been said, the following propositions need to be considered:
In his thought-provoking essay Is There An Artificial God? Douglas Adams makes a good case for using such fictions as dragons or money, irrespective of whether we believe in their existence or not, to better understand and manipulate the world in which we live. And indeed, the Mobile Web may be a useful fictitious entity to believe in for a while. This is the approach that I have chosen to follow throughout this paper, in order to take a closer look at specific advantages and disadvantages of mobile devices. It doesn't provide a conceptual architecture — which should be no different from that of the simple, unadulterated World Wide Web — but hopefully contributes a little to the definition of both the problem and its possible solutions.