Re: UI and scope

* Ian Fette wrote:
>Bjoern, the charter allows for "guidelines that define the user
>experience". The only thing that is specifically excluded is "exact
>presentation to the user." Requirements around UI are not excluded
>wholesale.

If the Working Group wants to make requirements rather than guidelines
then it's easy enough to recharter to make that clear, the charter is
set to expire end of next month anyway. I note that it is quite normal
for W3C charters to exclude requirements in this area as they tend to
interfere with Universal Access. Take your examples:

>Here's a few examples that would seem not to violate the charter. I am
>merely using them as examples, not advocating for them specifically at this
>time:
>
>a) When the API provided to request an exception is called by a site, the
>user's preference must be solicited.

A user agent that preloads web pages for offline use will usually do so
non-interactively; always denying such requests is not soliciting the
user's preference every time there is a request, so the requirement spe-
cifies the presentation to the user so exactly that common functionality
like preloading web pages for offline cannot be implemented under DNT.

>c) The user interface must make the following items clear as part of the
>process by which a user turns the DNT preference "on": <summary of what DNT
>does and does not do>

A command line application that allows setting DNT preferences through a
command line switch does not have a user interface where it could inform
users of anything as they specify their preference, since they would do
that before launching the application. The information would be in the
software's manual, but manuals are not part of the user interface and in
general not part of the process by which users enable preferences. When
I want to know how to encode videos so they work good on AcmePhone, I'll
search for something like 'ffmpeg AcmePhone' and then copy and paste the
commands I've found on a blog or recipe collection; no manual involved.

The requirement specifies the presentation to the user so exactly that a
whole common class of applications cannot conform to the specification.

>d) When the API provided to request an exception is called by a site, the
>user's preference must be solicited via an active mechanism such as via a
>dialog, infobar, or other mechanism that would attract the attention of
>most users; the mere presence of a "passive" indicator (such as an icon
>changing color or the appearance of a small icon) would not be considered
>sufficient.

Someone drives a car and their web browser is reading the news to them.
Something decides to request an exception and the browser generates an
obtrusive signal that is sure to attract the attention of most users...

"One of W3C's primary goals is to make these benefits available to all
people, whatever their hardware, software, network infrastructure,
native language, culture, geographical location, or physical or mental
ability." - http://www.w3.org/Consortium/Points/

Your examples illustrate how specifying presentation requirements, as
opposed to guidelines, can very easily pose problems for environments
and implementations you did not consider when making the requirement.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 16 June 2012 15:33:34 UTC