Re: Proposed Set of Needs/Preferences for v1

It seems to me that we have a fundamental disagreement on whether we have some semantic set of preferences built in or whether its a general model that can express any (keyed) preferences defined externally and uniquely for each device vendor.

I have two problems with the second approach

1. How do we get an individuall"s set of preferences into the device? We said there would be no mechanism for that in v1

2. How do we achieve the generality of preferences (the interoperability) that individuals need and web authors need to know about?

Andy

Sent from my iPad

On 21 Feb 2013, at 04:54, James Craig <jcraig@apple.com> wrote:

> 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"
> 
> 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.
> 
> What browser has a preference for this? That would change things.
> 
>> 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.
> 
> James
> 
>

Received on Wednesday, 20 February 2013 20:46:35 UTC