ISSUE-280: 3.3 User awareness and control

adam

3.3 User awareness and control

State:

CLOSED

Product:

Mobile Web Applications Best Practices

Raised by:

Adam Connors

Opened on:

2008-09-18

Description:

Bryan comments:

Under "3.3 User awareness and control"

The current draft does not contain any guidance on ("effective means to control") as indicated in "The use of such personal information and device functions can expose the user to privacy and security concerns. The overall goal is that the user is informed of such activities, given effective means to control them, and also the opportunity to opt-out of application/function use", other than for network activity ("Means should be provided to disable any automatic network activity" in 3.3.1.1).

There was much more useful information in the earlier draft (20080522) in this area, e.g.

+++++

4.3.4.2 How to do it

Users should be given easy-to-use controls to personalize application behavior, e.g.

- If an application uses AJAX requests to poll for updates from a server, the user should be able to turn off the polling, or adjust the schedule.

- Users should be able limit application use of personal data, or delivery of it over networks.

- Users should be able limit application use of sensitive device API's, e.g. location, filesystem, PIM data, media recording, etc.

- Users should be able to select the security level for requests and data sent over networks.

If user control over sensitive application functions is not provided, users should be given the chance to opt-out for the function, or to terminate the application.

User control preferences should be saved by the application to avoid the need to reenter them each time the application is used.

+++++

I recommend that these details be restored. As it stands, the document basically says the user should be able to turn off problematic behavior (either by denying an API prompt, or other on/off means). Simple as that is, it doesn't cover the useful case where the user can *limit* behavior (as compared to completely disabling it), while still retaining application functionality.


Adam comments:

->->-> Some key points from 4.3.4 preamble were moved into "Cookies and Redirection"

->->-> Re: Section 4.3.4.2: Pt 1 implies a level of configuration that is excessive for most web-applications (e.g. being able to set the polling schedule). Pts 2 & 3 say the same thing as each other. Being able to allow/deny on a per API basis is (in every case I know of) the native implementation. Pt 4) Implies that every web-application have a configuration step to switch in to HTTPS mode? Which is a strong requirement to put in a BP.

->->-> In the form expressed here an inexperienced developer might feel compelled to create highly configurable applications in order to follow the recommendation. I think this would be misleading advice.

->->-> There is something nuanced in what a Best-Practice means that we should discuss. We should either be able to provide concrete examples of how implementing a given BP improves the experience and be aware that a "Best-Pratice Recommendation" is quite a strong terminology and guard against the detrimental effects of someone feeling compelled to follow them to the letter.

Related Actions Items:

No related actions

Related emails:

1. [minutes] Tuesday 7 July 2009 teleconf (from fd@w3.org on 2009-07-07)
2. [Minutes] Minutes from the MWABP Editorial Meeting 2008-09-26 (from jrabin@mtld.mobi on 2008-09-26)
3. ISSUE-280 (adam): 3.3 User awareness and control [Mobile Web Applications Best Practices] (from sysbot+tracker@w3.org on 2008-09-18)

Related notes:

Display change log