The primary balance you have to be especially careful of when using a technique like scroll points is a balance of control. You don't want to unnecessarily take away or curb a user's control if you can help it because they are used to navigating in a particular way.
(The slides linked throughout this post are from my talk on meaningful animations)
A lot of the current methods developers use to limit and structure our users’ movements on a page are all too often needless, heavy-handed, unsympathetic, and frustrating. CSS scroll snap points seeks to in part fix this by providing a good, native implementation to aid our users’ scrolling traversals.
Recently, several main vendors rolled out support for CSS Snap Points, and as a browser-implemented standard, it provides a more accessible, minimally intrusive alternative to help users effectively navigate certain types of pages. Informative articles have already been written on how to implement CSS snapping scroll, but since it can be either immensely helpful or spectacularly abused, it’s at least as important to know when and where to use snapping scroll appropriately.
1. When possible, avoid snap points altogether.
Snapping to locations on a page is by nature a restrictive behavior. Restrict users' abilities only when it is clearly beneficial to them.
This is especially true for non-mobile views. On large screens there are very few use cases for this type of behavior. Never default to designing with it. Remember: you must offer a significant value to the user in return for taking their control.
2. Prioritize visual content, not text.
The best slideshows use very little text to convey their points; exceptional visual content is the focus, and the principle. When using snap points, limit the text to something brief but powerful.
Some particularly good examples of this are the "vision" page of Wrk, the animation-filled "about us" page by Code & Theory and Vito Salvatore's case study navigation.
3. If you need to show more content, combine snap points with other methods of navigation.
Hopefully you noted that neither site linked in the section above uses exclusively scroll snapping behavior — they change dependent on the type of content they are showing. Both go to the regular default scrolling behavior when showing more content like articles or giving more description of the work they create.
The web is more dynamic and capable than one navigation behavior. Snapping has its use cases but is not great for every type of content.
Here are some particularly good use cases which comply with the guidelines above:
- Slide shows: This functionality essentially turns a part of a web page into a slide, so it's perfect for slide shows. A great example is the Code & Theory site linked above.
- Page transitions: I can imagine sites using snap functionality to transition between pages like Rally Interactive does horizontally, while maintaining regular scrolling on the pages’ primary content. Paired with pre-fetched content and dynamic URL routing, this could be a viable part of creating a website or application that transitions well between posts. Paired with lovely transitions like the Wrk page, it makes the experience even better.
- Grid navigation on mobile devices: If you happen to have a large grid that users can navigate similarly to Webkit's demo (your browser needs to support it) showing use cases of snap points, then CSS snap points is a great fit. Similarly, a spreadsheet table may also be able to use snap points appropriately. Keep in mind that scroll snap navigation without other context should only rarely be used. Even for image galleries, there are often more intuitive and effective methods of showing and navigating content.
The development of the CSS Snap Points standard is exciting! With good implementations from vendors, we can expect to see more sites make use of the technique to help improve their user experience by helping precise navigation be a little easier. Admittedly, it’s just a small enhancement of our arsenal, but one that deserves its place in the right circumstances. As designers, we need to be careful not to fall into the assumption that everyone else experiences the web exactly the way we do.