RE: UI and scope

I am not advocating for a change to the charter. Merely pointing out that
the charter does not prohibit as much as people say it does (as written).
On Jun 17, 2012 9:17 AM, "JC Cannon" <jccannon@microsoft.com> wrote:

>  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>
> 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/***
> *
>
>  ** **
>