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

Hi Anssi,

On Oct 20, 2009, at 09:13 , Anssi Kostiainen wrote:
> 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.

There was no discussion, the change is entirely unintentional and I  
believe the result of me letting my fingers do too much of the  
thinking. It should probably be reverted to User Interaction.

> 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 think that there are use cases for two levels, and that we should  
address both.

There is the abstract, or device independent, level at which the  
developer simply wishes to draw the user's attention but wants to  
respect the user's wishes. This is a showNotification/alertUser/ 
whatever API, and its result is entirely system dependent: it may  
vibrate, ring, beep, flash some lights, or pop up a disco ball —  
that's up to the user to figure out.

Then there is the other side which is that the developer may wish to  
use the vibration mechanism (say, for instance, to match collisions in  
a game). This is a vibrate() API, and if the device can't vibrate then  
I expect that nothing happens (or some other error handling mechanism).

Note that another aspect (supported by BONDI) of the UI deliverable is  
the ability to control menus. This has clear value in that a web  
application could declare its own menu (which could be one of the two  
menus on a mobile, an extra menu entry on a desktop, etc.) and  
therefore have better integration with the system, but I am wondering  
what its relationship with HTML's <menu> element is. I'd be interested  
in input on that.

--
Robin Berjon
   robineko — hired gun, higher standards
   http://robineko.com/

Received on Tuesday, 20 October 2009 13:51:26 UTC