Editor's Corner

I've been involved with MWI for a while, though this is just a personal response and not from the working group --

Broadly, I think it's a fair comparison, but I disagree with several of your key points.

"One web" means many things to many people, and some interpretations are quite controversial, so its mention seems to always draw fire. GAP stresses that one needs to generate a separate mobile-specific site and markup for phones, and the MWI BPs 100% agree. Heck, they're talking about writing markup with no tables! very different and mobile-specific.

XHTML Basic 1.1 has nearly converged with MP 1.2. If anything, Basic is the more limited standard. Hence it was recommended that you only assume what Basic supports. The related mobileOK standard kind of clarifies this.

Neither document discusses adaptation actually. MWI just focuses on what you deliver to a basic handset, adaptation or no, and GAP says it's nice but out of scope.

I think that if you compare these recommendations point by point you see they're actually quite similar, which is not surprising. Everyone should read both.

Finally I'd like to point out two developing tools that try to help assess compliance with best practices:
http://validadores.tawdis.net/mobileok/en/
http://ready.mobi/

Hi, I am Luca Passani of WURFL and GAP.
The reason why I decided to create the GAP document was that I couldn't get the W3C BPWG group to see it my way on a bunch of key aspects.
Sean is right that there are similarities, but I think it's important to stress differences between BP and GAP, since GAP is an attempt to do right what W3C did wrong (IMO, of course).
Sean has always minimized the impact of one-web on BP, but what I see is that one-web is a big distraction for those who want to create mobile services. In fact, a whole bunch of "corollaries" are derived from the one-web dogma (wrt both BP and MobileOK) which are bound to be a hindrance for developers. Also, BP has "imported" some guidelines from WCAG, the W3C accessibility stuff. There was no reason to do it if not because of W3C internal politics, since those practices are wrong when applied in the mobile context. Finally, GAP is about educating developers about usability and, indirectly, how to improve user-experience with adaptation. Readers of GAP will walk a way with the clear understanding that one-size-fits-all mark-up will only take one so far and will most likely fail to deliver a great user experience for many users. Adaptation should be chosen whenever possible, instead. IMO, MWBP does not go long enough in stressing that adaptation is a must (i.e. readers may walk away with the impression that one-size-fits-all is good enough).
Anyway, thanks to Eli for writing this account of the mobile development guidelines landscape.

Luca Passani

Hi - I've been involved in the MWI since day dot and have a few comments to make.

1) The group started with WCAG as some of the guidelines are applicable. I’m happy for Luca to highlight exact guidelines which aren’t relevant. Making a site accessible to people who use assistive technologies, by default, is more accessible to mobile devices. My company is active in both groups so we appreciate the similarities. Using WCAG guidelines to start with wasn't even the W3C's idea.

2) GAP is for developers who wish to build sites that only work on mobile phones. Web sites that use GAP will *not* work on desktop computers (at all). The MWI helps developers to create sites which work on desktop computers and will work better on mobile devices.

Some developers will only develop for mobile, some will develop for desktop and some will want to develop for both. So, there are use cases for both GAP and MWI. I’m just pleased the MWI participants could help Luca by giving him a house that needed a little bit of decorating. For the record, the same can be said for the .mobi guidelines. That is, they are the MWI Guidelines with a little tweak here and there.

3) I would have liked to see a quote from someone non-WAP focused to help balance the story. It appears to be quite one sided IMHO.

Paul, engaging in yet another blog thread was not in my wish list. But some of the things you wrote force me to set the record straight.

> The group started with WCAG as some of
> the guidelines are applicable.

I am not sure about what went on before I joined BPWG, but I know that many of the partecipants considered WCAG a nuisance, more than a support to the work which was taking place. In fact, I don't recall any big discussion on this, until recently when I raised the point and you reacted sort of violently.

> I’m happy for Luca to highlight
> exact guidelines which aren’t relevant.

here they come:

- do not autorefresh pages: Refreshing may be necessary for email or chat applications. This guideline is interfering with a service business model without need. Practice should be removed from BP.

