LC-442
Ian B. Jacobs <ij@w3.org> (archived comment) |
1) 5.1.3 Work around deficient implementations.
Question: If I conform to standards without looking further,
do I satisfy this practice?
If the answer is "yes" then I am satisfied and ask only that
this be made clear in the document.
If the answer is "no, you have to do more than conform to
standards," then I have an issue. I think it places an
unreasonable burden on authors to have to learn about the
diverse landscape of browsers, platforms, and bugs. There may
be large organizations that have resources to do this, but I
believe that for the millions of individuals or small
organizations that will likely wish to satisfy this document
(or be required to, who knows), this is an unreasonable
burden.
Instead, I suggest: "Even if it means that you have to deviate
from standards, you MAY work around deficient
implementations." I realize that the group is creating "best
practices" and considers this to be good practice. However,
even if satisfying this requirement is possible for a few
content providers, I think it will be very difficult for
ordinary authors.
If content that conforms to the standards that define the
default delivery context satisfies this requirement, then
please make that abundantly clear. However, because authors
are asked to do more than design for the default delivery
context (practice #2), it still sounds like one is forced to go
beyond the defaults in order to conform.
Lastly, I believe a desirable property of conforming content
is that once it conforms, it always conforms. Because browser
bugs vary over time, content that once conformed may not
conform in the future. One way to handle this is to date
conformance claims, but that does not improve on the fact that
the content's conformance status may vary over time.
|
The main point here is that no one is forcing anyone to do anything. So there is no implication of 'have to' and there is a strong element of it being a good thing to do.
We note that it is a particular challenge to provide work-arounds and where we say that deviation may be necessary we make the point in quite a limited way [It is recognized that content providers may need to violate specific Best Practices in order to support their intentions on devices that exhibit deficiencies in implementation.]
However we use very strong language to encourage standards compliance [If a device is not known to have specific limitations then content providers must comply with Best Practices.]
In summary, these comments are very relevant to mobileOK and should feature largely in that thinking. However as noted above, the BP as it stands is clear enough that it is an escape hatch for those that wish to do better than the bare minimum. |
tocheck |
|---|
LC-456
Karl Dubost <karl@w3.org> on behalf of QA (archived comment) |
Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD
Did you have chosen these formats because it's really supported
everywhere?
I was wondering about PNG.
[[[
Image Format Support
JPEG
GIF 89a (non-interlaced, non-transparent, non-animated).
]]]
|
Indeed, an analysis of the devices on the market today shows that GIF is more widely supported than PNG; in particular, PNG is very poorly supported in most devices on the Japanese market. |
tocheck |
|---|
LC-452
West, Mark Andrew <mawest2@bsu.edu> (archived comment) |
I have read the current draft of the Best Practices document. Overall it is a good summation of all the guidelines (esp. OpenWave) I have been using under the Mobile Development Project at Ball State University Libraries.
While I have a few minor problems with the guidelines (GIF really ought to be put on pension since most mobile Web browsers can handle PNG), I take issue with the capabilities guideline (5.1.2): "Do not take a least common denominator approach."
As the mobile developer, my primary concern is to make library information and services available to the largest number of mobile users. I started with no knowledge of mobile devices; with a clunky development environment (IIS/Visual Studio/FrontPage); and with a vague idea of what devices were in use on campus. (Several attempts at an online survey of mobile devices fell flat.) Nonetheless I have created a mobile Web site for the University Libraries, that looks and works perfectly well using a strategy that the Best Practices document has labelled "least common denominator".
Perhaps you can add a "How To Do It" section under the capabilities guideline, or at least explain why following a LCD approach could result in a lesser experience for mobile users.
The University Libraries mobile Web site is http://www.bsu.edu/libraries/mobile/.
|
We encourage content providers to provide an experience that works for the Default Delivery Context. However, we are aware that the Default Delivery Context is very restrictive and that when mobile devices such as PDAs and large screen mobile phones are used, a better experience can be provided to the users of those devices by exploiting their greater capabilities. A specific example of this is that larger screen devices can display larger images, so we encourage content providers to provide better quality images on devices that can handle them. |
tocheck |
|---|
LC-447
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.4.12.2 "All applications should support UTF-8". I think the
word "application" may be confusing because it sounds like
"software", and these are content guidelines, not user agent
(software) guidelines. I read this as "Content providers, you
can expect that software will support your UTF-8 content."
Was there a particular reason behind the choice of the word
"application?" Possible rewrite:
"Content providers should make available at least a UTF-8
encoding of content."
|
We feel that the word 'application' which is used in several other places in the document with the same meaning is appropriate.
The text has changed slightly in this revision as a result of other comments: "Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8." |
tocheck |
|---|
LC-448
Ian B. Jacobs <ij@w3.org> (archived comment) |
There are three practices that use the word "document" (31,
40, and 43). Because most of the document refers to "content"
rather than "documents", I recommend using "content" in the
remaining three. If there was some reason for using "document"
instead of "content," please make that clear in the spec.
The same applies to the word "application" or other terms that
are intended to be synonyms of "content"; one may think that
the terms are used to refer to something other than "content."
|
The majority of uses of the word document are in reference to the BP
document itself or similar interpretations of the word document.
In the following instances:
"[STRUCTURE] Use features of the markup language to indicate logical
document structure."
"[VALID_MARKUP] Create documents that validate to published formal
grammars."
"[STYLE_SHEETS_SUPPORT] Organize documents so that they may be read without style sheets."
We really do mean "document". There are a couple of places where document is used in set phrases such as "document order" and "XML document". There is one instance where you could argue that the word content should be changed to document.
"Ensure that content is encoded using a character encoding that is known to be supported by the target device."
But even in this case it is followed by
"Where possible, send content in a preferred format."
and we believe that it reads better as it stands, with this in mind.
Also, "application" is used appropriately and used in the sense of talking about where the content comes from, rather than being specific that it comes from a Web Server. |
tocheck |
|---|
LC-450
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.4.16 Fonts. (Minor) I would move this section closer to "Style
sheets"
|
The grouping is somewhat arbirary. We're reluctant to change the order as the condensed list of BP's has been out for a little while and an improvement in the consistency of the ordering would be at the expense of consistency between revisions. |
tocheck |
|---|
LC-454
Karl Dubost <karl@w3.org> on behalf of QA (archived comment) |
Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD
* Why the document scope has a direct reference only and not a link
in the reference section?
* I haven't figured out if it was troublesome to have the scope of a
specification in a W3C Note. It seems strange. At the same time, you
are making an abstract of it.
[[[
The scope of these Best Practices is laid out in "Scope of Mobile Web
Best Practices" [Scope]. In summary, this document refers primarily
to the extension of Web browsing onto mobile devices.
]]]
|
The scope document does appear to be properly linked from the References - can you clarify if that is not what you mean? |
tocheck |
|---|
LC-443
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.3.1 Page content. The practice says: "Ensure that content is
_suitable for use in a mobile context_"
I believe the purpose of this document is to explain what one
needs to do to create content that is suitable for use in a
mobile context. Requirements such as "avoid long sentences" or
"prioritize information that relates to mobility" tell me what
to do to achieve that goal. "Ensure that content is suitable
for use in a mobile context" tells me nothing and merely
restates the project of the entire document. If you have
specific ideas in mind here, please replace the current
practice with those more specific requirements.
|
We have decided to clarify the point and satisfy Ian's need for examples by providing a link to User Goals :
[Mobile users typically have different interests to users of fixed or
desktop devices. They are likely to have more immediate and goal-directed intentions than desktop Web users. Their intentions are often to find out specific pieces of information that are relevant to their context. An example of such a goal-directed application might be the user requiring specific information about schedules for a journey they are currently undertaking.]
and to the section on One Web:
[Some services have a primarily mobile appeal (location based services, for example). Some have a primarily mobile appeal but have a complementary desktop aspect (for instance for complex configuration tasks). Still others have a primarily desktop appeal but a complementary mobile aspect (possibly for alerting). Finally there will remain some Web applications that have a primarily desktop appeal (lengthy reference material, rich images, for example).]. |
tocheck |
|---|
LC-444
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.4.5.2 How to do it: "Design pages as though they were to be
displayed on a text-only browser."
I believe a reader might misinterpret this sentence to mean
"Design text-only pages" which I do not believe is your
intention. In the area accessibility, there is a
misconception that text-only pages are accessible pages and
therefore one should limit oneself to designing text-only
pages to ensure that they are accessible. My concern is that
the above sentence will perpetuate that misconception and
introduce it into the MWI context.
Proposal: "Design pages that transform gracefully when
rendered in a text-only environments. Test your content with a
variety of browsers, including text-only browsers in order to
learn how some users will perceive them." I recommend
adopting the latest WCAG verbiage on this topic.
|
We think this is a fair point and have decided to update the BP to read
Design pages so that they are useful when rendered as text only. See also [TESTING].
And we have updated [Testing] to suggest that download of images is disabled as part of testing.
"Content providers should also test with specific features disabled, such as using text-only modes and with scripting disabled." |
tocheck |
|---|
LC-453
Karl Dubost <karl@w3.org> on behalf of QA (archived comment) |
Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/#iddiv2220152400
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD
I wonder if this following part should be in the status section. The
sentence will not bear the same meaning once you would have actually
published the companion documents. Or maybe you could modify the
sentence in a way that will not imply a future: "will be".
[[[
mobileOK and techniques for implementing the Best Practice
recommendations will be discussed in companion documents.
]]]
|
We agree that this should be changed and in addition have reveiwed all references to the companion documents.
The text we have chosen is:
At the time of writing of this document, documents describing mobileOK and Techniques for implementing the Best Practices are being worked on. |
tocheck |
|---|
LC-455
Karl Dubost <karl@w3.org> on behalf of QA (archived comment) |
Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD
I have the same comment than previously about history. The "will
develop" seems not to be at the right place in a specification.
[[[
The BPWG will develop a companion document describing techniques
[Techniques] by which the Best Practice statements in this document
can be implemented.
]]]
|
As per the previous comment, we agree and have reviewed the references to companion documents. The text we have chosen is:
The BPWG is developing a companion document describing techniques
[Techniques] by which the Best Practice statements in this document can be implemented. |
tocheck |
|---|
LC-445
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.4.5 Non-text items. What is the definition of "non-text
element?"
I strongly recommend defining this in the document and using
the latest WCAG definition. As a sample of why the definition
poses challenges, consider these questions:
* Is ASCII art text content or non-text content?
* Is a script that generates text considered non-text content
or text content?
[This term has years of discussion behind it in WAI.]
|
We have added a link to the WCAG text explaining what non-text item means. |
tocheck |
|---|
LC-446
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.4.9 Style sheets. The first two practices are:
"Use style sheets to control layout and presentation,
unless the device is known not to support them."
"Organize documents so that they may be read without style
sheets."
If I read these practices carefully, I think they probably
don't conflict. But I think some readers might read these too
quickly as "Use style sheets" and then "Don't use style
sheets." For instance, suppose I want to achieve a particular
layout. The right thing to do is to use style sheets (practice
1) but if I use a feature in a particular way so that turning
the feature off would cause the content to become unreadable
(practice 2), then I probably should not use the feature. But
then have I violated practice 1 by not using it? I can't quite
put my finger on it, but I think there is some dependency
between the practices that needs to be made more explicit. For
instance, I could read them as:
Use style sheets to control layout and presentation
(1) unless the device is known not to support them,
AND
(2) do so in a manner such that when turned off,
the content remains readable.
I wonder if this is an improvement:
"Use style sheets to control layout and presentation,
unless the device is known not to support them."
"When using style sheets to control layout and presentation,
organize content so that if the style sheets are turned off
or not supported, the content may still be read."
It is probably too long. Nonetheless, I think a slight
clarification would help avoid confusion.
|
We agree and have reworded the best practice to:
"Organize documents so that if necessary they may be read without style sheets." |
tocheck |
|---|
LC-449
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.4.12 Character encoding. (Minor). The phrase "target device" is
used here where "device" is used elsewhere. It seems as though
"device" would suffice
|
Thanks for pointing out this anomaly. Target does appear to be redundant here and in several other places too, so the document has been updated to make the usage consistent - in the text of the best practices themselves. |
tocheck |
|---|
LC-451
Ian B. Jacobs <ij@w3.org> (archived comment) |
5.5.3 Labels. (Minor) The practices in this section are about
"Labels for Form Controls." I think that would be a clearer
title. Also, I propose that you use "form control" instead of
the bare word "control."
|
We agree and have made the relevant changes. |
tocheck |
|---|