FW: Feedback on MWBP 1.0

Tony

Many thanks for your thoughtful feedback and sorry it has taken so long to
reply.

Comments in line below.

Jo
(co-editor)

> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of TC
> Sent: 03 November 2005 23:14
> To: public-bpwg@w3.org
> Subject: Feedback on MWBP 1.0
> 
> Hi all,
> 
> Coming from a perspective of user centric design can I make the following
> comments...
> 
> 1) I can't see any reference in the document to any customer based
> research,
> surely it would be better to ask actual users of mobile devices about
> their
> experiences and desires for best practice are going forward? Otherwise we
> run the risk of defining what experts within the industry think is best,
> not
> what users think works.

Yes, it's true that the work is based on secondary research and the opinions
of 'experts'. Having said that, those opinions are hopefully informed by
research that their organizations have carried out. In addition, some
organizations, including the one I represent, are planning to put their
research into the public domain.

> 2) Secction 5.2.5, Error Messages - you state at the start of the document
> that you want to try and encapsulate things that are specific to mobile
> experience, therefore while i completely agree that 'useful' error
> messages
> are great this is surely a web design guideline?

Yes, agree with your point that this is in fact a general good practice.
However, it is of particular importance in the mobile area, given the
difficulty of contextualizing, the absence of a 'back' button in some cases,
and the difficulty of re-entering URLs to start over.

> 
> 3) 5.2.6, Testing - how many devices are now in captured inWURFL and how
> many devices are launched each year (with subtly diff version evolving
> over
> a device lifetime) - so how useful is a statement like..
>  - Consequently testing should be carried out in as wide a range of real
> devices as is practical
> Shouldn't there be some push to the device manufacturers/browser
> developers
> to help with by standardise]ing where practical?

Yes, very much so. There's more to this food chain than just making mobile
friendly web sites: including conformant browsers, and transparent network
paths. We've not forgotten this, but are addressing the web sites first. You
have to start somewhere!


> 4) 5.3.2 - Provide a Site Map - web based site maps can be very useful,
> but
> a large site map on a mobile device... just a long list, hardly good user
> experience.
> 
This statement is under active consideration - thanks for your feedback.


> 5) Use a small graphic at the top of the page to illustrate what site the
> user is on and where on the site they are at
> This contradicts the point about not using graphics where text would
> suufice
> - it seems to be referring to some form of breadcrumbing navigational aid,
> which is surely better as text anyway. If a graphic were to be used we'd
> need to educate users on what it's trying to tell them.

Yes, we need to be clearer on what we mean. Thanks for the feedback.
> 
> 6) Most of the points re Navigation are just good web practice (though of
> course that doesn't mean you see it on the web either), wouldn't it be
> simpler to refer out to perfectly good sources for these (Jacob Nielsen
> seems the most obvious - in fact wouldn't he be a good addition to your
> group?)

Again, it's of particular importance in the mobile area which is why they
are called out here.

Jacob Nielsen would be more than welcome in the group which as you say would
benefit greatly from his presence.  Same goes for other well-known and
highly regarded individuals. That's not to say that the current membership
of the group is a bunch of dummies of course.

> 7) 5.4.7 Color - Interesting one here (and in a few other places) as
> clearly
> they you are rightly conscious of the visual impairment issues (>30% of
> people have some form of limitation) but isn't a better way to address
> this
> within the guide to suggest use of  'Graphics lite', 'Accessible' or 'High
> Contrast' menu option... and what should happen if the web source has such
> an option already, as many do?

The point about this is less an accessibility point but more that the mobile
device is often used in hostile lighting conditions.

> 8) 5.5.2, Frames, 5.5.4 Tables etc - Guide says Don't use these (agree re
> frames) and also dont use 1x1 gifs to control layout - BUT do use CSS when
> a
> device supports it - so if a device doesn't support CSS we should not use
> any other device to provide a 'nice' layout? This seems a somewhat
> limiting
> best practice.

Yes, thanks for this. My view is that we specify a baseline device because
we need to rely on some level of support for various things including CSS.
If you are delivering to a device that doesn't meet the baseline spec then I
guess the position would be that you should stick to the recommendations
where possible. 

In fact the second statement in 5.2.2 does explicitly say that you should
work around deficient implementations. Perhaps we should think about
enhancing the wording to make it clear that when all else fails you should
try to provide a useful experience using whatever means at your disposal.
Just my opinion for now.

Thanks again for your helpful comments. Which we value.

Received on Tuesday, 22 November 2005 13:55:57 UTC