W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ISSUE-16: Gathering requirements [User Interaction API]

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Tue, 20 Oct 2009 10:13:06 +0300
Cc: Device APIs and Policy Working Group WG <public-device-apis@w3.org>
Message-Id: <85F8F94B-BBFA-448D-AE2F-B16B100D4AED@nokia.com>
To: ext Brian LeRoux <brian@westcoastlogic.com>
On 20.10.2009, at 1.19, ext Brian LeRoux wrote:

> Perhaps of interest from a mobile device perspective a notification
> can be of the form of vibration or different lights found on the phone
> (Blackberrys have a bewildering array / the new Palm Pre has two nice
> lights on either side of the home button to indicate different
> gestures have been entered such as back/forward). Sometimes a
> notification might be a beep!
> So, notifications may not take the form of a modal/non-modal dialogue.

A very good point. I unintentionally excluded those as they were part  
of the "User Interface" requirements:


Now I see that at some point we've renamed the "User Interaction" (as  
in Charter) into "User Interface" (as in requirements) as it seems  
they overlap with each other -- I have missed that discussion.

Anyhow, I don't think it is worthwhile to get caught with the  
semantics of the definitions. I agree that beeping, vibrating and  
manipulation of backlight(s) is something current devices support out- 
of-the-box so they obviously are the low hanging fruits to be included  
in the v1. Perhaps those notification mechanisms I listed below should  
be put into the "may be considered in the future versions" section?

Related to this I was also thinking how to make these user interaction  
related APIs -- which by nature tend to be more device-dependent --  
more device-agnostic. Here's my brain dump of available options:

A) Describe in the prose what UAs w/o e.g. vibrating support should do  
if there's an alternative mechanism available that could serve as a  
fallback (think gentle electric shock?-)). Optionally allow developers  
to control whether the use of a fallback mechanism is permitted.

B) Raise the abstraction level so that the developer can just say  
"notify the user using any alerting mechanism available which is not  
audible". This would map into vibrating on devices supporting it and  
fall back to blinking backlights or taskbar/whatnot on the rest. This  
could be provided in addition to more granular APIs.

C) Do nothing intelligent. Developers are accustomed to detecting  
feature support and acting accordingly depending on what's supported  
on the target platform(s).

I'm sure some of the above ideas are (or have been proven to be) bad  
so I'd like to hear everyone's thoughts on this :-)


> On Mon, Oct 19, 2009 at 9:09 AM, Anssi Kostiainen
> <anssi.kostiainen@nokia.com> wrote:
>> On 25.8.2009, at 16.29, ext Device APIs and Policy Working Group  
>> Issue
>> Tracker wrote:
>>> ISSUE-16: Gathering requirements [User Interaction API]
>>> http://www.w3.org/2009/dap/track/issues/16
>> It seems the ISSUE-16 has not been discussed on the list yet. To  
>> recap,
>> according to the Charter deliverables section:
>> [[
>> User Interaction API, a set of APIs that gives a widget or website  
>> far
>> better control of how it manifests itself on different platforms.  
>> This would
>> include minimise/maximise functions, window size, alerting  
>> mechanisms etc.
>> ]]
>> Below is a summary of prior art related to "alerting mechanisms"  
>> after a
>> quick scan.
>> The getAttention() and showNotification() methods were specified in  
>> the
>> earlier WDs of the Widgets A+E spec [1] but have since been removed
>> presumably due scope creep and inconsistency concerns with what HTML5
>> specifies(?). The notification functionality has also been in the  
>> HTML5 spec
>> (see e.g. [2]) at some point, but has been removed due to lack of  
>> interest
>> [3]. Summary of related specs:
>>  - getAttention() and showNotification() in Widgets A+E [1]
>>  - showNotification() in HTML5 [2]
>> Related implementations:
>>  - create/showNotification() in Gears [4]
>>  - createPopup() in IE [5]
>>  - create[HTML]Notification() in WebKit [6,7]
>> Older discussion which pre-dates (most of) the above:
>>   - getAttention() [8] and showNotification() [9] at Bugzilla@Mozilla
>> I believe these resources can help us extract practical  
>> requirements based
>> on real implementations and developer experiences if the group sees  
>> this is
>> something that should be worked on further (also please point out  
>> if this is
>> already being actively addressed by some other WG).
>> -Anssi
>> [1] <http://www.w3.org/TR/2009/WD-widgets-apis-20090423/>
>> [2] <http://html5.org/tools/web-apps-tracker?from=2596&to=2597>
>> [3]
>> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-December/017997.html 
>> >
>> [4] <http://code.google.com/p/gears/wiki/NotificationAPI>
>> [5] <http://msdn.microsoft.com/en-us/library/ms536392%28VS. 
>> 85%29.aspx>
>> [6] <https://bugs.webkit.org/show_bug.cgi?id=25463>
>> [7] <http://trac.webkit.org/changeset/47056>
>> [8] <https://bugzilla.mozilla.org/show_bug.cgi?id=293077>
>> [9] <https://bugzilla.mozilla.org/show_bug.cgi?id=293412>
Received on Tuesday, 20 October 2009 07:12:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:12 UTC