W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2012

Re: [Vibration] Feedback on the Vibration API

From: Marcos Caceres <w3c@marcosc.com>
Date: Mon, 5 Nov 2012 23:05:58 +0000
To: David Bruant <bruant.d@gmail.com>
Cc: public-device-apis@w3.org
Message-ID: <0C32F3B17B194E4985EE6F6F07A34A5D@marcosc.com>
Hi David, 

On Monday, 5 November 2012 at 17:46, David Bruant wrote:

> 
> What happens?
> 1) The device vibrates for a second then logs 'yo'

Nope.  
> 2) The device starts vibrating, logs 'yo' while vibrating and ends vibrating

yep.  
> 3) something else (explain)
> 
> Case 1 would be an aberrant waste of CPU time especially for long
> sequences of vibrate/idle. Also games are known to use UX trick to
> compute things in the background. Vibrating to deconcentrate the user
> may be one of these tricks.

Yep, it's async.  
> 
> In case of 2, how do you know when the device stopped vibrating?
I don't think that information is available, unfortunately.  
> 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".  
> 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?  
Received on Monday, 5 November 2012 23:06:28 UTC

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