Re: [Vibration] Feedback on the Vibration API

Hi Marcos,

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.

>> 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!"


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.

David

Received on Tuesday, 6 November 2012 07:47:13 UTC