← Tech Asteroid

Scrolljacking

November 20th, 2016 by Virtual-Machine

This post will serve as a warning to prospective designers and programmers that are thinking of using scroll-jacking inside their projects. If this post prevents even one website from using this technique, my words will have served a valuable service. The plain fact of the matter is, there is no functionality that you should need to implement that depends on overriding the default scrolling behaviour of the users' browser. At best, you will have spent significant time making a very good scrolling experience across all OSes and browsers. Considering most users are going to be accustomed to their native os/browser scrolling experience, more than likely your custom scrolling behaviour is going to be viewed as cumbersome and annoying. Your time is better spent elsewhere, and the user can trust that they will get the native experience while using your resource.

Without trying to sound like a fanboy, my absolute favourite experience about using an Apple computer is the native scrolling experience. I would gladly in a heartbeat transition to exclusively using Linux if I could get a scrolling experience even half as good as I get on my MacBook. I feel completely in control of each page and can minutely adjust each window with the very slightest flick of my fingers. 99% of the time, I can rely on this uniform experience across native applications. The lone exception to all this are the websites that have decided to commandeer control over the users' scrolling experience.

I have seen a few implementations including a few libraries that include scroll-jacking behaviour and I have yet to see an implementation that improves my user experience. In fact, the reason I am so aware of them is because in some manner I notice some degradation in my user experience as a result of this 'feature'. I think the real problem is that scrolling is actually a subtly complex feature to implement and has many subtle traits that each user would like to control for a personal scrolling experience. Simply based on that fact alone, it is a feature that is best controlled at the operating system level rather than the application level. A user can setup their scrolling experience system wide and then enjoy uniform control across all applications.

When my fingers move 2mm vertically down my trackpad, my mental mind already has a corresponding number of pixels that the screen is going to travel, in a given direction, at a given speed, acceleration/deceleration. When the screen performs this action in sync with my mental image, such as in a native application with default scrolling behaviour, the experience is actually quite unnoticeable. This is a desired trait, as scrolling actually becomes a very natural process that I am able to perform without much active thought. The issue lies in non-native scrolling implementations that are likely going to change some or all of the variables. This ultimately results in a different section of the screen being rendered than the user expected. This is extremely jarring to a user comfortable to the native experience.

The reality of the matter is that scroll-jacking could be forgiven if there was a necessary use for it. If there is a necessary use for it however, I am not aware of it. I have heard arguments that it may be necessary for mobile devices or some other special proprietary devices; fair enough but why does my macOS experience need to suffer to help mobile users? Furthermore, I think they are still putting the cart before the horse because the solution to the issue should come from the OS level rather than the application level anyways. In practically every case I think if you are looking to create custom scroll behaviour for your website/web application, you are taking a very anti-user approach to your ui development. Let the OS control the ui as much as possible, and use your valuable time elsewhere to benefit the user experience.