Re: Proposed Set of Needs/Preferences for v1

Rich Schwerdtfeger

James Craig <jcraig@apple.com> wrote on 02/20/2013 01:54:25 PM:

> From: James Craig <jcraig@apple.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cc: Indie UI <public-indie-ui@w3.org>, Sangwhan Moon <smoon@opera.com>
> Date: 02/20/2013 01:55 PM
> Subject: Re: Proposed Set of Needs/Preferences for v1
>
> On Feb 20, 2013, at 5:38 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
>
> > James Craig <jcraig@apple.com> wrote on 02/19/2013 07:23:35 PM:
> >
> >> I think we as a group are still discussing two very different
> >> things, which for lack of better terms, I'll call "wishlist
> >> preferences" versus "actual preferences." Actual device, browser,
> >> and AT preferences include things with existing settings like font
> >> size, colors, and whether or not captions are enabled. What I'm
> >> referring to as "wishlist preferences" include some things in Andy's
> >> proposal like "I'd prefer access to an transcript if you have one."
> >> I don't know of any system that has a preference like this, and on
> >> the Web it's usually exposed as link near the audio player.
> >
> > These are not wishlist preferences.
>
> I'm not implying the prefs won't be useful at some point in the
> future. I'm merely stating that no user has a way to enable these
> preferences, and until they do, there will be no way to implement
> these prefs, and therefore we don't have any business putting them in a
spec.
>
> I freely admit, as I did above, that "wishlist preferences" is not
> the best term. Feel free to suggest a better one.
>
> The fact remains that there is a difference between actual settable
> preferences, and the preferences that a user would like to have
> (even needs to have) but is not currently settable or
> programmatically meaningful on their device, browser, operating
> system, or assistive technology.
>
> > These are already implemented in the National Science Digital Library.
>
> Because the National Science Digital Library is not a operating
> system, browser, or assistive technology vendor, so I'm not sure
> what you mean by "implemented." If theses keys are *defined* by the
> NSDL, then they could be referenced as a third-party taxonomy with
> the optional taxonomy key.
>
> > We can not be so myopic as to limit a user's needs to what is
> provided as an operating system setting.
>
> Implementability is a requirement to exit Candidate Recommendation.
>
> > You don't know of systems that support preferences like this
> because you have not been involved in that work. Just because you
> have not been involved in that work does not mean that they are a wish
list.
>
> If you know of an operating system, browser, or assistive technology
> that exposes these preferences in a programmatically useful way,
> that changes things. Please elaborate.
>
> > Preferences that can be passed to a page author to allow them to
> deliver content in different ways is completely in the scope of this
> work as it does not require the browser to turn/off a feature in the
> OS and does not require an additional API. More importantly, the
> preference (prefers a transcript) is easily understood.
>
> I believe support for this is already available as defined in the
> User Context draft by allowing an optional "taxonomy" key.
> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-

> context.html#UserPreferences
>
> If you prefer, I can add the following as an informative code example.
>
> // example of preferences that are defined by third-party taxonomies.
> window.preferences.valueForKey('prefersTranscript', 'nsdl'); //
> "National Science Digital Library"
> window.preferences.valueForKey('prefersSimplifiedInterface',
> 'gpii'); // "Global Public Inclusive Infrastructure"
>

No. I am not supportive of that approach as it what you are saying is that
the things that apple wants don't require namespaces but the things that
the working group wants get ghettod into a namespace and you end up not
really supporting it. That is is wrong as that is NOT interoperability.

At the last meeting the other members wanted these other features and not
just the OS settings. Second, at the face face it was asked that we have a
small set vs. a large GPII set. We have done that.

Also, if Andi's action item was to get these other preferences and you want
to ghetto them into a namespace there was not purpose to that exercise.

Finally, just because these features are not in the browser today really
does not matter as if you look at the schedule there is more than ample
time to get them in and we can get implementations in that time frame.

> But we should not define keys like these in the primary spec for two
reasons:
>
> 1. These third-party taxonomies already define them.
> 2. There is no way for a user to set this preference without
> utilizing a tool designed specifically for one of these taxonomies.
>
>
> > This is a browser feature setting and very easy for the user to
> set. If it becomes important at the OS system level then the
> platform owner can decide to move it there. Right now, I see no need.
>
show a settings panel, for say Safari, and let the user select the
preferences. They do not need to got to a systems settings panel or a
control panel in windows where settings apply to the entire OS.

> What browser has a preference for this? That would change things.
>
They don't today. That's why we have a working group. Heck, when we started
ARIA there was NO browser support and in fact there were even gaps in each
platforms accessibility API. We filled them.

> > We are not duplicating an effort. What you have been provided
> existed far before GPII and the GPII preference set is an enormous
> set of preferences. We are talking about a small core set of preferences.

> …
> > I don't want to limit the discussion to OS system settings.
>
> Neither do I, but I disagree that we're not duplicating effort for
> some of these. I'm talking about keeping 1.0 scoped to common OS,
> browser, and assistive technology settings, while allowing access to
> other settings via vendor-specific or third-party taxonomies.
>
You are defining a scope for 1.0 that was agreed upon by the group.

> James
>