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

[Sorry for the duplicate]

  Dear Zev Blut ,

The Mobile Web Best Practice Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Mobile Web Best
Practices 1.0 published on 13 January 2006 Thank you for having taken the
time to review the document and to send us comments!

This message holds the disposition of the said comments on which the
Working Group has agreed. This disposition has been implemented in the new
version of the document available at:
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/

Please review it carefully and let us know if you agree with it or not
before 3 May 2006. In case of disagreement, you are requested to provide a
specific solution for or a path to a consensus with the Working Group. If
such a consensus cannot be achieved, you will be given the opportunity to
raise a formal objection which will then be reviewed by the Director
during the transition of this document to the next stage in the W3C
Recommendation Track.

Thanks,

For the Mobile Web Best Practice Working Group,
Philipp Hoschka
Dominique Hazaël-Massieux
W3C Staff Contacts

 1. http://www.w3.org/mid/43F59775.1040104@ubit.com
 2. http://www.w3.org/TR/2006/WD-mobile-bp-20060113/


=====

Your comment on 1.4 Default Delivery Context:
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.

Working Group Resolution:
We decided not to include the screen height because:

* research showed that even being able to view only a few lines (4) was
sufficient for a reasonable user experience

* we didn't want to fix the aspect ratio

----

Your comment on 2.2 
Input:
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?

Working Group Resolution:
The "back button" is not mandated by any of the specifications that
defines the default delivery context, and in particular, there doesn't
seem to be any evidence that any device supporting XHTML-basic would
feature a back button.



As such, we have kept our text regarding the back button as is.

----

Your comment on [DEFICIENCIES] Take ...:
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?





Working Group Resolution:
We say that this is relevant when the device does not respect the author's
intentions.

----

Your comment on [URIS] Keep the URIs...:
What does the group consider a proper range for short URLs?

Working Group Resolution:
No specific values have been defined for lengths of URLs because it was
felt  that specifying precise value might in practice prove too
restrictive

This BP should be interpreted as meaning if you have the choice between

http://subdomain.example.com/mobile/home/index.html

http://example.com

as the access point for your site you should choose the shorter one, which
we have tried to clarify through additional examples.

----

Your comment on [NAVBAR] Provide min...:
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.

Working Group Resolution:
We have clarified that only a few links should be placed at the top of the
page, leaving the rest of the navigation links to the bottom, and added a
note to the effect that user should be able to see the content of the page
without scrolling.



----

Your comment on [CENTRAL_MEANING] En...:
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.

Working Group Resolution:
This is a WCAG checkpoint and a fairly common usablity rule.  Put the
important stuff first.



Note that the Best Practices and the mobileOK trustmark, while related,
are different and it is not defined yet which best practice will be
included in the definition of the trustmark.

----

Your comment on [NON-TEXT_ALTERNATIV...:
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

Working Group Resolution:
The DoCoMo way of doing this is in the spirit of this BP i.e. the user
will receive an appropriate message if his or her phone does not support
the OBJECT tag, but we agree that the Best Practice was a worded a bit too
restrictively.



We have changed the wording of the Best Practice to:

[OBJECTS_OR_SCRIPTS]

Do not rely on embedded objects and/or scripts.



----

Your comment on [IMAGES_SPECIFY_SIZE...:
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.

Working Group Resolution:
We have clarified that specifying the intrinsic dimensions of an image
allows that the browser doesn't have to re-flow the page in the course of
displaying it (re-flowing creates usability problems due to changes of
focus, and also may have a bad CPU/battery impact).

----

Your comment on [ERROR_MESSAGES] 
Pr...:
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.

Working Group Resolution:
Good point but clearly the content author can't do anything about this
User Agent deficiency





----

Your comment on [COOKIES] Do not use...:
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?

Working Group Resolution:
We have clarified that we really meant "do not rely on cookies being
available"; i.e. it is indeed fine to make use of Set-Cookie to determine
if the phone support cookies.

----

Received on Wednesday, 12 April 2006 17:13:58 UTC