Re: [w3ctag/design-reviews] Vibration API (Issue #971)

Thanks for your review!

We consulted the Gamepad API editor to understand whether it'd be feasible to repurpose the current Gamepad API to cater for the Vibration API use cases as suggested. In our discussion we concluded it is not possible. For details, please see the [meeting minutes](https://www.w3.org/2024/09/24-dap-minutes.html#t28).

For considered alternatives, we've looked at [HapticsDevice API](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HapticsDevice/explainer.md) proposal that targets haptic-enabled surfaces and gaming controllers. There are a few important areas where that API (that exists in an explainer form only?) differs materially from the Vibration API:

HapticsDevice API defines non-interactive haptic feedback as out of scope, tying haptics into the PointerEvent interface. The Vibration API allows non-interactive feedback after the user has interacted with the page once (sticky activation). Non-interactive feedback has use cases in both gaming and web apps where the feedback is delivered in response to some event happening, not just in response to user interaction that triggers a PointerEvent. Such use cases include e.g. a game where a character bumps into a wall or an app where a long-running process finishes followed by a vibration to inform the user.

Another design consideration where the two APIs differ in a use case impacting way is that the HapticsDevice API supports implementation-defined waveforms (aka Pre-Defined Waveforms) while the Vibration API supports on-off pulses only. The latter provides a consistent experience across platforms, while the former as implementation-defined provides consistency within a one native platform only, but not across multiple platforms. 

(We're aware of [interesting](https://github.com/jmattthew/vibration-generator) [experiments](https://github.com/SomaticLabs/haptics.js) that create more complex waveforms using the Vibration API on-off pulses as low-level primitives to demonstrate feasibility of consistent waveform generation across platforms. This lowering approach follows the [EWM](https://extensiblewebmanifesto.org/) principles.)

Since the Vibration API predates the explainer-era we did not have an explainer handy. We hope this comment addressed your questions and unblocks this review. I've filed https://github.com/w3c/vibration/issues/45 for the explainer and we'll incorporate insights from this review into that document. Thank you!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/971#issuecomment-2388761466
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/971/2388761466@github.com>