RE: UI and scope

Though the charter is expiring I am totally against changing it at this point. We have enough problems trying to complete this process without expanding the scope via a change to the charter.

Thanks,
JC

From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com]
Sent: Saturday, June 16, 2012 8:55 AM
To: Bjoern Hoehrmann
Cc: Heather West; public-tracking@w3.org Group WG
Subject: Re: UI and scope

On Sat, Jun 16, 2012 at 8:33 AM, Bjoern Hoehrmann <derhoermi@gmx.net<mailto:derhoermi@gmx.net>> wrote:
* 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:



Bjoern, I think we disagree on the reading of the charter. "Guidelines that define the user experience or user interface" -- how you can "define" without being a "requiremenent" is a bit unobvious to me. Definition == specification. Definition of the user experience or user interface is explicitly in scope the way I read the charter.

>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.

Again, I did not say I was arguing for these examples or that they were a good thing to do, merely giving examples of things that would be in scope.


>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.

Again, I did not say I was arguing for these examples or that they were a good thing to do, merely giving examples of things that would be in scope. And I would argue that if you document it alongside wherever you document the command line switches, that would be sufficient... the documentation of command line switches in this case is where you give users the options.


>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.

I don't actually see this as problematic as you do. If the car is reading the news to them, it's probably using a rather specialized interface/set of sites, or if not it already has to deal with other permission problems. This example feels a bit contrived tbh.

--
Björn Höhrmann · mailto:bjoern@hoehrmann.de<mailto:bjoern@hoehrmann.de> · http://bjoern.hoehrmann.de

Am Badedeich 7 · Telefon: +49(0)160/4415681<tel:%2B49%280%29160%2F4415681> · http://www.bjoernsworld.de

25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/