W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2011

Re: Device task source

From: Rich Tibbett <richt@opera.com>
Date: Wed, 06 Apr 2011 14:13:23 +0200
Message-ID: <4D9C58E3.6050101@opera.com>
To: Robin Berjon <robin@berjon.com>
CC: public-device-apis@w3.org
Robin Berjon wrote:
> Hi,
> the Contacts draft currently refers to a "device task source". It uses it notably in its find operation, where if there's an existing ongoing task from this source an error is dispatched.
> The problem is that this is a generic task source (at least in name), which means that Calendar, for instance, would also use it. But it doesn't make sense to error on contacts.find() if I call calendar.findEvent().

That was how I originally intended for it to work and for each Device 
API to share the same task source. It was to prevent a web app from 
overloading the user with actions from multiple task sources and to put 
the onus on producing a good user experience on to web developers: where 
the user is not bombarded with multiple actionable messages in quick 
succession but instead only requests them on-demand.

> So is the solution to:
>    a) have different task sources for each spec (in which case a name change is in order);
>    b) have the cancellation trigger only if a similar operation is ongoing.

Both of these solutions allow a web developer to overload a user with 
multiple actionable notifications. I'd prefer to leave it as-is and work 
with implementers on changing it as necessary depending on the derived 
user interactions they come up with. For now, it is effectively a 
proposal to serialize such opt-in dialogs until we've got some real 
implementation experience.

> I'm thinking (b). I can implement this change once we agree (I have to massage the whole task source situation anyway).

- Rich
Received on Wednesday, 6 April 2011 12:13:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:48 UTC