why are these sites so hostile to autoscroll and wheels?
Actually, this isn’t that bad, and it’s always interesting to see rethinks like this of old ideas. I’m not convinced that scrollbars are a problem that needs solving, but there’s no reason not to at least look at a thing like this.
If it winds up catching on, the gradient will almost certainly have to get much less obvious; it’s aesthetically pleasing, but that much screen space is just too much. No, my vision is not good enough to read the text behind it, so it effectively takes height away.
I also wonder how this interacts with sites that do the thing where their top navigation disappears or collapses, when the user scrolls down, and reappears on an upward scroll. It seems as though the “upward scrolling is possible” indicator would need to be displayed below the nav bar rather than at the top of the entire window… not the end of the world, and certainly a little experiment will make it look good.
There’s definitely a user education problem to make it clear to people that the gradient’s presence means scrolling is possible.
What I would really enjoy is a navigation widget for long reference documents with deeply-nested structure. Whether those are displayed all in one page, or in a long single-scroll, I’ve always found them rather irritating to use. I know that’s out of scope for this effort; I’m just wishing. :)
It seems like a nice idea but why does it have to replace scroll bars at all?
Why not have it in addition to scroll bars?
I suppose people have “gotten” that the UI can’t be added to forever without removing something. But this seems the mania for removal has gotten out of hand itself - I still miss my Firefox old status bar - especially when the new appears and blocks something I’ve trying to read.
So, from the ultra-negative angle:
The outline floating on the left, or some condensed version of the content, is mandatory but unmentioned. Skipping two-thirds of the way through a document is something that needs to be possible with a single UI action. Scrollbars, conveniently, combine this with the scrolling UI in a single compact element.
intence does not provide any controls for changing the scrolling position, and this was done intentionally. From now the issues of scrolling indication and scrolling control are separated: intence is responsible for indication and is supposed to work along with a navigation widget, like the menu on the left side. It can be a pager, or an area with small previews, a progress bar, or something totally new and different. Such components can be designed for the needs of a particular application and solve the issue of controlling the scrolling better than the general-purpose scrollbar.
In practice I imagine the result would be that some programs would have one of the 2 widgets, some programs would have the other, and some programs would have both, depending on the whims of the designer. Being general-purpose and standardized is a significant advantage.
The idea beyond intence is that it’s supposed to be a standard designation of a scrollable area, and a navigation widget may be different depending on the particular needs.
Well, I missed that paragraph when I skimmed through looking for it apparently. Oops. =) I don’t think it really impacts my point, though: a long-form navigation widget is mandatory, and a page without it is broken. Enabling broken pages is dubious design at best. Scrollbars nicely include the long-form navigation and thus sidestep the issue.
Funny bug. Clicking at the bottom of the navbar starts scrolling down (almost painfully slowly). If I click again at the top before it gets to the bottom, it keeps going down for a while before reversing directions and slowly scrolling up.
So two points. If I can race your UI animation without trying, it’s not fast enough. If I win the race and you don’t adjust, it’s not responsive enough.
nice that someone noticed it. the animation time is always the same (600 msec to get to the target, I think). The animation is a spline. When you change the target of a running animation, it calculates a new spline which has the same speed and acceleration at it’s starting point as the currently running animation.
Kudos to the author for experimenting–there is so much room for improvement in standard GUI stuff that it is really encouraging to see people playing with what’s possible.
That said, I don’t think this really succeeds as a better option than the scrollbar. Its only real advantage is indicating which part of the page will scroll (and to me, that is solving a problem that isn’t really a problem). The downside is that it takes much more space than a scrollbar (easily 10-20 times the screen real estate on my display) to convey less information (not only doesn’t it tell you as specifically how far along you are in the page, it doesn’t give you any indication as to the overall page length, which the scrollbar does very well). I also find the gradients pretty ugly, but perhaps that’s a matter of taste.
Why does my iPhone drop frames when scrolling?
What we really need is to go back to a percentage in the status bar like vim…