Hey - I just halved the scroll distance. Unfortunately, I didn't have anything to test on except a MacBook since I'm traveling. It sounds like the scroll ratio to movement was too small...perhaps now it's a bit more friendly.
This pretty much nails the obnoxiousness of parallax scrolling sites. It looks super cool from an aesthetic viewpoint, and these transitions are gorgeous, but as a user I just really fucking hate it. Parallax is the modern web's gaudy Flash interface.
You can do anything with a parallax scrolling intro! Anything at all - the only limit is yourself.
With a parallax scrolling site, you can to anything. The infinite is possible with parallax scrolling! The unattainable is unknown using parallax scrolling!
You made the fatal UI mistake --and by fatal I mean absolutely unusable for a great % of users-- of tying your viewport scroll to a fixed incremental +1 tick on the scroll wheel. If a user is using a MacBook touchpad, it's way, way, way faster than a user using a mouse or scroll-wheel, or any other custom scrolling device.
The key is to ALWAYS normalize your scroll, regardless of platform or device. Not only does it make your scroll values uniform, it provides a much smoother experience for the user.
The way this has been historically solved is to capture the mouse scroll tick, and then apply a multiplier on the expected result to induce easing, and then pipe that result into the scroll position of your container. All of this should take place within a requestAnimationFrame.
In JavaScript it's as simple as
position += (targetPosition – currentWindow.scrollTop) * easing // generally between 0 and 1
This classic inching equation is your friend!
If you were to revise your demo by implementing the above (about 5 minutes of work) it would look absolutely phenomenal.
I was totally confused by that spaceneedle site at first. Didn't realise I needed to scroll up. And once I figured it out it was very jerky. Chrome improved things a bit but it was still kind of frustrating to use. Nice when it worked though!
Hi there. I developed the demo and this is basically exactly what I do...the only difference is apply a multiplier to slow it down. I mentioned in the Medium post about this I am traveling and unfortunately didn't have access to anything but my MacBook Pro and my girlfriend's Air.
That said, seems like a common criticism is scroll speed is too slow, so by changing a couple small params, I halved all the scroll speeds.
I might totally be missing something, but seems like the concern is just relationship of scroll to movement of objects which I define in a big object. That said, I am no JS whiz and might be doing it all wrong.
Running your scroll within requestAnimationFrame isn't what makes the scrolling smooth, its the scroll multiplier which does it, making sure that deltas (or changes) in the y-position are normalized down into what will eventually be a zero, but over time. By constantly updating the future scroll position by running in through the equation and then applying it to your container whenever the user scrolls, you'll achieve a nice ease, which can then be dispatched to each of your parallax layers.
Here, I've just pushed an example to Github and Firebase. Feel free to check it out and let me know if you have any questions:
As a user on a MacBook Pro... it wasn't smooth. Inertial scrolling speedup causes problems, at multiple points I 'stopped' partway through animations.
It's a pain. Don't do this stuff, it just makes things worse. If you want to do this make them work like separate screens so that scrolling doesn't work, you can only click to navigate.
Computers have been training me on what a scrollbar does for 20+ years. DON'T try to change it now.
I think parallax done right would actually work on a mobile phone. Parallax effects make a lot of sense on a mobile phone that physically changes it's angle based on your motion. Not including mobile is wrong right out the gate, IMO.
Parallax... that word does not mean what you think it means.
These are just fancy scroll effects. Parallax would have been things in the background moving slower than things in the foreground. Your background is simply static.
I'm on a 1920x1200 display running chrome full screen, and it says "Whoops! Right now this demo doesn't handle resizing or browsers less than 1000px wide. Reload this page or get on a laptop!"
Wait, you mean there's more to that page than a single still image (with title overlay), and it was a broken flash/overly-fancy-javascript that it looked[1] like?
/me checks again after reading this thread.
WOW. That's horrific. Not only does it give ZERO indication that there is actually content there besides a background image/title.
The scrolling is not only bad per-click the z-axis mouse buttons, as cnp said. This same nonsense makes Page{Up,Down} only "scroll" (advance the animation) like an inch. In fact, the only way this even seems to approach "usable" is if you hold down the key for autorepeat, which gives it a constant "frame-rate".
This type of intro is yet another example of a style of design that really wishes the web/HTML wasn't a "document" with hierarchal markup, and try to force movie/tv style over how it is seen.
As others have said - should have just been if a flash intro/video instead.
From the end: "Really, anything is possible …"
Ok, I made the zombocom reference in a reply below before seeing that - now I almost wonder if this is some sort of waaaaaay-too-subtle parody or something?
[1] Extra broken, because the site detects browser width and overlays the ENTIRE PAGE with a black screen that says:
"Whoops! Right now this demo doesn't handle resizing or browsers less than 1000px wide. Reload this page or get on a laptop!"
So because a potential source of layout problems, such as my browser in a portrait-mode-like aspect ratio and too narrow for the background image, it's better to slam the door so the user sees nothing? How nice. If I'd seen the "broken" version, I might have had to drag my window a bit bigger. Or how about "background: center 100% no-repeat fixed url(...);"?
Hey - thanks for the feedback. For what it's worth, it's a demo. The entire point was a "quick" demo for the Medium post that I wrote about creating performant parallax sites: https://medium.com/@dhg/82ced812e61c
I totally understand the demo is limited in its implementation, but the point was never to be a perfectly polished site. It was to demonstrate the ability to achieve smoother animations tied to scroll.
That said, perhaps it was shortsighted of me to assume it wouldn't be judged on all platforms/devices/OS's.
In response to users calling this a Macbook-trackpad-only approach: this felt horrible on my MBA. I could only get through an animation in one go with a forceful swipe (the kind of maneuver I never use during casual browsing). Fellow designers, heed my plea: don't do this, ever. Having some subtle animations happen as I casually scroll is one thing, but this is a usability nightmare. I shudder to imagine what this experience must be like with a scroll wheel.
29 comments
[ 2.8 ms ] story [ 72.7 ms ] threadWith a parallax scrolling site, you can to anything. The infinite is possible with parallax scrolling! The unattainable is unknown using parallax scrolling!
You made the fatal UI mistake --and by fatal I mean absolutely unusable for a great % of users-- of tying your viewport scroll to a fixed incremental +1 tick on the scroll wheel. If a user is using a MacBook touchpad, it's way, way, way faster than a user using a mouse or scroll-wheel, or any other custom scrolling device.
Here's an example of a site doing it the right way: http://www.spaceneedle.com
The key is to ALWAYS normalize your scroll, regardless of platform or device. Not only does it make your scroll values uniform, it provides a much smoother experience for the user.
The way this has been historically solved is to capture the mouse scroll tick, and then apply a multiplier on the expected result to induce easing, and then pipe that result into the scroll position of your container. All of this should take place within a requestAnimationFrame.
In JavaScript it's as simple as
position += (targetPosition – currentWindow.scrollTop) * easing // generally between 0 and 1
This classic inching equation is your friend!
If you were to revise your demo by implementing the above (about 5 minutes of work) it would look absolutely phenomenal.
The cool thing about that space needle example was I could middle mouse button scroll with momentum too.
The middle mouse button does nothing on the posters example, so that's another feature to add.
That said, seems like a common criticism is scroll speed is too slow, so by changing a couple small params, I halved all the scroll speeds.
I might totally be missing something, but seems like the concern is just relationship of scroll to movement of objects which I define in a big object. That said, I am no JS whiz and might be doing it all wrong.
Here, I've just pushed an example to Github and Firebase. Feel free to check it out and let me know if you have any questions:
https://smoothscroll.firebaseapp.com/
https://github.com/damassi/smooth-scroll-example
It's a pain. Don't do this stuff, it just makes things worse. If you want to do this make them work like separate screens so that scrolling doesn't work, you can only click to navigate.
Computers have been training me on what a scrollbar does for 20+ years. DON'T try to change it now.
20 seconds of parallax = 20 parsecs
That's even more than the Kessel Run.
These are just fancy scroll effects. Parallax would have been things in the background moving slower than things in the foreground. Your background is simply static.
I don't think this counts as Done Right.
/me checks again after reading this thread.
WOW. That's horrific. Not only does it give ZERO indication that there is actually content there besides a background image/title.
The scrolling is not only bad per-click the z-axis mouse buttons, as cnp said. This same nonsense makes Page{Up,Down} only "scroll" (advance the animation) like an inch. In fact, the only way this even seems to approach "usable" is if you hold down the key for autorepeat, which gives it a constant "frame-rate".
This type of intro is yet another example of a style of design that really wishes the web/HTML wasn't a "document" with hierarchal markup, and try to force movie/tv style over how it is seen.
As others have said - should have just been if a flash intro/video instead.
From the end: "Really, anything is possible …"
Ok, I made the zombocom reference in a reply below before seeing that - now I almost wonder if this is some sort of waaaaaay-too-subtle parody or something?
[1] Extra broken, because the site detects browser width and overlays the ENTIRE PAGE with a black screen that says:
"Whoops! Right now this demo doesn't handle resizing or browsers less than 1000px wide. Reload this page or get on a laptop!"
So because a potential source of layout problems, such as my browser in a portrait-mode-like aspect ratio and too narrow for the background image, it's better to slam the door so the user sees nothing? How nice. If I'd seen the "broken" version, I might have had to drag my window a bit bigger. Or how about "background: center 100% no-repeat fixed url(...);"?
I totally understand the demo is limited in its implementation, but the point was never to be a perfectly polished site. It was to demonstrate the ability to achieve smoother animations tied to scroll.
That said, perhaps it was shortsighted of me to assume it wouldn't be judged on all platforms/devices/OS's.