Re: Implied Pairs in the Vibration API

Hi Iain,

On 16 Feb 2014, at 20:18, Iain Dawson <iain@musicfortheblind.co.uk> wrote:

> I really don't like that the Vibration API assigns meaning to the numbers in lists handed to it based solely on the oddness of their indices. This means developers have to be incredibly careful to only ever extend their lists two items at a time or risk subtle, difficult-to-track-down bugs.

I definitely wouldn't recommend people to write very complex vibration patterns by hand. The syntax should be relatively straight forward for simple and short patterns though.

> One solution would be to create lists of lists of [activeTime, restTime], but even this creates a situation where future extensions of the API would have to run on top of a completely different interface.
> 
> From my perspective, the *right* way to do this, while a little more verbose, would be much more extensible and much more explicit; have the thing take a list of vibration objects formatted something like {time: [number], vibrate: [bool]}. This means you don't have to keep track of the index of every item you append to your list and you open the door to future parameters such as intensity or, who knows, motor selection in hypothetical multi-vibration-motor devices.

It should be relatively easy to transform such a syntax to the standard one. A naive implementation might be:

function humanFriendlyVibrate(input) {
  var output = [];
  input.forEach(function(p) { output.push(p.time); });
  navigator.vibrate(output);
}

I see an opportunity here for someone to craft a library that makes writing vibration patterns by hand even more fun :-)

The API was intentionally scoped tightly, and the group deferred advanced features such as intensity and multiple motors to a potential future version.

Now that we have multiple implementations out, it appears people are successfully emulating intensity with the existing API, so we may not need to spec that explicitly.

Re multi-vibration-motor devices, some time ago game controllers were the only class of devices widely available that had multiple motors. Are you aware of any other type of devices that provide such a functionality?

> It would, of course, be possible to support all three of these interfaces, if so desired.

Thank you for your feedback.

Thanks,

-Anssi

Received on Monday, 17 February 2014 14:52:00 UTC