MWI Team Blog

Dispatches from members of the W3C Mobile Web Initiative Team

Categories: Current state (32) | Developing Countries (15) | Events (20) | Looking forward (13) | News (42) | Technical (33) |

W3C Mobile Web Initiative - what's next? — 10 May 2008

During W3C's bi-annual member meeting, I presented a few slides on where we see the Mobile Web Initiative going in the future - copied below.

We'd be interested in your feedback, so see question at end.

Mobile: Where do we stand?

MWI: Where do we stand?

Screenshot of mobileOK checker

Future Priority: Mobile Web Applications

Future Priority: Mobile Web in Developing Countries

Man with mobile phone in Asia.  AFP, Deshakalyan Chowdhury

Future Priority: Improving Standards Compliance and Testing

Screenshot of Web compatibility test

  • No "dominant browser" in mobile
  • Non-standards compliance even bigger problem for developers than on desktop
  • W3C work has started
    • Test harness simplifies testing Web specs on mobile device, 45K results collected via "crowdsourcing"
    • Web compatibility test to check "difficult" feature support (ACID inspired)

But of course, the mobile community is bigger than just W3C members ...

So, where do you see the mobile Web going in the next few years?

And what do you think should be the contribution of W3C's Mobile Web Initiative?

Share your thoughts below!

by Philipp Hoschka in Looking forward, Current state 1 comment Permalink

Making HTML location-aware — 29 January 2008

Location-based services has always been highlighted as a high potential for mobile web applications - it already was in the early WAP days-, but the current technical/legal situation makes it still a pretty hard to reach Graal:

  • most devices still don't come with an integrated GPS system - although this will probably be changing fast in the coming years,
  • when they do, there aren't any standard way to access to their data from the browser context - the Japanese market relies on a Java-based proprietary system; it is worth noting that the W3C Ubiquituous Web Applications Working Group is addressing part of that problem through its DCCI work;
  • operators are pretty reluctant to share the location data they get through their antenna's networks,
  • and most importantly, sharing location across the network is extremely sensitive in terms of privacy.

In my mind, most of these are only issues insofar as one considers LBS-services only through the lens of "the user's current location"-based services.

It seems to me that many services don't actually need the current location, but some location the user is interested in: that can be of course her current location, but it may as well be a location she'll be in the future or has been in the past, the location of a friend or family member,etc.

It remains that entering location information on a mobile device, with a limited keyboard, is hard and boring - it can be helped on the server-side, but not without breaking the privacy wall.

So, I am wondering if one way to make good progress in the area of LBS would be to focus on creating an HTML control that would allow easier input of location-data, rather than only focusing the on the "current location" aspect, and keeping it as a mostly client-side only operation.

Typically, I'm thinking that if we could get the big browsers vendors to agree on an HTML control à la:

   <input type="location" />

this would offer the opportunity to create many interesting interactive user interfaces to enter location data:

  • an address from an addressbook (or from your favorite social network),
  • a previously entered address,
  • an auto-completion address widget, either through in-memory data (as most GPS navigations system offer to enter for instance your destination), or through a set of AJAX requests to an appropriate service,
  • a map-based selection control,
  • and of course, when available, the current location of the user.

This could look something like:
Mockup of HTML location control

Given how HTML is implemented, for browsers which don't understand this specific input-type, they would get a normal free-text entry where one could still type an address if needed, thus providing seamless backward compatibility. Some Javascript magic could also be added to deal with some of this - typically to provide the map-based version of the control and the AJAX-autocompleted address.

To alleviate security/privacy issues, my thinking would be that such a control would have the same security restrictions as the <input type="file"> control - i.e. they couldn't be accessed through scripting at all. Note that in this case the privacy issue more or less disappears, since the browser in most cases can be trusted to be safe privacy-wise - even if I do input some location on my browser, nobody can tell whether that's my current location, somebody else's, a random address I just happened to see on a flyer.

On the server side, if the control sends both GPS data and manually written address, it may be a bit difficult to reliably parse the data provided, although it doesn't seem too hard to imagine having well-defined APIs to have this parsind done by a service provider of your choice, much like Google Maps or Yahoo! Maps would do for you today.

The first public working draft of HTML 5 doesn't address yet the area of new form controls, but the current WHATWG WF2 spec does, and they suggest adding specific controls for emails, dates (in any number of formats), and urls.

