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

Re: Scope of User Contexts specification

From: Andy Heath <andyheath@axelrod.plus.com>
Date: Thu, 07 Feb 2013 05:51:15 +0000
Message-ID: <511340D3.3030205@axelrod.plus.com>
To: public-indie-ui@w3.org
Thankyou Jason. I think this is a very good analysis.  I don't see it as 
opinionated but I am very opinionated so who knows. I just want to make 
a very tiny clarification - forgive me for editing out the surrounding 
context so as to make it visible:

> However, the proposal discussed at the meeting indicates that the application
> should achieve a "best match" of its capabilities with the expressed
> need/preference profile of the user. This suggests that some aspects of the
> application's behaviour will need to lie within the scope of the spec, and
> this should be more clearly delineated.

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.

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.  My own 
goals are to enable this to happen because in my experience its what 
real users need.

I'm talking V1 here. Questions about extension and API's outside of the 
browser/device API and whose cloud we're talking about (that's an ugly 
one) seem to me to be an order of magnitude harder and ought to be 
deferred beyond V1 and so I'm arguing for prefs being handled with 
closed vocabularies within an API on the device and set at the device UI 
(and dynamically by device OS) for now.


Andy Heath
Received on Thursday, 7 February 2013 05:51:47 UTC

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