Prompting discussion outcome

I'd like to confirm my understanding of the DAP minutes  re policy  
discussion on prompting

If I read it correctly we are in agreement with what Ian summarized:

http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0133.html

1. Users will generally ignore security prompts in the quest to get  
things done.

2. A prompt that is meaningful in the task context can also fulfill  
security purposes and is preferred, like asking which file to upload.   
We might want to list these for the various APIs we are developing?

3. A callback mechanism allows choices to be displayed in the context,  
e.g. provide location at granularity of city, street or not-at-all  
(rather than a generic permissions prompt) or an event interface that  
requires user action (e.g. drag and drop) to implicitly give permission

I think Paddy is taking an action to write this in more detail.

regards, Frederick

Frederick Hirsch
Nokia



On Oct 15, 2009, at 3:34 AM, ext Robin Berjon wrote:

> Here they are:
>
>   http://www.w3.org/2009/10/14-dap-minutes.html
>
> And in text:
>
>    [1]W3C
>
>       [1] http://www.w3.org/
>
>                                - DRAFT -
>
>           Device APIs and Policy Working Group Teleconference
>
> 14 Oct 2009
>
>    [2]Agenda
>
>       [2] http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0148.html
>
>    See also: [3]IRC log
>
>       [3] http://www.w3.org/2009/10/14-dap-irc
>
> Attendees
>
>    Present
>           Marco_Marengo, Paddy_Byers, Robin_Berjon, Daniel_Coloma,
>           wonsuk, David_Rogers, Dzung_Tran, Ilkka_Oksanen,
>           Anssi_Kostiainen, Richard_Tibbett, Marcin_Hanclik,
>           WonSuk_Lee, Claes_Nilsson, Kangchan
>
>    Regrets
>           Frederick_Hirsch, Niklas_Widell, Dominique_Hazael-Massieux,
>           Venezia_Claudio, Steve_Lewontin, Daniel, Coloma
>
>    Chair
>           Robin Berjon
>
>    Scribe
>           Bryan Sullivan, Bryan1
>
> Contents
>
>      * [4]Topics
>          1. [5]Welcome, agenda review, scribe selection
>          2. [6]Minutes approval
>          3. [7]Editorial Updates
>          4. [8]Policy Segment
>          5. [9]ISSUE-32
>          6. [10]API Segment
>          7. [11]AOB
>      * [12]Summary of Action Items
>      _________________________________________________________
>
>
>
>    <trackbot> Date: 14 October 2009
>
>    <darobin> tlr: Zakim is buggy it seems...
>
>    <tlr> darobin, known problem, we'll need to deal with it
>
>    <darobin> ok, cool
>
>    <dtran> +dtran
>
>    <dtran> dtran is Dzung_Tran
>
>    <arve_> I am on the call at least
>
>    <darobin> arve_, it's a bug
>
>    <darobin> we need an "RRSAgent who's here?"
>
>    <darobin> can anyone hear me?
>
>    <paddy> I can hear
>
>    <darobin> arve_, are you on the call?
>
>    <darobin> Scribe: Bryan Sullivan
>
>    <darobin> ScribeNick: Bryan
>
> Welcome, agenda review, scribe selection
>
>    tlr: tpac plans for a privacy related panel, what does it mean to  
> be
>    privacy aware
>
>    <arve_> whoever got on last needs to mute
>
>    <drogersuk> great, white noise
>
>    <tlr> *ARGH*
>
>    <darobin> bloody hell
>
>    <drogersuk> will dial back in when you are sorted
>
>    tlr: the scope of policy related work, very broadly, to drill down
>    on the intellectual side of the topic
>    ... just calling to attention the plans to have a discussion
>
> Minutes approval
>
>    <darobin>
>    [13]http://www.w3.org/mid/6CC33B25-9534-4030-8445- 
> F0CC02566944@nokia
>    .com
>
>      [13] http://www.w3.org/mid/6CC33B25-9534-4030-8445-F0CC02566944@nokia.com
>
> Editorial Updates
>
>    robin: minutes are approved
>
>    <darobin> [14]http://www.w3.org/TR/dap-api-reqs/
>
>      [14] http://www.w3.org/TR/dap-api-reqs/
>
>    robin: api requirements should be available tomorrow at the address
>    shown
>    ... any other edits made last week?
>    ... none so far
>
> Policy Segment
>
>    robin: some discussions this week about prompting, any comments on
>    where the discussion is and next steps
>
>    paddy: a wide range of starkly differing views. prompting is
>    inescapapable given the wide range of apps expected, and
>    unfamiliarity with the app, and the need to make decisions
>
>    <tlr> agreement: "it's difficult"
>
>    paddy: good questions about when prompts should occur, e.g. re
>    lifecycle and obstrusiveness
>    ... seems agreement on modality, and that we should stay away from
>    user experience proscription
>    ... but only concrete conclusion is the non-modal prompt  
> expectation
>
>    richard: agrees, non-modal is better. we should use the term dialog
>    instead of prompt. the concept of user opt-in should be defined.
>    ... user needs to have an opt-in option, but before that the user
>    should expect prompts. Ian made a good comment, about difficulty
>    addressing all cases. But implicit prompting is usedful, e.g. based
>    upon platform filesystem functions.
>
>    thomas: leaning the same direction; we know a lot that doesn't  
> work,
>    some that do work, e.g. re implicit concepts such as pushing a
>    button on a camera. non-modalness is important.
>
>    <Zakim> darobin, you wanted to talk about UI terminology
>
>    thomas: question about what info is available to the user-agent
>    about the user's intent
>
>    <darobin> [15]http://www.w3.org/WAI/intro/aria.php
>
>      [15] http://www.w3.org/WAI/intro/aria.php
>
>    robin: terminonology may consider aria for terminology, see link
>
>    <paddy> I can do that
>
>    robin: hearing support for the general ideas, would someone write  
> up
>    the agreement
>    ... paddy has the action to do it
>
>    <darobin> ACTION: Paddy to document the output of the prompting
>    discussion [recorded in
>    [16]http://www.w3.org/2009/10/14-dap-minutes.html#action01]
>
>    <trackbot> Created ACTION-28 - Document the output of the prompting
>    discussion [on Paddy Byers - due 2009-10-21].
>
>    robin: paddy created a new issue
>
> ISSUE-32
>
>    paddy: question was having a policy governing access to resources,
>    how to id the resources portably in ways meaningful to policy
>    authors
>    ... have written down some thoughts and terminology to get the
>    discussion started, e.g. "device capability" which is definable
>    independent of the API's used to get access to the capability
>    ... next interfaces, which are directly related to the API's
>    accessing the resources
>    ... next the "feature" which are the API functional capabilities
>    ... we have had discussion on using IRI to id the resources
>    ... 2nd question is whether need to id the capabilities themselves,
>    to allow API-independent policies
>
>    <tlr> excellent point
>
>    paddy: so access to a capability is controllable independent of the
>    API, which is what BONDI supports
>    ... propose to discuss / validate the use cases and decide how to
>    address this for DAP policy
>
>    robin: any reactions now?
>    ... now this is started, input is requested and discussion. unsure
>    how the policy docs will be organized, but we could paste some of
>    this into a document for review. we will discuss this when Fredric
>    is here.
>    ... anything else on policy?
>
> API Segment
>
>    robin: item discussed is where do we want the API to hang off of.
>    some inputs, e.g. we may not want to define it immediately.
>    ... so I recommend to wait for more API's to be defined then return
>    to the hanging off discussion
>
>    <Bryan1> scribenick bryan1
>
>    <darobin> arve: only just got back, will look into FS ASAP
>
>    <Bryan1> scribe: Bryan1
>
>    <darobin> ScribeNick: Bryan1
>
>    <darobin> robin: will continue contacts discussion on list
>
>    <darobin> richt: will contact robin offline to start putting things
>    inside the calendar spc
>
>    robin: a lot of discussion on scoping, sensors, etc. anything to
>    discuss now?
>    ... will wait for the concrete input and take it from there
>
>    <darobin> richt: I will join the editorial pool for APIs
>
>    richard: will join the editor pool
>
> AOB
>
>    robin: anything else on APany other business
>
>    richard: "meta-discussion" on the list. any guidelines for list
>    discussion?
>
>    robin: discussion about how to conduct discussion. we will make
>    easier progress if we edit and them consider the edits, rather than
>    discuss too long up-front
>    ... sometimes its better to dive in and assess where we are
>    periodically
>    ... it would be good to have some concrete work done before the  
> F2F,
>    and take a step back at the F2F
>
>    david: agree, key concern raised by me is that the charter has 10
>    API's. we need to concentrate on those. new ideas are expected, but
>    the three inputs so far focus on a set of API's
>    ... being royalty-free, we should focus on them
>
>    robin: there is some grey area due to vagueness in the charter,  
> with
>    wiggle room expected. but we need to wait for concrete proposals  
> and
>    consider IPR issues as they arise
>    ... AOB?
>
>    <darobin> thanks Bryan
>
>    <darobin> RRSAgent: make minutes
>
> Summary of Action Items
>
>    [NEW] ACTION: Paddy to document the output of the prompting
>    discussion [recorded in
>    [17]http://www.w3.org/2009/10/14-dap-minutes.html#action01]
>
>    [End of minutes]
>      _________________________________________________________
>
>
>     Minutes formatted by David Booth's [18]scribe.perl version 1.135
>     ([19]CVS log)
>     $Date: 2009/10/14 14:37:06 $
>      _________________________________________________________
>
>      [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ 
> scribedoc.htm
>      [19] http://dev.w3.org/cvsweb/2002/scribe/
>
>
> -- 
> Robin Berjon - http://berjon.com/
>
>
>
>

Received on Monday, 19 October 2009 20:22:24 UTC