Vibration API: who needs it and why?
On February 10, the World Wide Web Consortium announced that the standard describing the vibration management API had been recommended. By itself, the ability to make the browser vibrate with the device has been available for some time, but only now it was finally framed with the recommended specification, so it's time to think about how and where it can be used on a daily basis. However, at the very beginning, the authors of the standard warn that the API is designed specifically for those cases when simple tactile feedback is required, and it is not intended to be used as a general mechanism for notifying the user. For notifications it is recommended to use Notifications API.
Those who wish to join the official specification with all its nuances can do it on the W3C website , and here we will only briefly look at how all this can be used, and also highlight some points that are not disclosed in the documentation.
Obviously, desktops, laptops, and even tablets just fly by, because they are not able to vibrate if they wish. And even if the system unit began to rumble and move around the room like a washing machine, users probably did not appreciate it, so it is hardly worth regretting it. Due to the existence of such device fragmentation, as well as the banal unpreparedness of a number of browsers, it makes sense to start by checking whether the vibration control is supported, and this is just not in the specification. However, it all comes down only to checking the presence of the navigator’s vibrate () method:
')
Directly vibration is set by passing navigator.vibrate its duration in milliseconds:
However, everything is not so boring, and there is an opportunity to transmit a whole array, the values of which will be a sequence of durations of vibration signals and pauses between them:
Here, the even elements of the array determine the duration of the vibration signals, and the odd ones determine the duration of the pauses between them (the counting of the elements of the array starts from zero, conventionally considered an even number). That is, the above code will cause the device to first vibrate a second, then wait half a second and then vibrate again a second. In two and a half seconds everything will end, that is, the process must be looped manually by means of a script.
The vibration process is not blocking, that is, the code will continue to be executed while the device is vibrating.
If you want to stop the vibration, you should pass the value 0:
Or if you like more:
Transferring a zero value immediately cancels all previously started vibrations.
In principle, this is all that can be said about the vibration management API on web pages. And now there is a proposal to brainstorm and think together about what all this can be used for. For a start, there are the following ideas:
And now honestly: who and with what hooked up the potential possibilities of the Vibration API?
Those who wish to join the official specification with all its nuances can do it on the W3C website , and here we will only briefly look at how all this can be used, and also highlight some points that are not disclosed in the documentation.
Obviously, desktops, laptops, and even tablets just fly by, because they are not able to vibrate if they wish. And even if the system unit began to rumble and move around the room like a washing machine, users probably did not appreciate it, so it is hardly worth regretting it. Due to the existence of such device fragmentation, as well as the banal unpreparedness of a number of browsers, it makes sense to start by checking whether the vibration control is supported, and this is just not in the specification. However, it all comes down only to checking the presence of the navigator’s vibrate () method:
if ("vibrate" in navigator) { // } ')
Directly vibration is set by passing navigator.vibrate its duration in milliseconds:
navigator.vibrate(1000); However, everything is not so boring, and there is an opportunity to transmit a whole array, the values of which will be a sequence of durations of vibration signals and pauses between them:
navigator.vibrate([1000, 500, 1000]); Here, the even elements of the array determine the duration of the vibration signals, and the odd ones determine the duration of the pauses between them (the counting of the elements of the array starts from zero, conventionally considered an even number). That is, the above code will cause the device to first vibrate a second, then wait half a second and then vibrate again a second. In two and a half seconds everything will end, that is, the process must be looped manually by means of a script.
The vibration process is not blocking, that is, the code will continue to be executed while the device is vibrating.
If you want to stop the vibration, you should pass the value 0:
navigator.vibrate(0); Or if you like more:
navigator.vibrate([]); Transferring a zero value immediately cancels all previously started vibrations.
In principle, this is all that can be said about the vibration management API on web pages. And now there is a proposal to brainstorm and think together about what all this can be used for. For a start, there are the following ideas:
- Using vibrations in web games, for example, device shake in racing or shots.
- Vibration alerts for important changes on the page, for example, when a new message appears in the web chat.
- Duplication of audio signals, if they are present in the interface, for example, to provide accessibility for users with limited hearing abilities (both physical impairments and simply disabled sound on the device).
- Simply adding cool ryushechek to the interface, for example, vibratory jolts when you press the buttons on the site.
- Annoying and frightening user spec. effects, for example, violent vibration of the device when the page is loaded, which will cause about the same negative as unexpectedly turning on music.
And now honestly: who and with what hooked up the potential possibilities of the Vibration API?
Source: https://habr.com/ru/post/250393/
All Articles