Re: [vibration] Update implementation report (#33)

>@marcoscaceres, can you clarify why you think this is misuse? It is a common pattern in mobile games to use on-screen controls to emulate a gamepad, and haptics are a reasonable part of this. 

Right, again, the validity of the use case is not in question. It is if the API is suitable to meet the use cases, and the implications that every website then has access to the API leading to all the abuse/misuse cases.

Please consider that it's possible to, for instance, on certain platforms to overlay a [virtual gamepad controller on an application](https://developer.apple.com/videos/play/wwdc2021/10081) - and I believe it may be possible to do a similar thing on Android. Such solutions would provide a very specific, highly accessible, user controllable, developer customizable, virtual controller *with haptics* that could be provided by the Gamepad API or existing companion spec. 

That's an entirely different approach to achieving the "I need a gamepad with haptics" use case, without needing to expose `.vibrate()` everywhere in a manner that is so highly abusable (again, as evidenced by the 148 sites).

This is very much akin to vibration for notifications: they are offloaded to the OS, giving ultimate control to the end-users if they want to turn those off or not, without as much user annoyance. 

The approach of having a `.vibrate()` function accessible everywhere is problematic not just because it meets the use cases in an unsatisfactorily manner (e.g., no "rumble", just simple pulse)  - but also because one needs to consider all the misuse/abuse cases that it enables.

So again, the question of "what use cases does it enable?" must always be paired with "what abuse cases does it enable?" and does the API enable more abuse/misuse than the use cases. 

I hope by now it's pretty clear, by looking at the sites that are using the Vibration API, that: 

1. it's mostly used in an abusive manner
2. it doesn't meet the gamepad use case as well as maybe something like the Gamepad API could.

> To use the Gamepad API for this would be strange since a mobile device would only provide the haptic portion of the Gamepad API.

Would it though? I'm just trying to show that there are multiple ways of solving for these use cases - and that falling back to `.vibrate()` feels a bit short sighted: just because `.vibrate()` does handle a little bit of the use case (limited haptics), the consequences for the rest of the ecosystem are demonstrably detrimental (the high rate of misuse/abuse). 

Without getting into a discussion here, hopefully that shows that there might be different ways of approaching the gamepad-like haptics use case in a manner that is better for users and empowers developers to make great experience, while hopefully mitigating the abuse cases seen with the `.vibration()` API. 



-- 
GitHub Notification of comment by marcoscaceres
Please view or discuss this issue at https://github.com/w3c/vibration/issues/33#issuecomment-2161989561 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 June 2024 02:34:08 UTC