Re: [Vibration] Feedback on the Vibration API

Hi David,

On 6.11.2012, at 9.46, ext David Bruant wrote:

> Le 06/11/2012 00:05, Marcos Caceres a écrit :
>>> I
>>> assume knowing when the device stopped vibrating is an important
>>> information when you want your user to have a compelling experience.
>> Maybe, what's the use case you were thinking of? I think it's deliberately designed to be "fire and forget".
> I want to wait for a vibration pattern to end before starting a new one. I want the previous to end to offer a consistent experience; I don't want to randomly cut a vibration pattern because I'm starting the new one.

In early drafts we had 'vibrationstart' and 'vibrationend' events but we dropped them from v1 as we did not have compelling use cases for them. As always, we're happy to reconsider adding something similar in v2 if we unearth new use cases. I've added a note about this to our FutureWork wiki, so we don't forget:

  http://www.w3.org/2009/dap/wiki/FutureWork

>>> Step 3, 5 and 7 of the processing vibration patterns algorithm mention
>>> implementation-dependent limits and throw according to these. However,
>>> an application has no way to know these limits, so an application can't
>>> adapt its behavior to different implementation limits. I think it would
>>> be nice of the implementation to provide these limits as constants.
>>> I'm afraid that from an application author perspective, the only
>>> alternative is try out values to figure out the limits and "try out
>>> values" means actually vibrating or do weird hacks like:
>>> 
>>> try{
>>> navigator.vibrate(10000);
>>> navigator.vibrate(0); // cancel vibration if it occured
>> What use case did you have in mind for knowing the limits?
> Using the API and being sure it will actually vibrate the way I intend to?
> If, for some reason, the device can't vibrate for 2 seconds and that's I want to do, I wish I knew it before getting in a situation where I need to vibrate 2 seconds, so that I can define a fallback behavior instead, for instance.
> 
> To authors, the spec is saying "use this function to vibrate, but it will throw for some implementation-independent values, but you have no way to know them, good luck!"

The expectation is that implementations set the limit to a reasonable level and do that for a good reason. E.g. sometimes the user may not want the device to vibrate at all, but does not want the web app to know that due to privacy reasons.

I don't think we have a high value use cases for vibrating for a very long time outside of adult industry, so in most cases you should not hit the limit anyway. 

> Also, in the physical world, I doubt devices can vibrate for durations as low as one millisecond. If that's the case, I might be worthwhile exposing a minimum time.


Similarly to the maximum time, that's an implementation detail that should not be exposed to the Web.

> Is using the API in a WebWorker a planned use case or is it on purpose that it's completely banned?


Banned on purpose. Only a limited set of Web APIs are exposed to workers. There's no access to non-thread safe components or the DOM. And in this particular case the WorkerNavigator is very limited:

  http://dev.w3.org/html5/workers/#the-workernavigator-object

David, thanks for your feedback!

-Anssi

Received on Tuesday, 6 November 2012 09:36:23 UTC