Vibration API Tutorial

[KraigWalker]

Prelude

I've been getting my teeth cut working on a browser game for work. One of the fun little additions we've added is support for the HTML5 Gamepad API. Reading button presses off an Xbox 360 controller was easy enough; but then we just had to ask "What About Force Feedback? It's been in controllers since the 90's. Right?"

After a couple of emails to the editors of the Gamepad API demanding to know where our precious rumble pak was, Scott Graham got in touch, saying the feature had been "lightly discussed" in the early days of the Gamepad API, and has since now taken a form of it's own: The Vibration API

And we were like...

Say Hi to the HTML5 Vibration API

The Vibration API is one of few API specifically intended with gaming in mind. In contrast with the Gamepad API however, which is slowly building up a wider user base, many people I've spoken to, not to mention many documentation sources, didn't get the memo about also being able to make those gamepads wiggle.

It is logical however to keep the two API's separate however. Devices like the original Xperia Play come with their own gamepad and thumbsticks, it does not however have vibrating motors intended for gaming.

What I'd Like To Do

I'd like to write a tutorial to get people up and running with the Vibration API. It's not the biggest, most complicated API in the world, but I feel it's the missing part of the Gamepad API that a lot of people aren't aware of. The biggest impact I think it can have is in getting the ball rolling with discussion on how the API can be improved on. The core topics being discussed in the tutorial would be:

• A high level overview of what the Vibration API does
• What browsers currently support the API
• What devices should be used with Vibration
• A cross-browser friendly method of using Vibration in games and web apps
• Understanding how vibration patterns work
• Using patterns to create different types of rumble effects (with examples, of course)
• Some limitations to bear in mind
• What the future might hold for Vibration

What I'm Also Going To Do

I'm going to address some awareness issues on projects like HTML5 Please, which doesn't yet list the API yet.
Modernizr added support for detecting Vibration support in 2.6, which I'd like to use in my tutorial in a similar way to the Gamepad API tutorial by Marcin Wichary.

May The Force (Feedback) Be With You

[ebidel]

Haha. Nice proposal. What's the current browser support look like?

[KraigWalker]

Thanks :) The API is currently implemented in Firefox and Chrome, with that branching out to the main webkit branch once it's progressed further through Standardisation. There are some tiny differences between the two implementations, but the functionality is identical.

[ebidel]

I think it may be implemented in WebKit, but it's behind a compile time flag. Believe it only works in FF mobile, no?

http://davidwalsh.name/demo/vibrate.php

[KraigWalker]

According to the webkit changelogs, you're right The Vibration API was quietly added to Webkit about a year ago. Chrome, however, is the only webkit browser to have it in a stable release. As for Firefox, it was included in 11.0 of Gecko with an additional moz prefix, which was dropped in version 16.0 (though the Gecko uses window.navigator.vibrate as opposed to webkit's window.vibrate)

Sounds a little convoluted, but basically, it will run in any Chrome and Firefox version less than a year old. Safari (and a webkit Opera?) will follow suite.

Again, the more usage examples that people start finding, the more popular the technique will become and the API will start getting a bit more love and affection 🏩

[psema4]

Hmm. I asked on StackOverflow about Vibration API support in Google Chrome and got back the following response from Chrome Developer Relations: "We don't have it in Chrome for Desktop and we don't have it in Chrome for Android as of version 25." That was about 2 weeks ago: http://stackoverflow.com/questions/13633561/where-is-the-vibration-api-hiding-in-chrome-23/14831924

[ebidel]

Correct. It's not in Chrome.

On Wed, Feb 27, 2013 at 8:00 AM, Scott Elcomb [email protected]:

Hmm. I asked on StackOverflow about Vibration API support in Google Chrome
and got back the following response from Chrome Developer Relations: "We
don't have it in Chrome for Desktop and we don't have it in Chrome for
Android as of version 25." That was about 2 weeks ago:
http://stackoverflow.com/questions/13633561/where-is-the-vibration-api-hiding-in-chrome-23/14831924

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/297#issuecomment-14181530
.

[KraigWalker]

Sad times. a simple if check on navigator.vibrate turns up as not supported (chrome 25) - all the chromium issues I was researching were documenting the progress of including it in webkit.

So I guess the initial tutorial would only work in Firefox, but could it be updated once vendors start including the webkit implementation?

[ebidel]

Mind pinging https://code.google.com/p/chromium/issues/detail?id=114524 and
seeing where things are?

On Wed, Feb 27, 2013 at 9:25 AM, Kraig Walker [email protected]:

Sad times. a simple if check on navigator.vibrate turns up as not
supported (chrome 25) - all the chromium issues I was researching were
documenting the progress of including it in webkit.

So I guess the initial tutorial would only work in Firefox, but could it
be updated once vendors start including the webkit implementation?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/297#issuecomment-14186829
.

[paulirish]

to see if any other ports have it on.. see the "skipped" files from this
commit ... http://trac.webkit.org/changeset/108272
...and see if this skip line is still present in them today.

