Re: [Vibration] Feedback on the Vibration API

On Tuesday, 6 November 2012 at 07:46, David Bruant wrote:

> 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.

I can't claim to know if the following is true or not, but the hardware itself might be designed to be "fire and forget". Also, there may be some latency between when the request is made at the OS level, and when the hardware actually powers up and starts vibrating (which then also breaks knowing if there is a 1..1 reflection of state between software and hardware). My point being that we need to check on actual hardware if it's possible to have the level of reflection you are eluding to.  

As a data point, Android does not give this level of control:
http://developer.android.com/reference/android/os/Vibrator.html

And in iOS, vibration seems to be bound to an audio API?:
AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);

http://blog.ablepear.com/2010/02/iphone-sdk-shake-rattle-roll.html
  
Also, I can imagine that if I set an alarm on my phone to vibrate at a given time, and that time clashes with a pattern specified by a web app… then things are gonna get ugly.  
> > > 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.

I think this is valid, but if and only if there is actual evidence of hardware that is causing this problem (i.e., do you know of any phones where this is a problem?).   
> 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!"

Yeah, I agree that sounds kinda sucky, but again, does it really come up as an issue in the wild? I'm not saying this is invalid, just that we should not ad things "just in case".   
>  
> 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.

I don't know what the, um, "resolution" of vibration is on those modules. But it would be good if we could gather such data. But again, it's only really useful if we have actual examples of people hitting this as a problem in the wild.

Received on Tuesday, 6 November 2012 09:50:33 UTC