- From: Andy Heath <andyheath@axelrod.plus.com>
- Date: Thu, 07 Feb 2013 05:51:15 +0000
- 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. Cheers andy -- __________________ Andy Heath http://axelafa.com
Received on Thursday, 7 February 2013 05:51:47 UTC