Animated scrolling is a simple interaction but can make all the difference for the user experience of a site. Fans of jQuery will tell you the easiest way to implement this feature is to wrap a .scrollTop() function with .animate() and call it a day. However, I have some issues with this method. For one, jQuery does not use requestAnimationFrame in its Animation class, using setInterval instead (as explained here). There is also the fact that most people don't update the URL to reflect this jump down/up the page, screwing up the progressive enhancement of the links to these areas on page. Having a focused, dependency-free module that facilitates this feature and enforces best practices should be a better solution. So that was my goal when planning out the creation of Elevatr.
The name was inspired by the glass elevator from Charlie and The Chocolate Factory—flexible, transparent, and fun to use. Flexible in the direction of scrolling, transparent in how the internals of the plugin works, and fun to use within the rest of the web building experience. The planning and design of a tool like this can be just as challenging as developing sites and apps used by consumers, it's simply a different type of consumer.
The flexibility of Elevatr comes from the options available when instantiating a new Elevatr object. Upon creation, the speed, easing, pushState toggle, and even a custom callback function can be passed in to suit the needs of the project. There is no need to specify the direction of scrolling because it is figured out by the plugin based on the position of the element of the trigger link and the element being scrolled to. This means multiple trigger links could be set without worry of where they are on the page.
I believe in transparency of code for the sake of upkeep in the development project, and it's also great for allowing others to understand what's happening under the hood if anything goes wrong. The naming of private and public methods and properties can go a long way in making the internals of a module as readable as possible. Then abstracting out too much within one method, to make sure it is easy to test every part of the plugin. Taking care of these issues up front will make it better for others to contribute to the codebase in the long run as well as maintaining it.
A plugin like this should be fun to use in the development of a site or app, not a chore. The developer shouldn't feel exhausted trying to read through documentation just to use the plugin for the first time. The API should enable the user to see a quick example or code snippet and understand exactly how to get the job done. While this can be done through great documentation as well, most developers wil want to just drop in the plugin code and get to work without doing a deep dive into someone else's code. I attempted to make this possible by only promoting one public method, Elevatr.setTrigger(), to use after instantiating a new Elevatr object. It is possible to use Elevatr.triggerJump as well, but it is only exposed for the sake of transparency.
Without further ado, this is the first iteration of Elevatr:
- add multiple choices for easing
- clean up some of the private methods a bit more
- create GitHub repo
- clean up the demo
- create landing page
- add tests
- add build system
- add option to integrate with Velocity.js for progressive enhancement and finer control over easing
- submit to Bower for easier distribution
That only includes what I can think of right now but I'm sure there will be user requests if anyone else decides to use it in their projects. I want to make it as easy as possible to contribute to the development of Elevatr and I've been thinking a lot about using CodePen as a tool in that process. For every iteration of Elevatr, I want to have an updated CodePen demo that others can fork and comment on, rather than having to fork a repo, clone it locally, run the build system, and finally view the demo page. The accessiblity of CodePen is absolutely brilliant for beginners and experts alike who just want to tinker with someone else's code ASAP.
Thanks for reading if you made it all the way through, and please comment on the demo or this post with any feedback. I'll probably update this article with links to the GitHub repo and new demos in the future.
Cracked a big bug in animation process by changing the scrolling function to use window.scrollTo instead of window.scrollBy which made using any easing besides linear a little nutty. So, with that change, I have added 4 easing options:
I have also added a build proccess to the open source project on GitHub using Gulp. More to come.