- From: <dom@w3.org>
- Date: Wed, 12 Apr 2006 17:05:08 +0000 (GMT)
- To: Ian Jacobs <ij@w3.org>
- Cc: public-bpwg-comments@w3.org
[Sorry for the duplicate]
Dear Ian Jacobs ,
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/1139848085.29752.36.camel@jebediah
2. http://www.w3.org/TR/2006/WD-mobile-bp-20060113/
=====
Your comment on Abstract:
Please start early with the "One Web" message, for example by adding
something like this to the end of the preceding sentence: "An important
Web design principle (discussed, for example, insection 4.3of
"Architecture of the World Wide Web") is to design content that is
flexible enough to enable a valuable user experience for a variety of
devices. This document explains how to design for "one Web" while also
optimizing for the mobile experience."
Working Group Resolution:
We have elevated THEMATIC CONSISTENCY to the most prominent in the
document and hence have given it the precedence it deserves.
----
Your comment on 1.1 Purpose of the Document:
What does "in context" mean?
Working Group Resolution:
We have removed the incriminated sentence.
----
Your comment on 1.1 Purpose of the Document:
I suggest merging the previous two paragraphs; I otherwise was unsure
about the mobileOK trustmark in the paragraph where it was introduced.
Working Group Resolution:
The paragraph boundary was indeed unnecessary and we have merged the two
paragraphs accordingly.
----
Your comment on 1.3 Scope:
A very important feature of the WAI Guidelines is that they work together
to identify different responsibilities among authors, user agent
designers, format designers, and authoring tool designers. WCAG does not
hold up well in some cases when browsers don't take advantage of features
that authors expect to be supported. Does the MWI BP WG plan to produce
other guidelines than these content guidelines?
Working Group Resolution:
In the document we refer to Techniques and MobileOK which are currently
being written. We can also imagine adaptation guidelines but we are not
sure of the exact course. There's also a new User Agent test initiative
but it hasn't started yet so we can't reference it.
----
Your comment on 1.3 Scope:
I suggest "This document only includes best practices that primarily
affect mobile access to the Web." You may also wish to have a look at some
of the verbiage insection 3of UAAG 1.0 (on Conformance). For instance,
adapting this text might be useful: "The UAWG expects conformance this
document to be a strong indicator of accessibility, but it may be neither
a necessary nor a sufficient condition for ensuring the accessibility of
software. Thus, some software may not conform to this document but still
be accessible to some users with disabilities. Conversely, some software
may conform to this document but still be inaccessible to some users with
disabilities. Some requirements of this document may not benefit some
users for some content, but the requirements are expected to benefit many
users with disabilities, for general purpose content."
Working Group Resolution:
We feel that this is not required, as the document is informative. The
work on conformance (and the related disclaimers) will be done in the
mobileOK trustmark document.
----
Your comment on 1.3.1 Phasing:
The first reference to "phase of work" is confusing. Does it mean "phase
of this WG?" or "phase of this document"? Please clarify. It may be
described in [Scope], but I think you need to provide a short summary of
what "phasing" means or of what the phases are.
Working Group Resolution:
We have expanded the consideration on phasing and have added a mention of
the expected longevity of the document.
----
Your comment on 1.3.2 Usability:
The terms "easily" and "efficiently" are almost unused in the document. In
my opinion that do not add much information where they are used and might
be safely deleted from this part of the document and from the best
practices below.
I suspect this entire section could be reduced without significant loss of
information to the following:
The quality of the user's Web experience via a mobile device depends
significantly on the usability of Web sites, of browsers, and of the
device itself. Although browser usability (for reading, navigating, and
interacting with content) and device usability are important, this
document focuses primarily on best practices for improving site
usability.
Working Group Resolution:
We agree and we have integrated your suggested rewrite in the section on
Phasing, having removed the section on usability as such.
----
Your comment on 1.3.3 One Web:
"From the perspective of this document this means that services should be
available as some variant of HTML over HTTP."
Why is the previous statement here? It sounds like it is an assumption
about delivery and belongs in the next section.
Working Group Resolution:
Yes and no: yes, HTTP has been added in the default delivery context --
but no, it also belongs here -- as a clarification of what "One Web" means
in the context of this document.
----
Your comment on 1.3.3 One Web:
What does "perhaps" mean here?
Working Group Resolution:
We have replaced perhaps by "for example" and "for instance".
----
Your comment on 1.3.3 One Web:
The document says "as far as is possible." When is it not possible? I
think you can safely say that it is considered "best practice not to
exclude access." You don't have to add disclaimers. If there are specific
cases that you are thinking of (e.g., there may be privacy or security
reasons), please call them out rather than say "as far as possible." I
make similar comments below.
Working Group Resolution:
We have reworded this to read "not to exclude access from any particular
class of device, except where this is necessary because of device
limitations."
----
Your comment on 1.4 Default Delivery Context:
The first sentence confused me because the title of the section includes
"context" and the first sentence includes "content". I thought it was a
mistake at first. It might help to say very quickly that there are two
things discussed; context and content.
Working Group Resolution:
We have reworded the introduction to the default delivery context section
and think it sets now more clearly what concerns the content and what
concerns the device/context.
----
Your comment on 1.5 Relationship to other best practices and
recommendations:
As you'll see below, I think you may wish to refer to some of the guidance
of theUser Agent Accessibility Guidelinesas well.
Working Group Resolution:
We are talking about site usability rather than user agent or device
usability, so refering to the User Agent Accessibility guidelines is out
of scope (and could possibly create confusion).
----
Your comment on 1.6 How the Best Practices are Organized:
I find "pointer to" to be very informal.
Working Group Resolution:
The incriminated text has been removed.
----
Your comment on 1.6 How the Best Practices are Organized:
I think "Appendices" is more common than "Annexes" in W3C specs.
Working Group Resolution:
We have replaced "annexes" by "appendices".
----
Your comment on 2.2
Input:
I think the problem is that it's hard to type, period. People should not
be typing URIs anyway; they should be using search engines and following
links.
Working Group Resolution:
The fact is there remains occasions where the user may have to type a URI
(e.g. a not yet indexed site, a non-linked from the outside intranet,
following an ad seen on a bus, ...) and that this has proven to be a
difficulty to get people even trying to use the Web on mobile devices, so
it's definitely worthy to be noted here.
----
Your comment on 2.4 User Goals
:
What is an "entertainment application"? Do you mean a game?
Working Group Resolution:
We have reworeded the paragraph to read:
"Equally, mobile users are typically less interested in lengthy documents
or in browsing. The ergonomics of the device are frequently unsuitable for
reading lengthy documents, and users will often only access such
information from mobile devices as a last resort, because more convenient
access is not available."
----
Your comment on 2.6 Device Limitations:
I note that the previous concern also holds for many desktop environments,
including very common one likes in companies or libraries where people
often cannot install arbitrary software or configure their machines
freely. Is this even more frequent on a mobile device?
Working Group Resolution:
Yes, this is true. However, the contrast is that it is usually expected
that personal devices to be configurable; while the mobile phone is very
much a personal device, it's rarely configurable.
----
Your comment on 2.6 Device Limitations:
Does this mean that you will have best practices for error handling below
to avoid incomplete display or other problems?
Working Group Resolution:
We do have a best practice on the size of pages to send to a mobile device
to avoid this memory limitations problems.
----
Your comment on 2.7 Advantages:
"As an illustration of some of these factors: First, unlike the fixed Web,
the mobile Web will go where you go. No longer will you have to remember to
do something on the Web when you get back to your computer. You can do it
immediately, within the context that made you want to use the Web in the
first place."
The previous paragraph needs to be adjusted. The text (which may have come
initially from the Communications Team!) suggests that there are two Webs:
one fixed and one mobile. That is not a message we want to communicate.
The point is that we want one Web and that we want to improve mobile
access to it.
Working Group Resolution:
We have changed the term to "Mobile Web access" to clarify that it's not
the mobile web but mobile access to the Web.
----
Your comment on 2.7 Advantages:
I am not sure what implicit user identification means. Also, it sounds
ominous to me, and therefore I'm not convinced it is always an
"advantage". Do you plan to address privacy concerns?
Working Group Resolution:
We have removed the reference to this aspect, as we agreed it's not always
something you get with mobile access.
----
Your comment on 3.2 Assumptions about Adaptation:
See also previous comment on "phase"; I suggest a link to where the term
is first explained.
Working Group Resolution:
We have added link to the discussion on the phasing of our work.
----
Your comment on 4.1 How the Best Practice Statements are Organized:
I think you can cut this entire section (4.1). The explanations do not add
more than the text in the <dt>. I find they are not necessary anyway to my
understanding of the document.
Working Group Resolution:
We have removed the section accordingly.
----
Your comment on [EXAMPLE] This is a ...:
There is an editorial problem around "by using URI reference composed" in
the previous paragraph. Also, I think you should use "URI: instead of "URI
Reference".
Working Group Resolution:
We have removed the wording altogether and have instead created a list of
the best practices with the links pointing to the relevant URIs.
----
Your comment on 5 Best Practice Statements:
In both WAI Guidelines and theWebarchdocuments I worked on, we found it
useful to provide short mnemonic labels for best practices and similar
statements. In Webarch, we created a navigation bar to the statements at
the top of the document (after the TOC), so people could access them
individually and rapidly.
Working Group Resolution:
We have resolved to keep the labels the same, but we have added a table of
BPs.
----
Your comment on [CONTEXT] Take all r...:
This point is problematic on several fronts:
* "Reasonable" is not well-defined. That term may work well in some
contexts (such as a patent policy, where people are used to it). I think
you should avoid it in this document. Alternatively, say once up front in
the delivery context section what you mean by "reasonable".
* I am not sure who is responsible for carrying out this task. Is this
the responsibility of someone who is producing content? It doesn't feel
like it.
* You say to do this for "any instance of an access." Even when there is
caching? It may be that in that case I haven't accessed the resource, but
I'm not sure of that, so it may be worth clarifying.
* This should not be the first best practice note --- this is about
content adaptation. I think it is important to start with the message:
Design for one Web! Then, talk about how to improve the user experience
above and beyond that.
* The statement seems overly general. What about saying something a bit
more specific, like "Follow published standards when determining device
capabilities for the purpose of content adaptation."
Working Group Resolution:
We agree that this best practice didn't fit very well with the rest of the
documents, and was more a general technique than an actual best practice.
As such, we have redistributed the text between some other parts of the
document as well as in the Techniques.
----
Your comment on [CAPABILITIES] Explo...:
* The word "exploit" seems like it is being used in the French sense of
"make use of". I find that in (American) English it carries a negative
connotation, as when one "exploits" a security hole.
* This statement is so broad that it should be dropped as a best practice
note. Instead, I recommend that you create a section a the top of the
document that explains what the best practices notes strive to allow
people to do. For example:
By following the guidance of this document, designers can:
* Learn to optimize their designs for delivery to a mobile device by
taking full advantage of device capabilities.
* ....
In short, this best practice note doesn't actually teach me anything
useful. Instead, I would like to learn from the document how to do the
thing you are talking about. I realize that there is an "abstract" layer
and a "techniques" layer and that the abstract point is to take advantage
of device capabilities, but I do not believe you have captured the right
level in the above note. Instead, if you are thinking of one or two
slightly more specific points, I recommend stating those instead of this
very general point.
Working Group Resolution:
* "exploit is the word used in the Device Independence authoring
techniques, so we prefer being consistent with them
* we think it is important to inform the reader that a good user
experience on a mobile devices needs most of the time to be adapated to
the device
* the techniques document is the place where the reader can learn more on
actual ways to learn about device capabilitiles
* we have also clarified that we mean more client capabilities than just
the ones required to implement the other best practices.
----
Your comment on [CAPABILITIES] Explo...:
Ah, that last sentence is already more informative in my opinion.
Working Group Resolution:
Capabilities has been removed
----
Your comment on [DEFICIENCIES] Take ...:
* Please delete "reasonable" (if you keep this one).
Working Group Resolution:
We think that reasonable is an appropriate word to use. We expect you to
try, but don't expect you to break your back.
----
Your comment on [DEFICIENCIES] Take ...:
* This can be a dangerous point if not worded carefully. See the
relatedprinciple in Webarch: " Agents that recover from error by making a
choice without the user's consent are not acting on the user's behalf." I
realize that in this context one may not always be interacting directly
with the user. But "silently recovering from error" is one of the things
that I believe the TAG feels strongly is a bad thing.
Working Group Resolution:
The "silently recovering from error" point is relevant to user agent
requirements which is out of scope. We believe the text already addresses
the issues you've raised.
----
Your comment on [DEFICIENCIES] Take ...:
* Below you say something more interesting, which I paraphrase as "It's ok
to not follow some of the other best practices in this document when you
need to work around errors." That's a big gate and you should strive to
narrow it. Furthermore, you seem to define conformance below "then content
providers must comply..." Does that statement belong in 5.1.3.1 or is it a
general statement that belongs in a conformance section?
Working Group Resolution:
We decided to keep the best practice as is, but we have added text to the
default delivery context to mention that no get-out clauses apply in the
default delivery context.
----
Your comment on [DEFICIENCIES] Take ...:
* In my opinion, unless you adopt something more along the lines of what
is stated below (a kind of "exception" provision for error conditions)
then I think you should delete this one, which, as stated, seems to me to
amount to "Do useful things." Again, the note has a very different impact
if you are talking about when it's ok to not follow _other_ good
practices.
Working Group Resolution:
We are writing for Web people who may not have realised that there is even
more variation in browsers on mobile than there is on the desktop.
We do indeed talk about when it is ok not to follow other good practices.
----
Your comment on [DEFICIENCIES] Take ...:
That last sentence is a good place to start for this entire document. But
there are other sentences that talk about One Web that might be pithier. I
think you can drop "as is practical" and all similar qualifiers in favor of
a section in the document about the general authoring context.
Working Group Resolution:
We think "as is practical" does convey the message that the Working Group
has in mind; note that this document is informative and aims at providing
guidance to authors, not imposing very specific rules - that will be done
in the mobileOK trustmark.
----
Your comment on [DEFICIENCIES] Take ...:
* How do you define a "deficient" implementation? It sounds quite
subjective to me. Do you mean implementations that do not conform
(strictly) to standards? Otherwise how would you classify something as
deficient or not? Do you mean "known bugs"?
Working Group Resolution:
We have added a clarification of the intended meaning of deficient:
"By deficient we mean non-support of mandatory features of a relevant
standard or recommendation and other bugs or errors in implementation."
----
Your comment on [URIS] Keep the URIs...:
I realize that you have chosen to write the good practice notes in the
imperative voice. I also realize that more information is provided below.
However, I think the reader might take away a lot more if the points
included more rationale. Any many people (including myself initially) may
simply look at the checklist and not take time to read the entire
document. For instance: "Short URIs require less effort to type, are less
prone to errors when typing them, and are easier to remember." In light of
my previous comment about short labels for the statements, you might end up
with:
[Short URIs Are Friendly] Short URIs require less effort to type, are less
prone to errors when typing them, and are easier to remember.
This is not much longer than what you have and I think the rationale
provided (likely imperfect as proposed) makes the statements much more
meaningful.
Working Group Resolution:
Generally speaking, we think the imperative voice better convey our
message across.
For the specific best practice on short URIs, we have added a explanatory
words and examples, but have kept the best practice mostly as is.
----
Your comment on 5.2.1.2 How to do it:
You say "how to do it" and then don't say how to do it --- you just say
"don't make the user do X." Instead, what about talking about how to
configure the server to do the right thing for index.html or similar?
Working Group Resolution:
We agreed with the weakness of the section and have added more detailed
advice on shortening URIs.
Meanwhile, we keep the specifics of configuring a server to that end for
the techniques.
----
Your comment on [NAVBAR] Provide min...:
* If you really mean "should be enough" then say "Provide between 2-4
links at the top of a given page for navigation to important parts of the
page." That seems to me to be more useful than saying "minimal
navigation." Find the 80% point, say it, and then let people adapt for
other cases as required (and explain to them when they might encounter
those cases). * In the same spirit as my comment on the previous point,
you might rephrase this as:[Navigation helps in small doses] Providing 2-4
links at the top of a page to important content in the page facilitates
navigation. Many more than that hinders navigation.
Working Group Resolution:
We have reworded the explanatory text about navigation bars, noting in
particular that the navigation bar shouldn't prevent the user from seeing
the core of the content.
----
Your comment on 5.2.2.2 How to do it:
If "The device will take care of wrapping" is true enough to be stated as
you have done, then add a best practice note: "Do not put explicit line
breaks in navigation bars because browsers on mobile devices will do the
right thing." or something more eloquent.
Working Group Resolution:
We have removed the incriminated sentence.
----
Your comment on [BALANCE] Design the...:
* Does "link on page" mean that it links to something on the current
page, or could it also be a link that points to a different page? * I
don't know what "balance" means here. I imagine it means "roughly equal to
in number," but it may not be about equality. * Does "depth of navigation"
mean "to other pages"? * Do you mean something like "Users tend to give up
if they have to follow more than 2-3 links in order to find something." * I
hoped I would understand this point better by reading the "What it means"
text, but the first sentence is confusing: it uses "navigation links" and
"navigate multiple links" as though they mean something different, but the
phrases are very similar.
Working Group Resolution:
We have substantially reworded the Best Practice on balance to clarify
that the balance was between the number of links per pages and the number
of pages the user has to download to go to his or her intended result.
----
Your comment on [THEMATIC_CONSISTENC...:
* You refer to "links"; do you mean "what you get when you follow the
link?" * I suggest expressing this point in terms of serving roughly
equivalent representations rather than in terms of links. * You might want
to citeWebarch section 3.5.1, which says "A URI owner SHOULD provide
representations of the identified resource consistently and predictably".
* Since this is the "One Web" point, I think it belongs at the front of
the document. You might want to retitle it "One Web Principle" rather than
"Thematic Consistency". * You might want to simplify to "[One Web
Principle] Because you never know for sure who will be reading your
content (and their device, browser, and human capabilities), you should
start by designing for a broad audience, then optimize your content for
targetted audiences."
Working Group Resolution:
We have changed the Best Practice to mention URIs instead of links, and
the text now refers to the Web Architecture principle.
We have not renamed it since the wording "thematic consistency" is about
the expected goal not the implied principle.
----
Your comment on [NAVIGATION] Use nav...:
* Because the word "use" suggests "user", I recommend making this sound a
bit more clearly like it is intended for authors. "Provide navigation
mechanisms that are consistent across pages." [If you mean something else,
then that's another issue.]
Working Group Resolution:
We have replaced "use" with "provide" as suggested.
----
Your comment on [ACCESS_KEYS] Assign...:
* Access key support on traditional desktop devices is problematic at
best. I do not know about the current state of support from the WCAG WG
for access keys (looking in the WCAG 2.0 techniques, I find only a
placeholder). Is access key support on mobile devices expected to be more
interoperable?
Working Group Resolution:
Yes, access key support on mobile devices is interoperable among mobile
devices and with some desktop implementations.
----
Your comment on [LINK_TARGET_ID] Cle...:
* You might want to shorten this and combine it with the next point as
follows:[Describe Link Targets] To help users decide whether to follow a
given link, provide this information about the target of the link: * What
it is, in clear language * How large it is (which may imply a
time-consuming download) * The file format (which the user may know is not
supported by the device). * I would note that in UAAG 1.0 we require the
user agent to provide some of these services so the author doesn't have
to; seecheckpoint 10.5. That helps address part of the goal of the
following point about "knowing" whether the device supports a given
format.
Working Group Resolution:
We have shortened the best practice by moving it in the explanatory text
that also has been clarified.
We haven't combined it with link_target_format since we want to to be
clear on both these points.
----
Your comment on [LINK_TARGET_FORMAT]...:
* I am not sure what you mean by this checkpoint. Through Internet
protocols I believe two parties can agree on whether a client supports a
particular format available on the server. So do you mean that after such
a negotiation, in (adapted) content you serve, you don't have to provide
information about the format? I don't think you mean that, in particular
because I think that would imply lots of communication about all the links
in a document to determine the format of identified resources. * Other than
through Internet protocols dynamically, I don't know how you can "know the
device supports" a given format unless you are designing in a very closed
environment, and I thought that the purpose of these guidelines was to
explain how to design effectively in anopenenvironment. * Perhaps you can
shorten this, therefore, to something like "To help users reduce the cost
of unnecessary downloads, for pieces of content in formats that are not
part of the default delivery context, identify the format in links."
Working Group Resolution:
Most content adaptation systems rely on a database of known devices, with
information on which format the device support. If you use such a system,
you can annotated only the links you know may not be supported; if you
don't, you fallback on the default delivery context, which tells you that
only XHTML, JPG and GIF are supported formats (we have amended the text to
clarify this).
----
Your comment on [IMAGE_MAPS] Do not ...:
* I have a similar concern as above about "unless you know." I think that
some of these checkpoints make more sense at certain points in a pipeline
than at others. For instance, I as a human author probably don't know
whether a particular user agent supports this or that. On the other hand,
a piece of software that is actively involved in some protocol negotiation
and that is doing content adaptation may very well have that information
available. But the points are written for multiple audiences and therefore
may be confusing.
* What is "an available geometric shape"? I think you mean that the
format supports the shape.
Working Group Resolution:
The document is about delivered content. The inference for a content
author is that if they specify an image map, then under certain
circumstances this will not work so they should in addition consider an
alternative linear arrangement of links.
We have shortened the best practice to: "Do not use image maps unless you
know the target client supports them effectively." and explained
"effectively" in the text with the remainder of the BP as it is now put.
We have also included a note to the effect that Image Maps on the Mobile
Web are a bad idea.
----
Your comment on [POP_UPS] Do not cau...:
* In developing UAAG 1.0, which addresses these topics, we distinguished
two concerns (1) the (visual or other sensory) disorientation caused by
suddenly opening windows and (2) the change in focus. * I urge you to
recast these in terms of thecheckpoints of Guideline 5of the UAAG 1.0
Recommendation. I am happy to discuss them further with you to help answer
any questions. * In particular, an important point is that it's ok to do
these things when the user says it's ok. * For the point about "unless you
have informed the user", that may be locking up the barn after the horse
has been stolen. I think it's more important to provide an alternative.
Working Group Resolution:
We don't mean to be prescriptive about providing a means of helping the
user choose, we do mean that there must be a way of telling the user that
the page will refresh and of stopping refresh once it has started. Any
other consideration is more to do with User Agents, which is out of scope
for this document.
----
Your comment on [SUITABLE] Ensure th...:
* Please delete this point. I believe the purpose of this entire document
is to explain to the reader what it means for content to be suitable for
use in a mobile context. Do you mean "suitable" in the sense of "not
offensive"? [I don't think you do; just checking.]
Working Group Resolution:
As explained in the text, we simply mean that you're rarely interested in
very detailed and long texts when using the web on a mobile devices, but
that you would be generally speaking looking for specific information:
"Users in a mobile context are often looking for specific pieces of
information, rather than browsing. Content providers should consider the
likely context of use of information and, while providing the option to
access all information, should offer appropriate information first."
----
Your comment on [CLARITY] Use clear ...:
I believe that the above checkpoint no longer exists in WCAG 2.0. I have
not followed that debate recently, but I believe that it is so contentious
as written (and not verifiable in any obvious way in that formulation) that
you will regret having included it. I recommend talking to the WCAG WG
about the evolution of their thinking in this area.
Working Group Resolution:
The point is less to be measurable and more to provide best practice
guidance. We are saying in the explanation below that a discursive style
is usually less appropriate in the mobile context. It's an important point
and we have kept it.
----
Your comment on [LIMITED] Limit cont...:
* How are you defining "what the user has requested?" Does that mean
"Implement HTTP GET"?
Working Group Resolution:
No, as we explain in the text below. The idea is to be mindful of the
users' costs etc and not send them advertising and so on that is not
relevant to their needs and at their expense.
----
Your comment on [LIMITED] Limit cont...:
* How does this apply to prefetching?
Working Group Resolution:
The idea is to be mindful of the users' costs etc and not send them
advertising and so on that is not relevant to their needs and at their
expense.
----
Your comment on 5.3.1.1 What it means:
The previous paragraph is not the same as "limit content to what the user
has requested." It is separate advice for good authoring for the Web
generally: Front-load pages with important information. You make this
point later on, so I think you should move this explanation to later in
the document.
Working Group Resolution:
We have linked CENTRAL_MEANING and CLARITY since they both address the
same range of topics.
----
Your comment on [PAGE_SIZE_USABLE] D...:
* I think the point of this document is to define what "usable" means.
Therefore, I don't think you should have a checkpoint that says divide
pages into usable pieces. Tell us instead what makes a piece usable.
Working Group Resolution:
We believe the explanation under the best practice makes it clear what we
mean by usable size.
----
Your comment on [PAGE_SIZE_LIMIT] En...:
* Delete "if they can be determined". This is an instance of a qualifier
that weighs down the point you are making and should be described
elsewhere.
Working Group Resolution:
We have removed the conditional statement since it is indeed taken into
account by the default delivery context.
----
Your comment on [SCROLLING] Limit sc...:
* What do you mean by "direction"? Do you mean "down, not up"? Do you
mean "Don't make people scroll horizontally? * Delete "unless secondary
scrolling cannot be avoided." In general, delete "except where impossible"
as I've mentioned above.
Working Group Resolution:
We have added the following explanatory paragraph:
"The page should lay out so that simple repeated scrolling in the same
direction (axis) allows the user to experience all its content."
We have kept the opt out clause, with explanations on cases where this
might be needed (e.g. a map).
----
Your comment on [SCROLLING_LIMIT] Li...:
* I do not understand how this point differs from the previous one.
Working Group Resolution:
We agreed and removed the second best practice on scrolling.
----
Your comment on [CENTRAL_MEANING] En...:
* The key [CENTRAL_MEANING] is less communicative than "Frontload
important information". See my earlier comment about using short labels
that capture the essence (even if imperfectly) of the point.
Working Group Resolution:
This one is meant to be about not putting banner ads, and other clutter in
advance of the text. The "frontloading" aspect is discussed under
[CLARITY]; we have added a link from one to the other to highlight their
relationship.
----
Your comment on 5.3.4.1 What it means:
The first sentence of the previous paragraph is more communicative than
5.2.2 as written.
Working Group Resolution:
We have referenced the text of this Best Practice from the text of the
best practice on navigation bar, with clarification on why it is important
to keep navigation bars short in the mobile context.
----
Your comment on [LARGE_GRAPHICS] Do ...:
* The first sentence of the second point here can be generalized to be
"don't do things that the device can't handle." Because I don't think that
is known in all cases, I suggest you delete the first sentence. Perhaps
rephrase the point in terms of the default delivery context: "Very large
or high-resolution graphics are unlikely to achieve their desired goal
when rendered on devices with small screens. Avoid them unless there is no
other way to provide the information in question." * In some cases, people
may wish to download images for viewing on another device (e.g., I store
something on my phone then view it on my desktop computer). You may wish
to remind the author of that scenario.
Working Group Resolution:
We keep this best practice as it is a classical problem in mobile web
design and want to insist on this type of practical issue.
On the 2nd point, we've included discussion on downloading items (under
link_target_format).
----
Your comment on [COLOR_CONTRAST] Ens...:
* I think it is very important that this document adopt the language used
by the WCAG WG. They have spent a very long time discussing this topic. For
instance, for the first point, copying from the 23 Nov 2005 Draft,section
1.3.1: "When information is conveyed by color, the color can be
programmatically determined or the information is also conveyed through
another means that does not depend on the user's ability to differentiate
colors." If you have a reason to say something other than what WCAG 2.0
says, please explain below. (In general, if another W3C Recommendation
says what you want, whether it is WCAG 2.0 or UAAG 1.0, Webarch, or
another document please use that language or be sure to explain why you
have chosen not to.)
Working Group Resolution:
We reference WCAG 1.0 because this is the current W3C Recommendation.
----
Your comment on [BACKGROUND_IMAGE_SU...:
* This is another instance of the general point "Don't do X". I think you
should regroup all of those points in one and relate them to the default
delivery context.
Working Group Resolution:
The Best Practice was dropped, so this comment doesn't apply anymore.
----
Your comment on [BACKGROUND_IMAGE_RE...:
* Please stick very close to WCAG 2.0 on this one as well (I think it is
1.4.3).
Working Group Resolution:
We stick close the WCAG 1.0 - the current W3C Recommendation.
----
Your comment on [PAGE_TITLE] Provide...:
* A theme has emerged: "Keep it short". I think you have points related
to shortness of URIs, titles, and pages. Perhaps they can be merged.
Working Group Resolution:
We don't think there are enough benefits in re-organizing the document
around this kind of grouping to justify the cost of actually doing it.
Also, this allows to put the focus on specific concerns rather than on
general principles.
----
Your comment on [NO_FRAMES] Do not u...:
* Please provide a bit more rationale, as in "Because they are not widely
supported in the mobile context and also are widely known to be problematic
for users, do not use HTML frames."
Working Group Resolution:
The text already reads:
"Many mobile clients do not support frames. In addition, frames are
recognized as being generally problematic."
----
Your comment on [NON-TEXT_ALTERNATIV...:
* Please stick very close to WCAG 2.0 on this one as well.
Working Group Resolution:
WCAG 2.0 is still a Working Draft, so the group has chosen to align with
WCAG 1.0 which is a Recommendation. In particular, we have syncronized the
text of this BP with the WCAG 1.0 guideline.
----
Your comment on [OBJECTS_OR_SCRIPT] ...:
* This is another instance of "Don't do X" when you are outside the
default delivery context; regroup with those?
Working Group Resolution:
As already noted, we don't think the benefits of grouping outweighs the
costs.
----
Your comment on [IMAGES_SPECIFY_SIZE...:
* Why do you use "Always" here and not in other points? I recommend
deleting "Always" for the same reason I suggest deleting "when possible".
* What about markup languages that don't support this?
Working Group Resolution:
We have removed the word "always" and have instead clarified in the
explanatory text that this is an exception to the best practices on
relative measures.
All the markup languages in scope for this document (XHTML Basic and
above) have support for this feature.
----
Your comment on [IMAGES_RESIZING] Re...:
* Please provide more rationale for this one, which I did not understand
when I first read it. Something like this might help: "Because mobile
devices have limited processing capabilities, make available small
versions of images rather than require resizing after delivery."
Working Group Resolution:
The text already reads:
"Resizing images at the server [...] reduces amount of data transferred
and the amount of processing the client has to carry out to scale the
image."
----
Your comment on [MEASURES] Do not us...:
* Adding more rationale: "To enable flexible display, use relative units
(e.g., "em") rather than absolute units (e.g., pixels) when specifying
dimensions (e.g., shapes or font sizes) in formats such as markup
languages and style sheets."
Working Group Resolution:
The text already reads:
"Avoiding pixel and absolute measures allows the browser to adapt content
to fit the display."
----
Your comment on [STYLE_SHEETS_USE] U...:
* Please delete "unless the device is known not to support them" in favor
of a general section on handling this sort of thing (as described above).
Working Group Resolution:
Given that style sheets are part of the default delivery context, this get
out clause is needed when a site adapts its content for a device that
doesn't support style sheets.
----
Your comment on [STYLE_SHEETS_SUPPOR...:
* This also comes from WCAG, but I no longer see it in WCAG 2.0. Have you
asked them why it was deleted? (I don't see it in the23 Nov 2005 draft)
Working Group Resolution:
It may have been a WCAG point but the mobile interpretation is that some
devices don't do style sheets.
----
Your comment on [STYLE_SHEETS_SIZE] ...:
* Delete "as possible", and * Add this to the list of things to "keep
short"
Working Group Resolution:
We have removed "as possible".
----
Your comment on [MINIMIZE] Use terse...:
* Delete this point and add to the list of things to "keep short":
markup.
Working Group Resolution:
We think these are separate concern that deserve separate contexts. While
we may have chosen to organize the best practices in the way you suggest,
we haven't found enough benefits behind your proposed re-organization to
work on a major re-organization as you suggest.
----
Your comment on [CONTENT_FORMAT_SUPP...:
* Perhaps you can be more specific about HTTP (is it "accept" headers?)
since that is an explicit assumption above. * The user may wish to receive
content even if its device does not directly support it (e.g., to save and
use it later). Please make it clear that the user can, on demand, request
content that is not supported by software on the client.
Working Group Resolution:
We have clarified that a user should always be able to at least download
items (in LINK_TARGET_FORMAT), no matter the level of support his or her
device has for the said format. We have also mentioned the various ways
one can determine which format is supported or not.
----
Your comment on [CONTENT_FORMAT_PREF...:
* Please delete "Where possible" * I suggest merging these two into a
single point about following standard protocols for content type
negotiation.
Working Group Resolution:
The point is that:
* simple standard content negotiation works poorly in the mobile space.
* It may not be possible to do it if you're not using content adaptation.
* Respect the markup format the client is asking for.
----
Your comment on [MINIMIZE_KEYSTROKES...:
* "to a minimum" is not well-defined. * Add this to the list of things to
keep short.
Working Group Resolution:
We prefer to have well-focused practical best practices rather than
generic lists of items that fit under a same principle.
----
Your comment on [AVOID_FREE_TEXT] Av...:
* Delete "where possible" * Provide more rationale: "Because text entry
is time-consuming and prone to error, avoid interfaces (such as text entry
boxes) in favor of other types of controls (e.g., menus or radio buttons).
Working Group Resolution:
The text already reads:
"Given the typical input limitations of a mobile device the interface must
as far as possible minimize user input. Where possible, use selection
lists, radio boxes and other user interface artifacts that do not require
typing."
----
Your comment on [PROVIDE_DEFAULTS] P...:
* Delete "where possible"
Working Group Resolution:
As noted above, this leeway is intended given the document focus on
guidance rather than mandated rules.
----
Your comment on [TAB_ORDER] Create a...:
* Perhaps "tab order" is the term of art. Do people use a tab key on
mobile devices? In UAAG 1.0 we talk about "sequential navigation"
(distinguished from "direct navigation" through keyboard shortcuts).
Working Group Resolution:
We have removed the word "tab" and used a more generic wording about
navigation order.
----
Your comment on [CONTROL_LABELLING] ...:
* Delete "appropriately" (twice) * By "explicitly" do you mean "through
markup language features" (such as the "for" attribute in HTML)? * Please
be more explicit about what appropriate positioning is rather than make
this general statements. Is "before" better than "after" in reading order?
Working Group Resolution:
We have removed the duplication of "appropriately".
We have split the best practices in two to separate the concerns of
labeling and positioning, but the proper positioning of labels with forms
controls depends too heavily on the context to be specified more
precisely.
----
Received on Wednesday, 12 April 2006 17:14:01 UTC