Avoid Scrolljacking and Smooth-scroll Effects for Better UX
Why web designers should avoid hijacking users scroll to make smooth-scrolling, parallax and other silly scroll-triggered effects.
By. Jacob
Edited: 2021-02-12 11:46
Smooth-scrolling is not bad in itself, but it is always bad when implemented on websites by web designers, because it hijacks the users scroll-controls. The reason is actually pretty straight forward; operating systems and browsers have settings to control how scrolling behaves that are typically native to the device, and for desktops, the behavior is pretty much universal to all apps. When a web designer decides to change the scroll-behavior on a website, there is a very high chance users will leave the site in frustration.
Users have memorized the way scrolling works on the device they are using, and intuitively expect it to behave consistently. If something disrupts this consistency, then the users attention is diverted, and this often causes frustration which will make users leave a website.
Most of the time web designers will not be aware of the all the controls used for scrolling and navigation, on all devices. On a desktop computer, this often means that keyboard navigation will be broken, and keys like home, page up and page down might get ignored. Designers should remember that all keys need to be remapped with event-listeners if you change a default behavior.
Problems caused by scrolljacking
It is also very difficult to implement an altered scroll behavior that will work well on different platforms, devices, and browsers — some problems caused by animations and scrolljacking is massive performance drag, lag, browser crashes, and CPU spikes on users devices. Even if you could get past all the difficulties, the damage caused to the user experience is just not worth it.
The problems with performance is worsened when designers add elements and CSS animations to a web pages on top of parallax, smooth-scrolling, and DOM manipulation with JavaScript. This will almost always lead to either of the following: CPU spikes, fans being noisy and running crazy, sluggishness, and lag while the animations are running. In some instances it might even crash the users browser.
CSS animations and DOM manipulation
You should also be very careful about adding animations to your pages, and probably keep your use of animations to a minimum.
Relying on hardware acceleration is not going to completely solve these problems, and sometimes it might even make it worse. The users hardware acceleration could be buggy, turned off in the browser, or it could be an experimental implementation, or users could have bad drivers. Etc.
If you do add animation effects, then you should consider limiting the use to short loading animations, and transition-effects on elements for states such as :hover, :active, and :focus.
When it comes to animation, tings you should be extra careful about would be .gif animations included on pages, infinitely looping CSS animations, auto-playing videos, and using videos as backgrounds; these tend to cause CPU spikes, sluggishness, and fan-noise.
This does not directly relate to hijacking users controls, but animations are often used in conjunction. A very common example of this is fixed headers on desktop that auto-hide when users scroll, since typically the header is moved in and out of the screen with an animation — on some websites this behaves very sluggish — besides, auto-hiding headers are really annoying to some users.
Are there any exceptions?
When it comes to scroll-jacking, I think there are very few cases where it makes sense to hijack users controls.
Perhaps if you have a photo gallery, and a user clicks on an image, you could open the image in a modal box, then place a couple of arrow buttons to show next and previous image, and re-map scrolling to navigate between images while the modal is open.
Note. A modal window is basically a HTML element that is absolutely positioned above other elements.
The point is, the exceptional cases where scrolljacking might add value are very few, and you should be extremely careful about trying to implement it elsewhere.
Of course, modal windows also come with their own usability problems. Often when a user clicks on an image in a photo gallery, they would much rather want the image itself to be opened in the same browser window. This exposes the browsers own native controls, and that often provides a much better user experience than what you can re-create in JavaScript.
Tell us what you think: