- 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