mobileOK Basic - it has teeth!

The W3C announced today the second public draft of the mobileOK test document (the first of mobileOK Basic as it is now known).

The document is has changed a lot since the version of the 12th July and I thought I'd take some time to look at some of the ways in which it has changed and to give some personal thoughts about its significance to the development of the Mobile Web.

Divide and Conquer

Initially the W3C MWI BPWG (trips off the tongue, doesn't it) was going to publish a single document covering three related but distinct aspects of mobileOK - Basic tests, more advanced tests and a scheme for labelling sites in a machine readable way.

The motivation for putting all in the same document, of course, was that the subjects are interlinked and that we didn't want to "encourage" people to think that going for the lower (machine processable) level of testing was all there was to be said about the subject. Equally, the labelling aspect is important because if you have gone to the trouble of making your site mobileOK then you'd like to be able to advertise this to crawlers and show up with higher rankings in mobile search results.

However, having taken the advice of various interested parties it was decided to de-couple the three aspects - partly in the interests of getting something out for public review in a reasonable time frame, partly because the non-machine testable aspects of mobileOK will take quite a lot more work and partly because the labelling infrastructure won't be ready till some time in the new year.

Digression - mobileOK Labels

The general subject of labelling of Web content is an increasingly urgent need which has to be addressed by a suitably flexible, machine readable and robust standard. It's really very desirable that the technical mechanism for labelling mobileOK should be the same as the one used for labelling child-friendly content and W3C WAI Accessible content to name just two of the areas to which it is relevant.

However, even a moment's thought about labelling shows that it's a difficult area, involving not just technological problems (which we can solve, usually) but social issues such as trust and trustworthiness. "Who is saying what? What are they saying it about and why should I believe them?" If you make a label saying that my site is not mobileOK and I make one that says it is, on what basis are either you or I to be believed?

But I digress - if you are interested in W3C work to find the successor to PICS then check out the work of the W3C Web Content Labelling Incubator Group (WCL-XG) and its report (draft) (co-authored by Phil Archer of ICRA and me) which act as part of the input to a W3C Working Group, which we hope will be approved soon.

Encouraging the least-common-denominator?

Aside from the very much improved tests, one of the major differences between this draft and the last one, is the inclusion of some fairly strongly worded language in the introduction about how the tests described in the document are only the beginning as far as building a mobile experience goes.

The use of the phrases "... content provider has taken basic steps ...", " ... should be considered only a first step." and "Compliance merely demonstrates that ..." is intentionally strong and is supposed to alert the reader to the idea that if you pass these tests, it still doesn't say anything about whether you have provided a useful, meaningful or pleasant user experience. And that really, if you do want to do that there's a lot more you should be doing besides passing mobileOK Basic.

This all follows a lengthy debate within the BPWG about serious concerns expressed by some members. Their concern was that by setting the bar low, people would aim low, develop simplistic sites that seemed to be mandated by mobileOK - and not develop more sophisticated and more compelling user experiences. Others felt that setting the bar too high would discourage people bothering at all, and as a consequence would not be the catalyst we all think is needed to stimulate the growth of the mobile Web.

An important part of the background to the debate is that the tests - and the acceptable results - defined by mobileOK are defined for one very specific and, on the face of it, unrealistic circumstance - what does the Web site do when accessed by the BPWG defined Default Delivery Context (DDC). The DDC is a specification of a device that has a minimal level of features to qualify it as a Web device. The idea of testing against the DDC is that while it is 'mandatory' in the Mobile Web to be able to deliver a functional experience to minimal devices it is optional, but very much encouraged to exploit the capabilities of more sophisticated devices.

An example of this conundrum is that the DDC specifies 10k of markup and 20k of total page weight. This is very limiting - and if you were to deliver pages of this size to an Nseries Nokia, you would not be giving the user as good an experience as you ought.

Needless to say, the correspondence on this in the group was quite voluminous and explored the highways and byways of almost every possible aspect - and a short-ish post like this really can't do justice either to the length of the correspondence or the impassioned tone of some of it. I confess that at the outset of the debate I was in the bar-too-low camp, but as time has progressed my view has developed - and I now find myself wondering if the Basic tests are not actually somewhat on the stringent side (OK, I changed my mind - or rather was persuaded, on balance, by the merits of the position I now hold).

In short, it's not so much that any of the tests on their own is conceptually difficult or hard to pass - it's that passing all the tests would represent a non-trivial improvement in quality for many, if not the vast majority of Web sites. As such it is one step, a relatively big step, at that, on the road to mobile Nirvana.

Non-Trivial Tests

Let's put it this way, how many Web sites actually feature valid HTML? Well if you were to run a random sample through the W3C's validation service (validator.w3.org) you'll find that really very few do. Yet, valid HTML is only one of the 27 tests of varying complexity currently defined by mobileOK. As a result, content that passes all of the tests is something really to be proud of and shows, to my mind, that the content provider (or their web developers) has taken unusual care to make it so, even if in an ideal world they look rather basic. So the important thing is to note that while there are loads of other steps you can and should take, this is the first step you need to take and by comparison with the steps usually taken in the Web today, represent a good effort.

Keeping a site mobileOK after the intitial development is, of course, a different question, and one that demands at least a minimal level of process in the maintenance activity. If you do develop Web sites, how rigorous are you about checking that the site is valid? Probably, like most developers, you check that it looks OK in the most popular browser (or possibly two) and if it looks OK, you call it a day. With an increasing amount of content being generated by content management of different sorts and by templates, of course, this is a different question to when folks used to hand code each page (OK, I still do, sigh), but looking under the stone on stuff delivered by content management and templates by doing a "show source" nonetheless reveals a fair number of scary things.

Tools

The idea of validity checking, let alone mobileOK checking, is really not that well supported by the tools. None of the several I have used recently even says a polite: "Excuse me, but you know I have HTML Tidy locally plus I also have the ability to submit this file to the W3C HTML validator? Don't you think you should be doing some kinds of verification before committing that change to the live server?".

A key, and developing theme in my mind, is the fact that the tool chain that people use is usually well short of what is needed to produce consistent and reliable results. I can't help thinking that the fact that you can write HTML pages with a simple text editor is both the cause of the Web taking off in the first place, and the largest obstacle to producing reliable, repeatable and consistent results across browser types.

Tools being a current hot button with me as they are, and if you are interested in them too, then you should check out what I can't help calling Mr Dev. Mr Dev is the dotMobi Ready checker - which gives you a rather nice display and a score. The score is a helful feature that gives you some kind of idea how close you are to conforming to Best Practices. Ruadhan and Ronan from dotMobi have put in a good job here.

Mr Dev implements most of the tests in the just-released mobileOK second public draft and is therefore a work in progress. Also check out the W3C Best Practices checker by Dom, I believe that at the time of writing this is not quite so up to date with the current draft.

Conclusion

This second draft of the mobileOK document is a significant change and improvement on the first draft. It's got a little way to go before it is stable, but in my opinion not that far. It is potentially a big contribution to the improvement in quality of the mobile Web despite the degree of qualification of the wording in the introduction.

Tools like dotMobi's Mr Dev and W3C's mobileOK checker need to be part of the way of life of developing Web sites and development tools need to help developers conform.

Jo Rabin