On Wed, Feb 27, 2013 at 7:25 PM, Eric Bidelman [email protected]:

Mind pinging https://code.google.com/p/chromium/issues/detail?id=114524and
seeing where things are?

On Wed, Feb 27, 2013 at 9:25 AM, Kraig Walker [email protected]:

Sad times. a simple if check on navigator.vibrate turns up as not
supported (chrome 25) - all the chromium issues I was researching were
documenting the progress of including it in webkit.

So I guess the initial tutorial would only work in Firefox, but could it
be updated once vendors start including the webkit implementation?

—
Reply to this email directly or view it on GitHub<
https://github.com/html5rocks/www.html5rocks.com/issues/297#issuecomment-14186829>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/297#issuecomment-14214730
.

[PaulKinlan]

Given the changes happening, I would be pretty keen to see this article written.

[PaulKinlan]

@KraigWalker - are you still up for writing this article? Vibration is being worked on in Chrome for android.

[KraigWalker]

Sure! I’ve been keeping an ear out on the w3c mailing list and recently saw some people talking about implimenting it on Chromium and Blink. Great to see it’s moving forward.

I’ll be able to start a plan during the weekend sometime, maybe include some functional demos in the final article?

http://www.kraigwalker.com

On 9 Oct 2013, at 17:24, Paul Kinlan [email protected] wrote:

@KraigWalker - are you still up for writing this article? Vibration is being worked on in Chrome for android.

—
Reply to this email directly or view it on GitHub.

[PaulKinlan]

Excellent, if you want to share a draft with me I can help review it. Inline demos would be very appreciated.

It would be good to also set a due date (nothing too close) so that I can plan it in to our release schudule too.

Thanks!

[PaulKinlan]

@KraigWalker any update on this?

[maxh]

Any chance we could get this out in the next few weeks?

[pearlchen-old]

@KraigWalker Don't know if you're covering WebView or not but, fyi, latest WebView for Android now has vibe support. Good for those games packaged using Cordova.

[PaulKinlan]

Michael Van Ouwerkerk who implemented the API was planning on doing one.... will chase up.

[KraigWalker]

Hey guys. Thanks for your continued interest. I've been monitoring the development of the Vibration API spec with the W3C working group. The interesting thing that divides the spec is the subject of gaming.

The current API is a simple sequence of on/off periods, where the vibration is either full on, or full off; naturally.

