Re: Ascertaining the user's needs and preferences: implications for the spec

On Oct 2, 2013, at 1:23 AM, Jason White <jason@jasonjgw.net> wrote:

> This is my action item from the last meeting.
> 
> Background
> 
> The mechanisms by which user agents acquire information about the user's needs
> and preferences are outside the scope of the specification. However,
> discussions within the working group have shown that the availability of
> information to the user agent about needs and preferences is a matter that may
> influence the design of the technology, or at least serve as a consideration
> in decisions about which features to include in version 1.0 and which to
> postpone.
> 
> For example, the User Contexts draft currently provides for a "transcript"
> boolean value (true if transcripts of video are requested). The editorial note
> acknowledges that whether transcripts are wanted is not specifiable as a
> configuration option in current operating systems or user agents, raising the
> question whether the proposed feature should therefore be omitted or postponed
> to a future version.
> 
> If this feature were included, IndieUI would implicitly require user agent
> developers to provide a configuration option enabling the user to specify a
> preference, or perhaps an algorithm for inferring this preference from other
> aspects of the configuration or running environment.
> 
> Questions
> 
> 1. If the value of a proposed variable in the need/preference profile is not
> ascertainable at all in any user agent at the time the spec enters Last Call,
> should the variable be omitted from the current version of the spec, e.g., 1.0
> for the first release?

Yes.

> Why or why not?

Because we have to prove implementability in two user agents.

> 2. If the value is obtainable in some, but not all user agents (or subject to
> differences in operating system), should it be omitted, and if so, under what
> circumstances, e.g., where two independent implementations are not expected
> within a reasonable time?

By some, do you mean one? Presumably if there were some, that would mean at least two, and therefore complete our exit criteria.

> 3. If there are expected to be two interoperable implementations of a given
> feature, but not all user agents would support it (lacking the mechanisms to
> obtain the need/preference value), how should the working group respond?
> Should the spec be modularized, or should the proposed feature be omitted? Are
> there other possibilities?

If there are two implementations of a feature, the approach for the others that do not support said feature is to file bugs in the user agents' respective bug trackers, and expect them to implement the feature at some point in the future.

> 4. If the value of a proposed need/preference variable is not currently
> ascertainable, should the spec recommend a mechanism for obtaining it, for
> example that user agents add a configuration option to their user interfaces?

That’s a slippery slope. If we suggest anything, if may be that the browsers implement a configuration file for these, rather than specify something like a graphical user interface option. Each browser can then determine if or how they want to expose those configuration options to the end user.

Given that some of these will likely end up being media queries, it may make sense to define these similarly to a user style sheet.

> Should any guidance for collecting needs/preferences from the
> hardware/software environment be given? what are the interoperability issues
> here, if different UAs collect the information differently?

I think that’s squarely outside the scope of IndieUI, since it affects platform and browser implementations.

James

Received on Wednesday, 2 October 2013 17:26:26 UTC