Comments on the Mobile Web Best Practices 1.0 (W3C Working Draft 13 January 2006) document

Hello,

I would like to offer a few comments regarding the Mobile Web Best 
Practices document. Below is a list of section numbers of the related 
items in the document with my comments and questions.

1.4 Default Delivery Context
There is an entry for screen width, but not height. I think that there 
should be some value for a default screen height.

2.2 Input
Discusses the potential lack of back button support, but in section 1.4 
the default device supports XHTML- Basic. Is it not reasonable that if 
the default is assuming XHTML-Basic then the target default handsets 
have back buttons?


5.1.3 Work around deficient implementations
“It is recognized that content providers may need to violate specific 
best practices in order to support their intentions on devices that 
exhibit deficiencies in implementation. If a device is not known to have 
specific limitations then content providers must comply with best practices”

My question is the use of “must comply” is a bit strong, because there 
can be cases where developers and the W3C differ in opinion on whether a 
certain device has limitations. In areas where interpretations differ 
this may prevent the developer from getting the “mobileOK” mark. Who and 
or how are agreements going to be made about when a device is known to 
have specific limitations?

5.2.1 URIs of Site Entry points
What does the group consider a proper range for short URLs?

5.2.2 Navigation Bar
I am not quite certain if having a navigation bar on the top page and 
having the navigation links on the same line is really a best practice 
that I agree with. Perhaps providing a definition or example of what a 
navigation bar is for a mobile site would help those who disagree with 
this. In many cases having navigation items like home and back links of 
the top of the page distracts the user from viewing the content that the 
user is currently looking for. The user must skip through a number of 
links before getting the view the content, which is not desirable in 
some cases. In such an example I think that having the navigation bar at 
the bottom is preferable when the user has found the searched for 
content. Although, in the case that the current page is not what the 
user is looking for having the navigation at the top is certainly 
better, for the quickness of getting out of the page. Perhaps this 
section could use a bit more explanation. This may be a difference of 
interpretation depending upon the if the handsets force the user to 
traverse each link or can skip links that are on the same line.

5.3.4 Navigation Bars etc.
This is a good idea, but it makes me wonder how possible the one web 
vision becomes. If one wants to create a page that can provide an 
optimal display, the developer would need to do quite some work or use a 
powerful platform. I fear that some developers may give up trying to get 
the mobileOK mark if it becomes too difficult.


5.4.5 Non Text Items
The way that current i-mode handsets deal with handsets that cannot 
support the object tag differs from this recommendation. This may make 
many i-mode sites break the best practices rules. You can refer to the 
following link for more detail:

http://www.nttdocomo.co.jp/english/p_s/i/tag/object.html

5.4.6 Image Size
[IMAGES_SPECIFY_SIZE] Are there actual examples where not setting the 
width and height of an image actually hurts the display of the image by 
the browser? I am not so sure how necessary this is, especially when 
considering that providing this information increases the size of the page.

5.4.13 Error Messages
This is also a great idea, but some handsets ignore the developer’s 
custom HTTP 5xx response and shows a built in error message to the user.


5.4.14 Cookies
Does this prevent systems that make use of Set-Cookie to determine if 
the phone supports cookies from getting the mobileOK mark?

That is all of my comments. Thank you for your time.

Zev Blut

Received on Monday, 20 February 2006 09:40:02 UTC