Of course gaming has had a rich history over the last 20 years of having variable levels of intensity (aka Dual Shock if you're a play station fan) where controllers typically have two or more motors - one for a big kick, the other for more sustained, higher frequency rumbles.

I had been holding out, hoping a resolution would come for developers with an interest in gaming on the web platform (which is now more relevant than ever thanks to the likes of WebGL)

The two ideas on the table are to create a new level of the Gamepad API that supports multiple motors/intensity settings or to create a new level of the Vibration API

That being said, I'm wondering if you guys have any suggestions for demos to put in a tutorial. The challenge I think is not necessarily in teaching the use of the API (which is very simplistic) but in opening the imagination up to it's potential (and tasteful) uses on the web.

My immediate (and probably most obvious) thought is on-page notifications. Either for success/fail dialogues when filling out forms, or when a new activity happens on the site you're currently browsing.

I'm thinking maybe a Lost style number input form, which has one vibration pattern for failure, another for success.

Maybe that's as much as we need to go into? I'd perhaps like to discuss another demo example where the user can interrupt or override the current vibration pattern being played. Maybe a text to morse code translator/playback or something?

Also, I've got Thursday & Friday off for working on something, so definitely interested in moving this forward with the current API spec in mind.

Sent from my iPhone

On 7 Jun 2014, at 15:34, Pearl Chen [email protected] wrote:

@KraigWalker Don't know if you're covering WebView or not but, fyi, latest WebView for Android now has vibe support. Good for those games packaged using Cordova.

—
Reply to this email directly or view it on GitHub.

[PaulKinlan]

My preference is to avoid gaming altogether for now and focus on places where it should be used as well as gotcha's and snags (i.e, if you mute your device there is no vibration). For example I would love to see how it can be used when validation of a form fails. Or an event happens that requires the users attention.

Also a small library of good patterns would be very handy.

[dasilvacontin]

@PaulKinlan I believe that if you mute your device there's only vibration and no sound - at least on iOS.

Not sure if avoiding gaming would be a good idea since it's probably going to be the most common case scenario in which the API is used.

[ghost]

To be honest, I think there should be a separate function for gamepad vibration like myGamepad.setVibration(leftMotor, rightMotor). The vibration API is supposed to target the entire device whereas a Gamepad vibration API would need to access individual devices for e.g. a 2-Player game.
I'd also like to see a way to have force feedback effects for devices that support them, in the future, like Joysticks and Steering Wheels which also could find ground in some medical applications as well. :)

[psema4]

I haven't been following the spec development very closely but noted the controversy; tbh I think the whole thing is kind of silly: when we use sound, it's either (for example) stereo or mono. We don't have a spec for each. Perhaps I should dig into it a bit deeper because I just don't get why having multiple motors is an issue.

@KraigWalker: my original use case (and something I still want to do) requires API support on desktop; I wanted to hijack the output line and create a serial interface to allow web apps (with awesome UI's) to control electronic devices.

[Polyducks]

I'm aware I'm conducting post necromancy here, but this is a discussion that had no real resolution.

I'd really like to see the rumble feature make it to web games. It adds an extra level of depth to the experience. As far as I'm aware, vibration support for game pads is not currently available in live or canary builds of browsers. Is this correct?

[KraigWalker]

Back when I proposed it the Vibration Spec was actually still in flux, but Mozilla had included support within Firefox in order to allow developers access to vibration in Firefox Phones (RIP) PhoneGap also replicated the API using a native bridge.

I had raised a question regarding gamepads in the mailing list way back then, and it became apparent that the vibration api wouldn't be a good fit for Game Pads. It's more focussed on supporting control of a mobile device's individual motor. Gamepads often have two or more motors of different sizes (the latest Xbox controller has four) – one typically provides a buzzing rumble and another serves as a 'kicker' for larger thumps and knocks.

So it was decided the vibration API would accept only a single array of vibration patterns at a time, and effect one global actuator on the device. It was recommended in order to achieve the desired level of fidelity of vibration on Game Pads that the JavaScript Game Pad API be worked upon instead to support the additional level of functionality.

This made sense, as the Game Pad API could squawk the device type, allowing the developer to provide the appropriate vibration patterns. A first party game controller may likely feel different from a third party one, as will a controller developed for a different console.

My only gripe is that this divides vibration support into two, and it may end up being the vibration API that winds up being redundant. As I type on this train, my phone's just given me a notification buzz with it's main actuator. But if I push down on a link a little harder a completely different motor springs into live along with some additional options on-screen. The strength of the Vibration API is it's simplicity, but it's also it's weakness as devices get more diverse.

On 30 May 2016, at 18:52, Ben Jones [email protected] wrote:

I'm aware I'm conducting post necromancy here, but this is a discussion that had no real resolution.

I'd really like to see the rumble feature make it to web games. It adds an extra level of depth to the experience. As far as I'm aware, vibration support for game pads is not currently available in live or canary builds of browsers. Is this correct?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Polyducks]

Thank you so much for your depthy response.

It may well be that mobile devices move on from a single vibration motor - when that happens a new API will be required which would support all devices (including game pads). Do you think this is possible?

[KraigWalker]

I think there's more likelihood of a second level of support being added to the gamepad API. Personally I think it would be a more appropriate area to add to. Of course, if a touch screen phone were to adopt that, there'd have to be a way of declaring "I actually don't have buttons or joypads."

I haven't subscribed to the working group mailing list on either the gamepad api or vibration. I'd recommend you find the on the w3c site, read a little bit of the backlog, and maybe pop the question? The wonders of open standards! 😍👍🏻

Sent from my iPhone

On 7 Jun 2016, at 10:15, Ben Jones [email protected] wrote:

Thank you so much for your depthy response.

It may well be that mobile devices move on from a single vibration motor - when that happens a new API will be required which would support all devices (including game pads). Do you think this is possible?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[KraigWalker]

UPDATE: In the span since I looked at vibration a proposal to extend the Gamepad API with vibration has been introduced:

https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0052.html https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0052.html

On 7 Jun 2016, at 10:15, Ben Jones [email protected] wrote:

Thank you so much for your depthy response.

It may well be that mobile devices move on from a single vibration motor - when that happens a new API will be required which would support all devices (including game pads). Do you think this is possible?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #297 (comment), or mute the thread https://github.com/notifications/unsubscribe/ABPCHbR7SHTXHo_G3tkcNHwVpxWFoOZ9ks5qJTatgaJpZM4Ab-ln.

[KraigWalker]

I’d recommend checking out https://iswebvrready.org/ https://iswebvrready.org/ which goes into support for new extensions to the gamepad api, including touchpads and posable VR controllers

On 7 Jun 2016, at 10:31, Kraig Walker [email protected] wrote:

I think there's more likelihood of a second level of support being added to the gamepad API. Personally I think it would be a more appropriate area to add to. Of course, if a touch screen phone were to adopt that, there'd have to be a way of declaring "I actually don't have buttons or joypads."

I haven't subscribed to the working group mailing list on either the gamepad api or vibration. I'd recommend you find the on the w3c site, read a little bit of the backlog, and maybe pop the question? The wonders of open standards! 😍👍🏻

Sent from my iPhone

On 7 Jun 2016, at 10:15, Ben Jones <[email protected] mailto:[email protected]> wrote:

Thank you so much for your depthy response.

It may well be that mobile devices move on from a single vibration motor - when that happens a new API will be required which would support all devices (including game pads). Do you think this is possible?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #297 (comment), or mute the thread https://github.com/notifications/unsubscribe/ABPCHbR7SHTXHo_G3tkcNHwVpxWFoOZ9ks5qJTatgaJpZM4Ab-ln.