Luca Passani (passani at eunet dot no)
Motivation behind "Global Authoring Practices for Mobile Web" document
======================================================================
There are quite a few XHTML-MP (Mobile Profile)
authoring guides out there, so you may wonder why I am spending
time to create what might appear as yet another
one of those. One of the main motivators for this activity is that
there is no such thing as an *independent* set of guidelines for creating
content for the mobile web.
OK, I can see one hundred questions (and objections!) being raised already.
I'll need to ask you to be patient and read this document to the end.
By then, I will have provided enough info to take any question on
some solid ground.
As I was saying, plenty of mobile browser vendors have created
each their own manuals and tutorials about how mobile content should
be authored using XHTML-MP "according to them".
Because of the large number of players in the mobile business today,
and even when restricting ourselves to XHTML-MP, the industry has
produced lots of tutorials and developer guides, each and every one
of which only contains part of the story (and, sometimes, even
contradicting one another). This is no surprise after all: why
should Nokia cover the Teleca browser? why should Openwave keep from
promoting the valuable usability extensions in its browser?
is there any business reason why the Opera guys should tell
developers to create content for browsers less powerful
than their own? The reality is that covering
competitors' products makes no business sense. This is why
everyone ended up producing the documentation that makes the most
sense to them.
Unfortunately, this situation creates a paradox: the audience
of these guidelines, i.e. the developers, are the one left wondering
what they should do to create decent mobile content that works
acceptably well on all devices. There is a gap to be filled and
this is where the Global Authoring Practices (GAP) document
plays a role.
If you have followed the evelution of mobile development over the years,
or simply have a smattering of experience with development for mobile,
I am sure you have many things to say and ask. Please wait.
I have things to say about WML, Least Common Denominator, Adaptation
and W3C MWI, which will put all of these things into a certain perspective,
before we start discussing.
Global Authoring and WML 1.1
============================
While not an XHTML MP tutorial, the GAP document does assume that
developers intend to create content using XHTML Mobile Profile 1.0,
or, at least, some flavors of HTML for mobile (cHTML for i-Mode in
Japan would be a good example of that). This leads to an interesting
consideration, though.
If, in the moment I mentioned Global Authoring, your thoughts ran to WML,
you have a heck of a point. If the goal of this guideline is to let people
know how to create content that is accessible on the widest possible
number of mobile devices, then WML is the best answer. I would
have a hard time mentioning a device that does not support WML,
but I could mention hundreds that do not support XHTML-MP, and some
that support XHTML-MP so poorly that they should not even be
considered legitimate XHTML-MP clients. I might argue
that WML is the past and XHTML is the future.
Yet, the fact remains that more mobile devices understand WML than XHTML
of any flavor. Or I might argue that XHTML allows flashier application
than WML. Even that is objectionable, though. After all, nothing in WML
restricts authors from using GIF and JPG pictures. Even CSS is supported
poorly enough by many devices that CSS can hardly be a selling point.
Some (but not me!) will try to argue that XHTML MP allows for more
usable applications. But that's an incorrect statement.
For example, WML has features that let developers program
softkeys and such. Some families of WML (particularly
in the US) let you associate two actions (one per softkey) to the same
selected item (for ex: left key to read highlighted message,
right key to delete). This cannot be achieved in XHTML and
similar features can only be emulated at the cost of introducing
a lot more clicks.
In the end, we all must pay a tribute to WML and admit that the mark-up
language of WAP 1.X is the moral winner in the race for global mark-up
of the mobile world. Yet the medal goes to XHTML-MP, the appointed
winner in the name of a not-better-qualified convergence with
that "big web" which non-mobile developers have known for years.
WML is dead. Long live WML.
Isn't this LCD (Least Common Denominator) authoring?
====================================================
In case you have not heard of Least Common denominator authoring,
the concept is simple. Imagine that two browsers, A and B, implement
features X,Y and Z. Imagine that browser A also implements feature X2 and
browser B also implements Y2. Now, imagine that you want to create an
application that works on both A and B. Question: can you use feature X2?
answer: No, you can't. It would break B. The specular question yields
the same answer: you cannot use feature Y2 in your application,
or users of the B browser would be unable to use your application.
At the cost of sacrificing some cool features,
you need to deliver an application that only uses X,Y and Z.
Now, this is the Least Common Denominator approach. You give up some features
on one side, you gain potential users on another. This is the phenomenon
we witnessed between 97 and 2001: Intranets (which assumed MS Internet
Explorer as a client) supported cooler UIs than Internet websites,
which had to support a large number of users still running
that klunky Netscape 4. The reason why internet websites had less
advanced UIs was that they adopted LCD authoring.
Now that you know what LCD is, the question becomes, is GAP about
LCD authoring? If I was working in sales, I could come out with a
bunch of ways to workaround this question. But my background is
development. I am compelled to tell the truth :) So, I prefer to
answer "yes" loud and clear, and then move from there to explain
the ways in which GAP is more than LCD.
GAP is about helping developers already familiar with XHTML-MP
which features they should give up in order to be confident that
their content will be accessible on a "non brain-damaged" XHTML-MP device.
As you see, this is virtually a definition of LCD.
GAP takes an extra step, though. It provides practices about
what you should do and what you should not do to
avoid mistakes which yield the highest chance to make your application
fail. Mark-up is one aspect. Usability and a bit of business intelligence
are other aspects which are also covered by GAP.
But there is more about LCD that you should know.
If the Netscape vs Internet Explorer war looked bad, I have bad
news for you: the situation in mobile is a couple of order of magnitude
worse. Not only are there at least a dozen browser vendors, but the devices
on which those browsers are installed have different screen sizes,
different colors, different navigation mechanisms (think stylus vs
2-way rockers).
LCD may have been acceptable in 1999 for web browsers, but is it good
for mobile authoring? That's an excellent question and the answer
may vary depending on who you ask. My answer is "probably not", but
keep reading, because there are quite a few things
to explain. Another question you may have is "Is there an alternative
to LCD?". The alternative exists and it is called "Adaptation".
What about Adaptation?
======================
A short explanation of adaptation first: imagine you have an application
that displays pictures on mobile phones. Also imagine that all the devices
you need to support have screen-widths between 120 and 145 pixel .
You apply LCD and create pictures which are not larger than 120 pixels.
All devices will read it without distorsion (even though some devices will
get some extra white space at the sides). Your customer is happy. That is
until the day when some new cool device with a screen of 320 pixel width
is introduced on the market and your customer is not satisfied with that
120 pixel wide "stamp" in the middle of the screen.
Since you are the smartest developer around, you come up with a trick.
You let your program analyse the HTTP headers of the request to your service.
You recognize requests coming from a 320-pixel device and you write a
program that will provide a larger version of the picture to that device.
Congratulations. You have just discovered "adaptation". You are
effectively adapting mobile content to the capability of that device.
A simpler example of adaptation could be one where you manage
to programmatically tell XHTML-MP devices from legacy WML devices
and you redirect requests to one of two mobile sites: WML and XHTML-MP.
Without going too much in detail about the different
"adaptation" techniques, google for "WURFL" and you'll find plenty
of info about what people are doing today in order to
create mobile content that suits the largest possible number
of different devices. But let's go back to the LCD and ask
ourselves: if LCD is so bad for mobile and an alternative (adaptation)
is available, why am I caring about LCD?
I have a good answer, but let me say this loud and clear:
* if you are not doing some adaptation of some kind *
* in your mobile application you are in the *
* reign of absolute beginnerdom. *
* Your application may be good enough to show *
* friends, but hardly anything more than that. *
Reality is that success in the mobile business
implies understanding the capabilities of devices and it implies
building applications that "multiserve" content tailored to the
capabilities of the requesting devices.
If you suspect that adaptation seems complicated and requires
time and knowledge, you are right: adaptation is expensive.
Since adaptation is expensive, you are bound to have developers
who cannot afford to adapt their content, yet they want to move
the first steps in mobile development. For those developers,
once they are clearly told that they should do adaptation,
the GAP document is some kind of survival kit which may save
their work in the rough seas of mobile development.
Also, while providing advice for LCD, GAP will build awareness
of why adaptation is important and and make sure that
GAP itself does not end up promoting LCD authoring.
Defining the baseline (AKA, What's an XHTML-MP client?)
=======================================================
One minute ago, I mentioned "non brain-damaged XHTML MP devices".
I am sure that some readers thought "Not so quick, kid!".
After all, 'non brain-damaged' is not a very formal definition of the
actual capabilities of a device browser.
The fact is that, once we have in some way decided to ignore WML-only
devices, we have implicitly already restricted the set of devices we
are interested into. Should we stop here and accept the idea that any
device that claims to support XHTML-MP content will have to display
content authored according to GAP?
Quite frankly, I don't think this is a good idea. I could mention
a few black&white XHTML-MP devices that did not support either GIF nor JPG.
You probably don't want to deal with those, or the LCD philosophy
would force you to avoid colored pictures of any kind.
I could also point to early XHTML devices that could not display
a picture and a link on the same line. Dealing with those would
mean to restrict LCD even further just to include support for
obsolete devices that you no longer find very frequently around.
Raising the bar a bit is obviously the way to go.
Of course, you don't want to raise the bar too much either. If we were
to say that only devices with 320x200 pixel displays, WiFi connection
and the Safari browser matter to us, than we would be restricting
ourselves to less than 1% of mobile devices. We need to draw
a line somewhere a lot lower. But where exactly?
Introducing the concept of a "baseline" device is useful here.
Sort of arbitrarily, I would say that the following
capabilities are the right compromise between
selecting a wide enough range of modern devices, while avoiding
supporting legacy WAP 2.0 devices from 2001/early 2002 which
represented more of a proof-of-concept than a sound implementation
of the new XHTML-MP spec.
- XHTML MP 1.0 support,
- GIF and JPEG support,
- 256 color,
- 120x120 pixel screen or larger,
- basic support for tables (two columns,
no 'rowspan' support, no 'colspan' support),
- ability to display pictures and links on the same line
A device which supports the above features is a baseline device.
If you are familiar with W3C MWI (more about this later) this is what
they call DDC, or Default Device Delivery Context, even though
the actual parameters for their baseline are slightly different.
It is probably worth to remark that the above baseline is based
on my experience with mobile devices. While it probably represents
a decent default baseline in case you have no clue about
how to define a baseline for your application, the GAP
baseline does not assume that you may not know better.
For example, if you know your target devices,
it would make total sense to choose a default
experience based on your knowledge of the phones most
commonly in use in your domain/region. An extreme example of this
would be a 'vertical' application, such as all of the employees
of your company equipped with the same device (or family of devices).
In this case, LCD would be much more effective. A less extreme
example would be a CDMA operator with a well-defined (limited)
device portfolio to care about. Still many devices, but not
as varied as in GSM (the toughest scenario for mobile authors).
To recap, we have explained what Least Common Denominator is,
we have explained that LCD will not bring a mobile application
anywhere near excellence (but adaptation could), and we also have
defined which devices you need to care about to avoid that LCD
will drag you down where it makes no longer sense (or,
alternatively, where you would be better off with WML).
We are not done yet. If you are one of those
who follows the evolution of the mobile distance from close,
you may know about related efforts by W3C in the same area.
In that case, I am sure you have a bunch of extra questions.
What about W3C Best Practices and Mobile OK?
============================================
W3C launched the MWI Best Practices (BP) effort in 2005
to achieve what is apparently not very different
from the objectives of GAP. What's the relationship
between GAP and BP?
When I said that GAP is an "independent set of guidelines"
for the mobile web, those familiar with W3C's Best Practices (BP)
for the mobile web [1] may have objected. After all, isn't GAP
very similar in scope to the W3C Best Practices?
The answer is "yes". I'll tell you more. I, the author of
this document and the editor of the initial
GAP draft, was also part of the BP Working Group (and technically,
I still am). To make a long story short, the work carried out
by W3C is the result of the contributions of the many
entities involved in the project. I won't bore you with the
story of how MWI's Best practices have evolved in over one
year of work, but I will just say that it appears to me as a manual
example of too many cooks spoiling the broil. So, I decided
to create GAP and open it for contributions from the people
to whom the guidelines really matter: developers.
Personally, I decided that BP was not ammendable. There
was more than one or two practices I disagreed with, so I
will spend a few words to comment on some of the MWI
practices that failed to impress me (yes, I am putting
it mildly :).
What is wrong with W3C's Best Practices?
========================================
If I had to point to the largest issue with W3C's BP, that
would have to be the "One Web" postulate. I understand that W3C
is all about the web and some may dream about a unified web
which can be accessed with equal ease by PCs and mobile devices,
but this is just a dream: web and mobile will remain separate
media for many many years to come (probably more).
There are three big reasons for this: technological,
consumer-driven and industry related.
*Technological*: Even with the high-end devices, it is going
to be a never ending catch up game between mobile and the
PC browsers. Nobody has ever managed to catch-up with the
mobile internet, while keeping the form factor of a phone.
Look at your parents' mobile phone and guess why.
*Consumer-driven*: if you ask your average technology-savy
mobile phone user whether they would like to have the
full Internet on their device, you'll most certainly
get a positive answer. The problem is that this is not
true in most cases. Even when provided with high-end devices
which are potentially able to go on the web, consumers
will still prefer to wait until they get home or reach
their workplace before they go access the full internet.
Mobile portals (i.e. portals tailored for mobile devices)
have a much higher chance to be accessed frequently because
they are fast and the information there is precise and
to the point.
*Industry*: it's not easy to make money with the internet.
In the age of 15 Euros a month ADSL flat-rate, making money is
hard. But mobile phones are different. Telecoms know who the
users are, they know how to bill them and they want to exploit
the possibility of selling those wallpapers at 4 euros each
by exploiting the impulse of their average subscriber.
We are talking about an industry that is not convinced at
all that a converged web-mobile experience is the way to go.
In summary, the mobile web today and the big web are
separate entities with similar mark-ups.
I will now delve into the gory details of what is wrong with
some of the BP practices, if you are in a hurry or you
don't like controversy, just skip the next few paragraphs.
One Web
-------
With MWI, W3C is trying to unify the web with mobile
by going the opposite direction of the industry:
they "postulated" that the web is one and asked W3C members
to figure out practices that would make that happen.
Nice try, but that's not how it works!
Unfortunately, though, a lot of BP builds on top
of "one web".
are we talking web or are we talking mobile?
--------------------------------------------
For example, BPWG would not specify whether the practices
are meant for web authors or mobile authors. My point is
that you can't provide guidelines that apply
to both, just like you can't provide practices that apply to the
manufacturing of bicycles and cars alike. The attempt
to sweep this distinction under the rug just makes the whole
Best Practice document incredibly confused.
not enough emphasys on adaptation
---------------------------------
Adaptation is yet another aspect that the Best Practice W3C
working group (BPWG) failed to address properly (also a victim
of "one web"?). As I wrote, and virtually all professionals in the
mobile space agree on this, adaptation is key to delivering a
decent user experience on a varied set of devices. Of course,
the GAP document is also about LCD, but at least we spell out
clearly that adaptation is key and that LCD is just some kind
of survival kit. More than this, when GAP practices are explained,
we never fail to point out how the application could be improved
by adapting headers, mark-up and pictures to actual device
capabilities. W3C's BPs are delivering an inconsistent
message to the reader. The general message is that
one should stick to a well-defined set of rules
for authoring (which, in turn, leads to LCD). At the same
time, though, some practices do mention that an application
could do something different if more info is available about
actual device capabilities (don't use tables unless...,
exploit device capabilities..., etc...). The result is
a document that simply ends up confusing ideas.
If you don't believe me, just try for yourself [1].
XHTML MP 1.0 not good enough
----------------------------
Have you ever heard the expression"Not Invented Here"?
Quoting from WikiPedia [2]:
"Not Invented Here (NIH) is a pejorative term used to
describe a persistent corporate or institutional culture
that either intentionally or unintentionally avoids
using previously performed research or knowledge because
the research and developed knowledge was not originally
executed in-house."
I think this perfectly applies to W3C refusing to acknowledge
XHTML-MP 1.0 as the standard supported by the majority of
mobile devices produced over the last 4 years. The reason
for this is that XHTML-MP is the creation of OMA and not
theirs. They prefer to go for a non-existent XHTML Basic 1.1
(current version is 1.0) which has no implementations at present,
rather than allowing XHTML-MP. Taking the words from one of
the BPWG members, I think it's perverse. A terrible doubt:
is this another victim of "one web"?
Thematic consistency
--------------------
There is certainly not a doubt that One Web was here too.
There is a written confession ("This is a realization of
the One Web."[3]). The idea is that if I find a cool website
and I send the link to my friend who tries to access it
from her mobile phone, she should manage to get
the same content. This is a lot of extra work to do,
particularly if one doesn't have adaptation in their toolbox.
But there is something more annoying for me about this practice.
The accompanying text reads:
"If the page that was bookmarked is not appropriate for the
device that is now using it, an alternative that
is suitable should be provided"
So, if your service has a link to a site to download MP3, but
you automatically hide the link to a device which does not support
MP3, than you are not respecting the Best Practices.
Supporters of this practice actually say that a sentence
like "Sorry, your device does not support
MP3" would be enough to comply. The problem is that
valuable screen space is wasted (and more clicks are
required to navigate past those lines) for no value
to the end user. Far from being a best practice,
this is a bad practice. And don't even get me started
on 'practices' that interfere with the business model
of the service.
Error Messages
--------------
This best practice is almonst reasonable.I say almonst because
not all errors are in the developer domain to trap before
they turn into an error on the device. What if the operator's
gateway is down? does this make my application not compliant to
best practices? I suggested they add "...whenever possible"
to no avail.
Don't use frames, pop-ups, plug-ins etc...
------------------------------------------
There is obviously nothing wrong with these practices, except
that it makes one wonder why they did not add "do not drop
devices in the water", "do not expect that your cat knows how
to operate a phone" and so on...These practices assume that
the reader is a potential imbecile, which makes the BP document
inconsistent in style and sort of frustrating to read.
Navigation Bar
--------------
Did you know that the top 4 links in a site (those that
typically do not require scrolling to activate) get
clicked about 80% more often than other links?
And what about those 2 or 3 extra clicks to go past
links that simply stay in the way?
This is called usability, honey, and that navigation
bar of yours is a hindrance to the users of the service.
Having a navigation bar at the top of a mobile site
is nothing short of a bad practice
Did you remove the whitespace from your mark-up?
------------------------------------------------
One of the BP practices that has IMO defied the danger of
getting the whole initiative ridiculed is the so-called MINIMIZE [4]
which demands that developers and authors strip their mark-up
(either static or dynamically generated) of excessive whitespace:
"While it is not intended that authors should create their
content in a single line to remove white space altogether,
it is suggested that authors should not contribute to page
weight by introducing unnecessary white space. Note that
"pretty printing" (the formatting of markup with indentation)
can generate large amounts of white space and hence
add to page weight.
If "pretty printing" is an important part of the authoring
process, then try to arrange that redundant white space is
stripped when serving a page."
If you have ever developed a mobile site (or even just a web
site with a back-end component), you know that this BP
makes no business sense. To be fair to BPWG members,
a lot of them made it clear that whitespace is
very often a by-product of the application, and forcing
people to remove it would impact development and
maintanance costs in non-neglegible ways.
Also, the extra cost introduced by whitespace in terms
of user experience is so neglegible that it is virtually
impossible to measure. The argument of volume-billing is
also bogus to a very large extent. Yet, some other members
keep pushing the notion that :
bloat cannot be good and nobody disagrees on it,
so
bloat must be bad and there is consensus,
so
MINIMIZE should stand.
What to say? I am curious to see the end of this soap opera.
do not auto-refresh
-------------------
At first sight, this practice may not make much sense.
After all, I may need to refresh a page for
a chat application, or just to check whether the
user has received a new message in their
inbox. What's the point in having this practice?
the answer is not simple to figure out unless
you have followed the BPWG work closely: There is
yet another ingredient to the W3C minestrone.
The ingredient is WCAG, the W3C
recommendations that tells people how to make web sites[5]
usable to people with disabilities. The "no auto-refresh"
practice maps directly to one WCAG point [6].
The job for authors of mobile services is already
hard enough when trying to make those services
usable to people without disabilities, but
that's not even the point here. In this particular
case, it remains to be demonstrated
that the lack of auto-refresh makes the site harder
to use for people with disabilities. Practices should
be derived by practice, not by higher-goals. I don't
think it's fair that someone tries to infer what practices
should be out of ideology (no matter how well-meant
it may be) and force it on professionals that are
trying to do their work.
Abstractly speaking, I would not oppose the idea
of someone creating mobile-internet guidelines
for people with disabilities, but one
step at the time, please. We need to figure out how to
make the mobile web work for everyone else first.
MobileOK
--------
The motivation for some of the practices is to be the basis
for what they call the "MobileOK Trustmark"[7]. The idea is that
adherence to a certain standard of quality for mobile sites
should be 'claimable'. Some can claim adherence themselves through
the W3C checker, while others may buy a stronger claim (i.e.
some kind of certification) from a commercial
entity. The problem for these entities is how to certify
a mobile site without a solid set of rules to compare against.
This is what BP is also about: writing down
the rules according to which MobileOK tests can
say if a site complies or not.
Generally speaking, I think certification is a legitimate business
model. But there is a problem in this case. Certification entities
should struggle to build practices that make sense, not
just engage W3C (which has not had much
to do with mobile so far) to make it grind out anything
with the W3C stamp on. After all, there are developers
out there who apply great effort to build usable sites.
Disrupting their work with *bad* practices just because
you need a list of rules of some kind in the
shortest possible time has something
unethical to it. It's like burning down your
neighbor's house because you want to make eggs
and bacon.
A camel is a horse designed by committee
----------------------------------------
Quoting from my precious WikiPedia again [8]:
"Design by committee is a wry, derogatory term referring
to the style of design that sometimes results when
a group of entities comes together to produce something,
particularly in the absence of good leadership - roughly
equivalent to the age-old expression, "too many cooks
spoil the broth". Its defining characteristics are
needless complexity, internal inconsistency, banality,
and the lack of a unifying vision."
Amen. I am sorry to say that the W3C BP document is a clear
example of this. Which is a pity, because
developers and content authors are the target audience
for this kind of documents and BP was the opportunity
to create something valuable for them. In reality,
BP may well end up being more of a hindrance than
a support for mobile developers and people aspiring
to become such.
No worries, though. GAP is coming to the rescue.
Global Authoring Practices for the Mobile Web
=============================================
For one important thing shall I be grateful to W3C.
Partecipating in BPWG has allowed me to focus on what a
set of practices should be and what it shouldn't be.
GAP reflects this by avoiding that irrelevant motivations
play a negative role in moulding guidelines which
are supposed to improve the adoption of mobile.
I chose the name "good practices" rather than "best practices",
because GAP is about LCD, and LCD cannot be best.
Best is what you get with adaptation.
All of the practices are based on facts. And the
facts that matter are those about:
- the quality and the quantity of mobile devices
available on the market.
- the nature of mobile development and development
tools and frameworks
- the best possible user experience one can get without
adaptation.
In addition, the explanation of each practice points to
adaptation, to stimulate developers who may wish to bring
their mobile application one step further.
If you are a developer and you want to get involved with mobile,
GAP is a great way to start.
Conclusions
===========
At this point, you should have a clearer view of
the motivation behind GAP. There are many actors in
the mobile arena. Everyone is trying to do the best
for themselves, but little is done for the community
of developers in the widest sense. W3C had a great
opportunity, but, in my opinion, they blew it by
letting too many external requirements and political
decisions play a role in the definition of
the actual practices.
GAP does its best to serve the community and stimulate
the growth of the mobile web, independently
of the interest of specific companies, but ultimately
in everyone's interest.
Luca Passani
References:
[1] Mobile Web Best Practices: http://www.w3.org/TR/mobile-bp/
[2] NIH: http://en.wikipedia.org/wiki/Not_Invented_Here
[3] Thematic Consistency: http://www.w3.org/TR/mobile-bp/#tc
[4] Minimize: http://www.w3.org/TR/mobile-bp/#iddiv373138648
[5] WCAG (W3C Accessibility Guidelines)
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html
[6] WCAG: No Periodic Auto-Refresh
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-no-periodic-refresh
[7] Mobile OK: http://www.w3.org/TR/mobileOK/
[8] Design by Committee: http://en.wikipedia.org/wiki/Design_by_committee