Surely, location is at least as important to most of us as urls and emails?

Let me know what this inspires you (if anything), and if it does, let's work to make it happen!

by Dominique Hazael-Massieux in Looking forward 3 comments Permalink

Making The Mobile Web relevant for rural communities of the Developing World — 18 December 2007

I recently came across two posts from two people i trust questionning the potential for the Mobile Web to be a solution to help rural communities of the Developing World in their development.

Both Nathan Eagle (read Nathan's post) and Ken Banks (read Ken's post), using different words, don't believe that the Mobile Web is a potential answer. At the opposite, I've been pushing this idea of Mobile Web for Developing Countries since more than a year now.

So is someone right and someone wrong? I'm not sure. In the Developed World, "Mobile Web" means providing the same user experience as on your desktop machine. The iPhone browser for example is, for me, an illustration of the ultimate achievement: the complete full Web on your handset. But would this model work in the Developing World? Are people in the Sahara going to get an Iphone soon, and a 3g network connection? Is a crop producer in Fidji going to use google or yahoo to see how to make bigger papayas?

I don't think so and completly agree here with Ken and Nathan. I think we are sharing the same goal: using mobile phones to provide access to relevant and useful informations and services to rural communities to improve their daily lives.

Today, if one wants to deploy a usable service on mobile phones, how should he proceed ? Again here, I agree that SMS and Voice applications are the only choices. But while these technologies have their own strengths (read a comparative study I wrote for IST-Africa 2007), they are lacking an essential feature: the scalability.

Having a specific NGO, or a project developing a specific application for a specific community is one thing - it is what we've been observing since few years now, with an incredible ratio of successes. All these experiments have ben using SMS and/or Voice applications. Great. But building on these islands of success to reach a state where thousands of services will be available is quite another story. It is hard and expensive to develop an SMS or a voice application. It is hard and expensive to advertise it to potential users. So I really doubt that we would ever have thousands of such applications available.

My view is coming from my background in Web and Mobile. When operators explored the idea of mobile applications in late 90's, they originally thought about WAP. A total failure, and very few content available. Why ? Mostly because it was hard and expensive for individual to create content, associated with a wrong pricing scheme compared to the value. At the opposite the success of the Web from 1989 when Tim Berners-Lee invented HTML and HTTP to now, is mostly due to the easiness for anybody to create content, and make it available and accessible to the whole World. So I strongly believe that Web technology is the only one which would scale well, and allow the development, deployment and availability of a big number of services.

However, as I said above, I don't believe that the problems to solve are in the infrastructure and the handsets. There is no minimal Web capabilities on low-end phones today, not because it is impossible, but because there is no demand and no use for now. As soon as people will start requesting this feature, all phones, even the very low-end ones, will have minimal browsing capabilities. This demand will come only if there is a value for people, i.e. if they find services that are helping them in their daily life.

In order to make usable and useful services, we have to adapt Web technologies to the need and requirements of the Developing World. Here the "Mobile Web" should not be aiming at reproducing a desktop experience, because people don't have desktop experience. Is the zooming interface ala iPhone browser natural for those who never used a computer before ? I really doubt it. So we should redefine browser and content interfaces to make them "natural" for those without previous computer experience. We should also understand what "natural" means for those without technological background, e.g.: if you've never ever been to an office, does the concept of files and folders have any meaning to you? So understanding which HCI paradigm to use is a key point.

Understanding also which applications could be particularly useful for a community is another point. Here again, I really doubt that we would be able to define a list of services that could improve people lifes everywhere in the World from Algeria to South Africa or from Bolivia to India. Each community has its own needs, way of working, living and so on. I think it should be possible to develop expertise on how to capture these needs and to understand where ICT could improve the situation, so that anybody interested to help a community could use such guidelines to see which service to develop first.

So the Mobile Web as it is defined in Europe, Japan or US today is clearly not appropriate to offer useful and usable services to rural areas and underprivileged population in Developing Countries. But I believe that the potential is huge compared to other technological options to deliver ICT services, and thus it is critical to make appropriate work to make the Mobile Web relevant in Developing Countries.


<< Previous Page :: Next Page >>

Contacts: Dominique Hazael-Massieux