- do not use frames and pop-ups in mobile site: You’ll agree with me that it does not take a genius to figure that out. Many imode users in Japan also created CHTML sites they could show to their friends (previewing in MSIE) and, guess what, they were not trying to open windows and frames! all in all, a pretty pointless contribution. Practice is useless and should be removed from BP.

- do not use tables for layout: this is such a stupid recommendation. Tables are the only way to place picture and text side-by-side on a mobile browser in a way that works consistently across all mobile browsers (and no, CSS can’t do it at the moment, not on the same variety of devices at least). As a little aside, you can use table for layout and still validate 5 out of 5 with the dotMobi validator. Obviously, I am not the only one who thinks this WCAG contribution to BP is rubbish. Practice should be removed from BP.

- use colors with high-contrast: that’s also bad. You may choose colors with high contrast for your mobile site, pass W3C validation/certifications with flying colors, only to find that some devices won’t honor the color for hyperlinks, thus leaving the user totally stranded in practice. Not very accessible. Practice should be removed from BP.

> Making a site accessible to people
> who use assistive technologies, by
> default, is more accessible to
> mobile devices

As I said before, the problem of enabling the web to people with disabilities cannot happen at the expenses of disabling the web for people without disabilities. This discussion has already taken place here:

http://segala.com/blog/luca-passani-is-wrong-in-my-opinion-discrimination-isnt-good-for-business/?domovar=1

> Web sites that use GAP will *not* work
> on desktop computers (at all).

This is nonsense. You don't have a clue, do you? What I am going to explain to you now does not detract in any way from my point that who builds a mobile service should not be required to necessarily care about the web experience of the same service (i.e. what "one web" demands): Of course, this has nothing to do with the importance for developers to be able to preview their application in a web browser for debugging purposes. Not by coincidence does WALL make it absolutely sure that a web preview is provided.
If you use the GAP templates you *WILL* be able to preview your pages in both Opera and Firefox (surprise, eh!?). And guess what. That's exactly the same you will get if you follow the BP, since Internet Explorer (any version up to 7) will fail to recognize the XHTML-basic MIME type and ask users whether they want to save the file to the file system (that's unless you tell me that BP is recommending text/html as a MIME type for mobile).
If anything, GAP does point to a simple code snippet that will let developers serve the right MIME type Plain-HTML, XHTML basic or XHTML MP).
Developers do not get any such hint with BP, so GAP is better than BP also in that regard.

> The MWI helps developers to create sites
> which work on desktop computers and will work
> better on mobile devices.

yeah, in your dreams!

> I would have liked to see a quote from
> someone non-WAP focused to help
> balance the story. It appears to be quite
> one sided IMHO

translation: would someone who does web development, still knows nothing about mobile, but thinks that they may create mobile services from one day to the next simply by leveraging what they know about the web, drink a few glasses of Paul's favorite whisky and be brave enough to post something supportive of Paul's point?

Luca

Hi Eli,

First of all, thanks for looking at the topic and commenting on it.
You have sparked discussion which is great. I am also a member of the Best Practices Working Group (BPWG).
Let me add my own views and comments to the discussion.

You say you are worried that there are too many Best Practices.
I agree with you that the W3C work ought to be the work of reference.
Not because it is the W3C, but because it is a global organisation with practically no intrinsic commercial interests that has worked on interoperability from day one.
dotMobi has pretty much adopted all of the Best Practices from the W3C and refers to our work. That is an endorsement of our work, as far as I am concerned and shows that a W3C recommendation is a living thing.

As for the markup to be used, let me quote from the dotMobi guide:
"Thanks to recent alignment efforts between the W3C and the OMA, the proposed W3C XHTML Basic 1.1 and XHTML-MP 1.2 are virtually indistinguishable."
There can be only one standard. Because of this needed convergence we are proposing XHTML Basic 1.1 in our work.

The Best Practices are trying to look not only at today but also at tomorrow. They are intended to open up the web to mobile devices on a grander scale.
How will mobile devices be defined in the future? The lines of division are already blurring. If we continue to focus solely on mobile content then that is all we will get.
The Best Practices are the first attempt to clean up the mess we have today. But they are also a fluid document. As devices change, as the world changes, so will the Best Practices.

