W3C home > Mailing lists > Public > public-indie-ui@w3.org > February 2013

Re: Scope of User Contexts specification

From: Jason White <jason@jasonjgw.net>
Date: Thu, 7 Feb 2013 17:20:26 +1100
To: public-indie-ui@w3.org
Message-ID: <20130207062026.GA21690@jdc.jasonjgw.net>
Andy Heath <andyheath@axelrod.plus.com> wrote:
> I wrote those words and regret now the poor way I phrased that.  A
> better phrase would have been "is able to achieve a best match".
> Certainly there is no intention here to specify behaviour at all -
> but to enable possible behaviours.

Thank you for clarifying your intention; this is very helpful. I don't,
however, think this resolves the underlying issue, which can be stated more
generally as: should there be conformance requirements in the User Contexts
spec that apply to Web applications, or should there only be user-agent
conformance requirements?

> As for the boundaries of extension, where the API a browser queries
> lives and those boundary questions my view would be that at this
> point we would want to encourage implementations on devices that
> handle all of the preferences as settings entered by some sort of
> set-up wizard at the user interface (though different settings may
> best be suited to slightly different interaction/selection
> mechanisms to set them), modified by the device as context
> (temperature, light, sound-level etc.) changes and the device
> notices.  Several of them are already common settings on devices or
> very close to existing settings.  It might be that some devices
> handle preference settings at the UI that they are not able to
> respond to at all but where the purpose is to enable behaviour by
> web apps. Or devices may choose to implement the API (that we didn't
> yet develop) to deliver settings like this to web apps but not
> handle at all preferences that they are not able to respond to (i.e.
> not set or keep settings values for them).  How that plays out is a
> marketplace scenario imho. If we build an API to support preferences
> like this and make it "possible" for browsers to respond then the
> marketplace is where decisions about "what" they will respond to
> should play out.  

There are several distinct questions here.

I agree that user-agents shouldn't be required (in all contexts and on all
operating systems) to support all of the needs/preferences defined in the
spec. Obviously, we will need at least two independent implementations of
each in order to satisfy Candidate Recommendation exit criteria, but that's a
separate matter.

My initial reaction was the same as yours: let's just define the API,
including the need/preference vocabulary, and let implementors populate the
user's profile as they think fit via UA or OS-specific user interfaces, via
API calls, GPII, or whatever mechanism happens to be available.

On the other hand, if this is totally unspecified then there is plenty of
scope for inconsistent implementations and hence for divergent, potentially
confusing experiences for the user with regard to what has to be configured
explicitly, what will be inferred from the fact that a given AT is in use,
etc., and what the precedence order is among various sources of preference
information. It isn't clear to me how large a problem this is, but it's
enough to make me want more discussion before concluding that stage 1 of the
pipeline, as I described it, should be entirely out of scope for the spec.

Of course, as is also true regarding Web application behaviour, we can always
provide non-normative advice, so we aren't faced with a binary choice between
normative requirements, on one side, and giving no advice whatsoever, on the

My question for the working group, then, is this:

In general terms, what should (1) the user-agent conformance requirements, and
(2) the Web application conformance requirements, if any, be?

If we can agree on the nature of the conformance requirements, at least
provisionally, these will define what is in scope. Along with this we can
decide what non-normative recommendations to give to implementors in the spec.
Received on Thursday, 7 February 2013 06:20:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:15 UTC