Re: UI and scope

On Sat, Jun 16, 2012 at 8:33 AM, Bjoern Hoehrmann <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 · 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/
>