"One Web" is utopian, you cite developers? There is a full spectrum of content out there. Some intended purely for PCs, some purely for mobile devices. But there is also an enormous gray zone in between. It is this zone where I see the greatest application of our work, because here I can make my web mobile, take it with me and use it as I, the end user, choose to. dotMobi has shown, however, that there is strong appeal for purely mobile content as well.
Thus one web is about usage, not display. It is something to strive for, not a homogenous content soup that doesn't satisfy anybody. There will always be room and necessity for specialized content.

You mention content adaptation and least common denominator design.
Here I have to say you simply have it wrong.
Content adaptation allows you to deliver the best content for a given device. This is what we want.
Only and only if you do not know what the device is that is making a request, should you deliver content that adheres to the "Default Delivery Context". It is a catch-all, a fallback. Something to ensure that whatever you build will allow some sort of decent experience on the web. Nothing more.

Hi

I'm a web developper as well as a mobile web developper (from the begining of the mobile web story).

I studied MWI BP and here is what I think about it : it contains some good advices, some other are "obvious", some are not so good (can cause problems in some circumstances) and some are bad (WILL cause problems). I will post a second comment with my opinion on all the BPs

I also think that because DDC is only about XHTML (name it as you want), it does not take count off 50% of the traffic of the mobiles in my country (France) that is done by WAP1 (WML) and i-mode devices (cHTML), and so, it can not be a good practice to only stick to the MWI BP to be accessible from mobiles devices.
In a few years, WAP2 phones will represent the vast majority of phones. But I fear that, by this time, MWI BP will be outdated and some new practices will need to be used to handle theses futur devices (or perhaps soup html will be ok for 80% of them).

I was disapointed by MWI BP because faced to the difficulty of developping mobile web site, I hopped it could helped me. I now realize that BP are not for mobile web developper, but only for web designers that know nothing about mobiles. The problem is that BP are not enough to make them understand how to nuild a site for mobiles.

GAP will help them in a better way, I think ... giving them a more wider view of the difficulty they will be faced to.

the new .mobi's developper guide is my next reading ;)

Here is my opinion on BPs.

They are classified, and the criticisms are detailed :

Good Practices:

Intersting for mobile web developpers:

[CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.
[DEFICIENCIES] Take reasonable steps to work around deficient implementations.
[TESTING] Carry out testing on actual devices as well as emulators.
[URIS] Keep the URIs of site entry points short.
[BALANCE] Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.
[ACCESS_KEYS] Assign access keys to links in navigational menus and frequently accessed functionality.
[EXTERNAL_RESOURCES] Keep the number of externally linked resources to a minimum.
[CLARITY] Use clear and simple language.
[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions.
[PAGE_SIZE_LIMIT] Ensure that the overall size of page is appropriate to the memory limitations of the device.
[SCROLLING] Limit scrolling to one direction, unless secondary scrolling cannot be avoided.
[CENTRAL_MEANING] Ensure that material that is central to the meaning of the page precedes material that is not.
[LARGE_GRAPHICS] Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.
[USE_OF_COLOR] Ensure that information conveyed with color is also available without color.
[COLOR_CONTRAST] Ensure that foreground and background color combinations provide sufficient contrast.
[PAGE_TITLE] Provide a short but descriptive page title.
[TABLES_SUPPORT] Do not use tables unless the device is known to support them.
[NON-TEXT_ALTERNATIVES] Provide a text equivalent for every non-text element.
[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script.
[IMAGES_SPECIFY_SIZE] Specify the size of images in markup, if they have an intrinsic size.
[IMAGES_RESIZING] Resize images at the server, if they have an intrinsic size.
[STYLE_SHEETS_SIZE] Keep style sheets small.
[MINIMIZE] Use terse, efficient markup.
[COOKIES] Do not rely on cookies being available.
[FONTS] Do not rely on support of font related styling.
[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum.
[AVOID_FREE_TEXT] Avoid free text entry where possible.
[DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the device is known to support it.

Good but obvious:

[IMAGE_MAPS] Do not use image maps unless you know the device supports them effectively.
[POP_UPS] Do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
[GRAPHICS_FOR_SPACING] Do not use graphics for spacing.
[NO_FRAMES] Do not use frames.
[SUITABLE] Ensure that content is suitable for use in a mobile context.
[STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.
[CONTENT_FORMAT_PREFERRED] Where possible, send content in a preferred format.

Not specific to mobiles ... why in the MWI BP ??:

[THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.
[LINK_TARGET_FORMAT] Note the target file's format unless you know the device supports it.
[MEASURES] Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.
[NAVIGATION] Provide consistent navigation mechanisms.
[AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.
[VALID_MARKUP] Create documents that validate to published formal grammars.
[STYLE_SHEETS_SUPPORT] Organize documents so that if necessary they may be read without style sheets.
[CONTENT_FORMAT_SUPPORT] Send content in a format that is known to be supported by the device.
[CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the device.
[CHARACTER_ENCODING_USE] Indicate in the response the character encoding being used.
[STRUCTURE] Use features of the markup language to indicate logical document structure.
[TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.
[ERROR_MESSAGES] Provide informative error messages and a means of navigating away from an error message back to useful information.
[CONTROL_POSITION] Position labels so they lay out properly in relation to the form controls they refer to.

Not a so good practice:

[CACHING] Provide caching information in HTTP responses.
Some devices are really buggy with cache directives ...

[LINK_TARGET_ID] Clearly identify the target of each link.
It may be disruptive and hard to see that we are not at the begining of the page

[PROVIDE_DEFAULTS] Provide pre-selected default values where possible.
Sometimes you need to press 'del' for each already present character if you want to write something else

[TAB_ORDER] Create a logical order through links, form controls and objects.
It may be very disruptive if the order of page elements is changed. It's better to let the device manage it

[CONTROL_LABELLING] Label all form controls appropriately and explicitly associate labels with form controls.
On some devices, labels are not displayed ... You should not count on it, and use classical text next to The input to labbel it.

Bad Practices:

[NAVBAR] Provide only minimal navigation at the top of the page.
Horizontal nab bars may force the user to scroll through each link (for two-ways navigational phones) and also : it depends on the site design ...

[REDIRECTION] Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.
It's known to be bugguy on some devices. For example some devices do not handle 302 responses

[LIMITED] Limit content to what the user has requested.
Why won't I add publicity to my site ?

[BACKGROUND_IMAGE_READABILITY] When using background images make sure that content remains readable on the device.
Using background images is a bad practice with mobiles (buggy)

[TABLES_NESTED] Do not use nested tables.
What if I need it and I know the device can handle it ?

[TABLES_LAYOUT] Do not use tables for layout.
What if there is no other way to have the good layout with somes devices ?

Cédric,

MWI BP explicitly ruled WAP1 content out of scope. And the working group explicitly recognised that things will change over time. Getting consensus (as opposed to getting all the world to just see it Luca's way) takes time, so the task was broken into smaller parts.

As well as the Best Practices, which are (hopefully) more generally applicable over time - although presumably they will need revision at some point - there are the MobileOK Basic tests (things you can check automatically, which are relevant to whether your web content will work on mobile web devices), and the more complete MobileOK tests in development. These are what people would apply and test for in day to day work, and I expect them to change more rapidly.

The primary target of Mobile Web Best Practices is people who are Web developers, wanting to make their web content work on a mobile.

If you are prepared to make a more powerful system, that adapts content to all kinds of phones (something that MWBP strongly encourages but does not "require" willy-nilly) then following the Best Practices document allows you to adapt content to those systems you know, in the way most appropriate for the device. The point is to find a reasonable default for devices which are unknown. (This is something that Web Developers have been notoriously bad at over the years, denying many users access to content that would have worked fine, simply because the developer wasn't sure what the user could do.)

If you are making a WAP1 site then the only desktop browser I know of that it might work on is Opera. The idea of "one web" is that you make sites that work on any Web Browser (where that means something that handles certain varieties of (X)HTML, and WAP1 browsers are excluded). This is not the only mobile content, but it is the vast majority of web content, and getting that to work on mobiles is the goal of the exercise.

The working group could look at specific advice for people who do mobile content, as opposed to Web content, and how they can make their content relevant to the broader audience. But those people often already do complex adaptation so have more of the basic tools and knowledge available. So it seems to me that the choice of "primary target" makes sense...

It would be helpful if you sent your list of comments to the MWBP working group, by the way, although it seems half the group is reading this blog entry.

Speaking of which, is the rhetorical flourish of 'many developers feel it is an impractical and Utopian vision of "One Web"' directly due to Luca, or just channeling his spirit? It seems that, like Luca himself, the entry is trying to claim that minor differences in focus and technique amount somehow to a fundamental divide in technology. This scenario would imply a dichotomy with the ignored genius on one side and the ignorant and unwashed community of user groups, content providers, browser developers and adaptation experts behind W3C on the other. But I think Sean is closer to the mark in describing the reality here. Not that there are no differences, but that there is actually a lot more common ground. In many ways it is really just a question of perspective.

Disclaimer: I work for Opera. Our goal is to ensure that the Web works everywhere, providing common ground so ordinary developers can make content that Just Worksâ„¢. We do the adaptation to devices, and support simpler ways for developers to do it (media queries, media-specific styles, and so on) so that developers can present applications and content by writing them simply for the Web at large (and small), rather than having to invest in adaptation systems for simple pages and tools where pixel-perfect rendering isn't a relevant requirement anyway. This presumably informs my perspective...

> Getting consensus (as
> opposed to getting all
> the world to just see it
> Luca's way) takes time,
> so the task was broken
> into smaller parts.

Chaals, my choice of words was probably unfortunate, but I need to point out that I was ready for teamwork when I approached BPWG.
The moment when I decided that it was impossible to turn MWBP into a valuable resource for developers, was when the group refused to state clearly if it was mobile devices or desktop browsers they wanted to create recommendations for. Still today, different members say very different things in this regard (albeit everyone agrees to sweep the problem under the big one-web rug). Had there been clarity in the group at some point, I would very happily have accepted compromise whenever possible and refrained from creating an alternative style guide.
Wasn't it you that, at some point, said that ambiguity was OK and that agreement would be found along the way? well, I guess that now there is space to see it either way. You can say that all BPWG members found an agreement and BP was created, so you were right. I can say that, with GAP, I single-handedly did better than MWBP in terms of developer mindshare, just because I faced and solved ambiguity, so I was right.

All in all, I think it's W3C's fault that a great opportunity was lost to bring industry players and developers around the same table and create something powerful for everyone.

Luca

Speaking on behalf of dotMobi, and partly just to add my name to the usual suspects ;-)

I'm very happy you think that the guide makes things easier. But it's not "yet another set of best practices" - essentially we were trying to humanise the existing W3C work into a format you might expect to read if you plucked the guide from a bookshop shelf.

Our big drive is to democratise the process of developing mobile content. (At the moment it's just too damn cliquey and certainly daunting to regular web developers.)

We greatly support the W3C work. I also acknowledge that Luca's a highly experienced and influencial "high priest" of mobile, so I always listen to what he says too.

There shouldn't be any surprises to anyone reading both our developer guide and the W3C document. (If there are, tell us - it's probably a bug!) As well as Brian, another key contributor was Jo Rabin - who just happens to be the co-editor of the Best Practices document.

Letting you in on a secret here... over time we plan to serialise and then wikify this guide. That's then a format where experienced mobile developers worldwide (no doubt Luca included) can add their words of advice and guidance to those trying to make sense of, yes, this Wild West.

> over time we plan to
> serialise and then
> wikify this guide.
> That's then a format
> where experienced mobile
> developers worldwide
> (no doubt Luca
> included)can add their
>words of advice and
> guidance to those trying
> to make sense of, yes,
> this Wild West.

What a great idea!
Yes, I would be happy to contribute to such an initiative. Not only because I love the idea of giving developers a chance to influence W3C specs, but also because the fact that you manage the .Mobi developer strategy, James, is a guarantee for every developer that .Mobi is on the right track.

where are the responses from the original author?