How To Scroll(bost.ocks.org)
bost.ocks.org
How To Scroll
http://bost.ocks.org/mike/scroll/
15 comments
> There should be a fairly straightforward Javascript workaround for this
There is. Sort of.
It's a javascript bookmarklet I named "FIXEDFIXER" that lives on my bookmark toolbar:
In my experience this little line of code fixes at least 90% of all my scrolling/coverup/screen estate problems. Sometimes the "position:fixed" element actually disappears, but I've been using this tool for over a year, and I have never had anything disappear that I actually wanted to see, read or use. (funny how that's a lot like the popup-windows on the web of old)
There is. Sort of.
It's a javascript bookmarklet I named "FIXEDFIXER" that lives on my bookmark toolbar:
javascript:(function()%20{%20var%20s,e,i,ee=document.getElementsByTagName('*');%20for(i=0;%20e=ee[i];%20i++)%20{%20s=getComputedStyle(e);%20if%20(s%20&&%20s.position%20==%20'fixed')%20e.style.position='static';%20}%20})();
In my experience this little line of code fixes at least 90% of all my scrolling/coverup/screen estate problems. Sometimes the "position:fixed" element actually disappears, but I've been using this tool for over a year, and I have never had anything disappear that I actually wanted to see, read or use. (funny how that's a lot like the popup-windows on the web of old)
Curious to see how this works out.
Let me know! I use and tested it for Firefox, but I guess it should work the same in Chrome. Also if there aren't any copy/paste errors from my bookmarks toolbars to the code here. I use it myself at least a couple times per day (otherwise I'd probably have my bookmarks toolbar hidden per default).
There should be a fairly straightforward Javascript workaround for this, intercepting the spacebar or pgdn keys to scroll the height of the unobstructed viewport instead of the full viewport, but I haven’t seen anyone implement it
I noticed a couple weeks ago that the New York Times website does this. Maybe not a coincidence that the article's author works there. :)
I noticed a couple weeks ago that the New York Times website does this. Maybe not a coincidence that the article's author works there. :)
Yeah, the space up up combo is common. As long as we're fixing the problem, I've only got one small pet peeve. It's when you hit the bottom, and scroll back up, but the page was like N+.4 viewports tall, so now I'm between pages, until I scroll all the way up to reset the view. I wish it would scroll up just .4 viewports initially, just lift it off the bottom first.
I don't know if this problem is worth solving, but I've thought about it.
I don't know if this problem is worth solving, but I've thought about it.
I have a more radical proposal, just hide all elements with position:fixed. I've never seen such elements contain anything useful anyway.
I've used a position:fixed form to create the input field for a downward-scrolling, bottom-affixed chat view (think Slack). I don't think they have any real use in web "documents", though.
This isn't even a problem though. Try pressing pgdn on any page with a fixed header. Modern browsers only scroll by 80% or so.
EDIT: why the downvotes? Try it yourself on http://legitmix.com
EDIT: why the downvotes? Try it yourself on http://legitmix.com
I've found the best way to avoid downvotes on HN is to pose your assertion as a question (as sincerely as possible) :)
"This isn't even a problem though." -> "Is this really a problem? I thought that... correct me if I'm wrong!"
Your karma will move in the positive direction almost every time.
"This isn't even a problem though." -> "Is this really a problem? I thought that... correct me if I'm wrong!"
Your karma will move in the positive direction almost every time.
Yeah, it's generally a good tip for interaction in general, where constantly making assertions comes across as argumentative and annoys people who realise that not everything they say is a fact.
Downvotes are likely because one's brain learns, "After you hit the space bar, look at the top of the text you were reading, except 15% lower. That's where the next line will be." Sites screw with this assumption and become very hard to read - even if the text is all visible after a scroll.
Browsers have scrolled less than 100% since forever, but there are differences. Most noticeably, Firefox scrolls (or used to scroll) more than Chromium, and has problems with content hiding more often.
Hear, hear! I've made this same complaint on this site many times, but less eloquently. I frequently use spacebar to scroll down one page. More and more I have to hit space, then up arrow a few times. :(
Space-scrolling doesn't work anyway, because when you're about to hit the bottom of the document, you don't know where to continue reading. If space-scrolling were smooth, this problem probably didn't exist. But still, in its current state, I'm not using it.
What site and what browser? My Chrome and Firefox understand position:fixed and it influences the amount the page is scrolled by.
Going back to my last complaint on this site: https://krrb.com/craigslist
Both IE and Chrome show the same behavior. My expectation on sites when I hit space or pagedown is to scroll down mostly one full page, leaving enough to get context of where I left off.This site scrolls past that point so I can't tell where I was.
Both IE and Chrome show the same behavior. My expectation on sites when I hit space or pagedown is to scroll down mostly one full page, leaving enough to get context of where I left off.This site scrolls past that point so I can't tell where I was.
Odd. I don't get the behaviour: http://imgur.com/a/zbZGE
Firefox on Linux
Firefox on Linux
What version of Chrome/IE are you using? I see the correct behavior on both (Chrome 38 / IE 11 on Win 8.1).
Interesting. Chrome 38, IE 11 here as well.
>Number five is the rule that’s being broken by an increasing percentage of the web without any custom scrolling at all: Every site with a sticky top bar breaks spacebar / pgdn scrolling by covering up the top few lines of text after a full-page scroll, requiring the user to back up a few lines to see what was hidden.
I just find out that medium.com does it the right way!
I just find out that medium.com does it the right way!
Even better would be a way to set a meta attribute that defines this (visible-width) or something like that, so that browsers could handle it. This would be easier for developers, avoid breaking things in JS, and could keep any browser animations that happen on scroll, etc.
I can't reproduce this problem on chrome or firefox. Pgdn/spacebar do not scroll the entire page - they leave some room, and the top bar doesn't cover up any content. Are you sure you aren't thinking of browsers from years ago?
Chrome, for example, works as you describe on Windows, but scrolls an entire page on a Mac.
This explains a lot. Thank you. Do you happen to know why there is a difference?
I often see this problem manifest when clicking links to sections in the same document, e.g. from a table of contents on a long single-page article or documentation page.
This essay is my attempt to synthesize a few general rules from recent work with custom scrolling. Scroll-based effects can be contentious, but I believe a lot of that comes violating reader’s expectations and breaking direct manipulation. There are ways to use scrolling effectively — to achieve the desired visual design without hurting usability.
Well-written and well-reasoned. Thank you.
I'd like to propose a sixth rule: don't move the goal posts. In other words, don't load additional content dynamically. This violates the user's expectation of when they will be finished scrolling. I find this frustrating, and I doubt I'm the only one.
Thoughts?
I'd like to propose a sixth rule: don't move the goal posts. In other words, don't load additional content dynamically. This violates the user's expectation of when they will be finished scrolling. I find this frustrating, and I doubt I'm the only one.
Thoughts?
I definitely agree with not moving the goal posts, I think this makes the scroll indicator useless since we make mental 'bookmarks' based on position. I believe a good compromise would be to keep the document height fixed and without loading everything. This wouldn't work for 'infinite scrolling' solutions, but scale-resetting could be minimized this way.
Consider adding: "If you think you need custom scrolling, think again."
Alternatively, replace the entire page with "Don't" in bold big letters.
I happen to like many of the New York Times articles that "mess" with your scrolling (that is, use the position changes to trigger events). To me, they somewhat resemble magazine articles with full page images in them, and I don't see a problem in there.
Have you thought about some kind of toggle for those of us for whom this scrolling junk irks? I've yet to see any site that actually uses it to present content that wouldn't have been fine without it.
Toggles aren’t a great solution; it’s a pain for you since you need to opt-in, and it’s a pain for the designer since they now have to create two different versions of the site.
I think either we figure out how to use scrolling effectively or we collectively realize it’s a mistake and abandon it as a fad. My personal belief is that we can make it work, and improve the visual presentation without harming usability, but perhaps there are a few more things to figure out.
I think either we figure out how to use scrolling effectively or we collectively realize it’s a mistake and abandon it as a fad. My personal belief is that we can make it work, and improve the visual presentation without harming usability, but perhaps there are a few more things to figure out.
Unfortunately, I don't care how much of a pain something is for the designer. Remember, the designer wants me on the page, not the other way around. And I'd rather be able to have a sane website experience rather then a crappy one. Most of the examples you had were absolutely horrible to deal with, even though I'm not on a weird platform. Win7 with latest Chrome, and the mac one won't let me get past the second tick thingy. IMHO, I wish this fascination with "Oh, let's screw with the user experience cause we want to be special" would just disappear.
I strongly disagree. I like the variety and the experiments. When you try new things, some will work out, some won't, and which do and don't vary depending on who you ask.
I'm still sympathetic. There are certainly UI experiences I can't stand. Pages that throw things in my face on hover are my biggest pet peeve. You jump to a page, your mouse happens to land on top of some random thing. You don't click, but it doesn't matter, because it throws a blanket over what you're trying to see because you hovered over something you didn't want to see, and now you have to figure out how to somehow get rid of it.
It's a revolting experience that I see everywhere, but I seem to be the only one who notices that trying to move my mouse to something I DO want to click ends up stepping on a hover-mine, which covers what I was trying to click..., so it's not like I can get anyone else to complain. I feel your pain (even though I LIKE some of these scroll effects.)
But if we were to tell designers to "stop screwing with the user experience", we'd just as likely have every page throwing random things in your face as part of the "standard hover UI" as get rid of it.
We're better off in the end with lots of experiments, seeing what new ideas seem to work, and adding support for those into the evolving Web platform.
I'm still sympathetic. There are certainly UI experiences I can't stand. Pages that throw things in my face on hover are my biggest pet peeve. You jump to a page, your mouse happens to land on top of some random thing. You don't click, but it doesn't matter, because it throws a blanket over what you're trying to see because you hovered over something you didn't want to see, and now you have to figure out how to somehow get rid of it.
It's a revolting experience that I see everywhere, but I seem to be the only one who notices that trying to move my mouse to something I DO want to click ends up stepping on a hover-mine, which covers what I was trying to click..., so it's not like I can get anyone else to complain. I feel your pain (even though I LIKE some of these scroll effects.)
But if we were to tell designers to "stop screwing with the user experience", we'd just as likely have every page throwing random things in your face as part of the "standard hover UI" as get rid of it.
We're better off in the end with lots of experiments, seeing what new ideas seem to work, and adding support for those into the evolving Web platform.
It's pretty easy to avoid all of this junk by disabling javascript. Nearly all news sites are easier to read without their intrusive CSS and scripting.
One thing I noticed is missing is supporting middle-click scrolling. I'm not a webdev, so I don't know how difficult it is. But that's pretty much the only way I scroll, so it's infuriating to run into shitty websites that break it.
If you follow rule 2 and adapt content to the viewport (rather than listening to wheel events directly), then middle-click scrolling should continue to work fine.
Are you doing any kind of throttling on the scroll events? When I was optimizing transitions based on scroll position, I found that pulling the scroll events off of a queue of size 1 was really effective in reducing dropped frames [1].
[1] https://github.com/circleci/frontend/blob/master/src-cljs/fr...
[1] https://github.com/circleci/frontend/blob/master/src-cljs/fr...
I love this. Thank you.
- Are there general principles you'd emphasize for mapping continuous control domains to discrete content ranges? (Like input rasterization.)
- If you could redesign the user control/input space (keyboards, mice, etc.), what might it look like?
- Are there general principles you'd emphasize for mapping continuous control domains to discrete content ranges? (Like input rasterization.)
- If you could redesign the user control/input space (keyboards, mice, etc.), what might it look like?
Thanks.
- Ideally, no mapping is necessary; controls should be naturally suited to their application. The problem here is that scrolling is designed for homogeneous content (such as a long column of static text), while web pages increasingly have heterogeneous media. Rather than try to rewire the controls, it’s easier to adapt the content so that it fits the controls we have. By limiting the visual changes and by retaining normal scrolling text, we are less likely to harm usability.
- I’d like to have access to touch events in desktop, for one, so that I could know whether the fingers are down (on track pads and magic mice, e.g.). And I always thought chording keyboards were a cool idea (particularly after observing court stenographers), but never seriously tried one. And maybe some standardization of swipe events on mobile.
- Ideally, no mapping is necessary; controls should be naturally suited to their application. The problem here is that scrolling is designed for homogeneous content (such as a long column of static text), while web pages increasingly have heterogeneous media. Rather than try to rewire the controls, it’s easier to adapt the content so that it fits the controls we have. By limiting the visual changes and by retaining normal scrolling text, we are less likely to harm usability.
- I’d like to have access to touch events in desktop, for one, so that I could know whether the fingers are down (on track pads and magic mice, e.g.). And I always thought chording keyboards were a cool idea (particularly after observing court stenographers), but never seriously tried one. And maybe some standardization of swipe events on mobile.
I think side notes are the single most underappreciated visual design element, and you make great use of them. I’m very much in favor of Ted Nelson’s idea that everything should have a content related, even editable/interactive sidebar.
I found this very interesting, but I was wondering if you have any data around these points? I'd love to see results of user testing or A/B testing, as right now I'm just surrounded by differing opinions.
thanks, really liked the summary. I also found the linked nytimes articles incredible!
Good god, how about "don't break anything!" Is that too much to ask for?
As in "don't break scrolling, don't break forward and back navigation, don't break link highlighting, don't break resizing (desktop and mobile), don't break clicking (I kid you not, some websites entice you to click and then can't be bothered to respond), don't break plain text."
I agree with everything in this article, but it should be common sense for a designer/developer/writer. Stop breaking the Internet. Serve up data, not apps, give me some viewing hints if you must, but let me or my browser settings control my viewing experience.
I suppose plain data doesn't make money, which is why all the apps/JS and interaction got added to the page to hijack our attention which could be then monetized.
As in "don't break scrolling, don't break forward and back navigation, don't break link highlighting, don't break resizing (desktop and mobile), don't break clicking (I kid you not, some websites entice you to click and then can't be bothered to respond), don't break plain text."
I agree with everything in this article, but it should be common sense for a designer/developer/writer. Stop breaking the Internet. Serve up data, not apps, give me some viewing hints if you must, but let me or my browser settings control my viewing experience.
I suppose plain data doesn't make money, which is why all the apps/JS and interaction got added to the page to hijack our attention which could be then monetized.
Also, if I select a piece of text to copy, don't unselect and show a damn popup with "share on facebook/twitter" when I right click!
In my opinion if you have a site that mainly consits of text (e.g. News sites, blogs) you should never interfere with scrolling behaviour. Lazy loading content is ok, but please keep dynamic stuff to a minimum.
Because I'm traveling I'm using a cheap 70$ Android. So the phone isnt very fast and the internet connections slow. This makes a good number of "modern", especally SPA news sites completely unusable. Scrolling callbacks constantly freezing the whole interface. It's not per se the fault of using too much javascript – gmail and facebook work pretty well. But if you dont have ressources to optimize your sites fancy js magic please consider not doing it at all.
I dont expect much of my cheap phone. But reading plain text is definitely something i do.
Because I'm traveling I'm using a cheap 70$ Android. So the phone isnt very fast and the internet connections slow. This makes a good number of "modern", especally SPA news sites completely unusable. Scrolling callbacks constantly freezing the whole interface. It's not per se the fault of using too much javascript – gmail and facebook work pretty well. But if you dont have ressources to optimize your sites fancy js magic please consider not doing it at all.
I dont expect much of my cheap phone. But reading plain text is definitely something i do.
I just gave up trying to read a newsweek mobile form article because of this (site kept resetting the scrollpoint to the top of page). If I can't read a text article on my $500 pocket super computer, I'm beyond annoyed.
And I agree, even if your scroll .js works perfectly, the callbacks leave a perceptible pause on most phones.
And I agree, even if your scroll .js works perfectly, the callbacks leave a perceptible pause on most phones.
Even on a high-end phone all that fancy js uses a lot of battery. Some "mobile" sites cause my phone to get warm. I don't like visiting them because it's like I can feel my battery draining.
To be honest, hijacking scrolling takes me to about the 90% "I'm ready to leave this site" frustration level. I've learned to live with it for a few sites, but if you don't get my attention is about 10 seconds, I'm gone.
Shift-space scrolls up a page. Thank you!
I come from Unix, I'd have expected b or backspace to scroll up a page, been disappointed by browsers numerous times, and just lived without it.
I come from Unix, I'd have expected b or backspace to scroll up a page, been disappointed by browsers numerous times, and just lived without it.
I use Firefox, where / is 'search in page' just like unix tools. I flop around like a dying fish when I have to use Chrome, where you have to use the gasp chorded keys ctrl+f.
A lifelong unixy sysadmin friend of mine particularly hates browsers and ctrl-w. To him, 'ctrl-w' means 'clear text field', particularly useful for things like password prompts where you can't see what's been written. So he goes to clear a password field in a browser window... and the webpage disappears
A lifelong unixy sysadmin friend of mine particularly hates browsers and ctrl-w. To him, 'ctrl-w' means 'clear text field', particularly useful for things like password prompts where you can't see what's been written. So he goes to clear a password field in a browser window... and the webpage disappears
Pentadactyl is your friend, friend
http://5digits.org/pentadactyl/
http://5digits.org/pentadactyl/
I never really looked at it - I guess it's time to finally try it. Thanks.
This is a common (and brilliant) pattern on Mac's. Once you learn the keyboard shortcut for an action, you've immediately learned how to do the opposite action, eg.
Undo: Cmd-Z Redo: Cmd-Shift-Z.
Undo: Cmd-Z Redo: Cmd-Shift-Z.
My mind boggles. This is like a relative of mine, who has used desktop computers for decades, and recently revealed an ignorance of ctrl-c, ctrl-v. I think I actually cried a little bit for her.
I too am stunned that someone has used their computer for many years without ever having to send SIGINT, but perhaps she only uses very well behaved applications?
It's not often however you have to send raw characters. Several of my coworkers didn't even know what that particular control sequence did when I quizzed them, so that doesn't surprise me at all.
It's not often however you have to send raw characters. Several of my coworkers didn't even know what that particular control sequence did when I quizzed them, so that doesn't surprise me at all.
Well, I don't know. Control+V is pretty important for paging through content. Even people who don't use raw characters have to be able to scroll (which just happens to be what this article is about…)
Haha, well done. Yes I would have had to look that up.
OMG this works in Chrome.
#3 is the biggest offender for me.
The feeling of "well, I'm scrolling, but nothing's happening. Am I doing something wrong...oh there it is" can really throw off an otherwise positive content experience.
The feeling of "well, I'm scrolling, but nothing's happening. Am I doing something wrong...oh there it is" can really throw off an otherwise positive content experience.
Yeah... sometimes I'm scrolling and there's some sort of effect on the page that some design nerd spent a couple work-weeks on, but it may not always be readily apparent. If I do what I'm apt to do when scrolling doesn't work, aka click on the scrollbar to jump ahead, then it breaks the entire presentation. Having to scroll forever to get at the content I'm looking for is incredibly annoying.
Using scroll-driven websites on a Mac with its gesture-based trackpad scrolling is often a beautiful experience, and it's usually also delightful on an iPad. Sometimes it even translates well to mice with scrollwheels. Using the same site on a windows laptop with weak trackpad gestures, where you instead rely on arrow keys, or awkward middle-button-synthesis for scroll, it's all too often completely frustrating. Even this piece seems to regard users using anything other than an apple trackpad or a scrollwheel mouse as a secondary concern.
Position:fixed isn't a panacea either, I've seen it horribly overused as well. Lately I've seen a lot of UIs recreating the worst mistakes of the era in the late '90s when everyone discovered frames. I've seen some cases where sites are so broken that they have maybe one line of text of scrollable content on mobile devices because of all the dumb mostly useless fixed content on every page (ads on the bottom, headers on the top).
Yes, but you have to have the "share on X" buttons follow you through the whole document. You never know when the moment is lost!!!
This is great, and perfectly encapsulates all the irksome interactions and usability problems with scroll hijacking that has taken over the web in the last couple of years. I hope this article travels wide and forces a rethink of some of the strategies.
He proposes event based and scroll based interfaces. The Mac Pro example is hideous, but Apple's retina iMac page is quite beautiful (and lives somewhere between the two, not using gestures but giving the user the impression that no scrolling is happening) http://www.apple.com/imac-with-retina/
I'll add:
Don't break accessibility. Hijacking scrolling can easily confuse screenreaders, spiders, old browsers, etc. Especially when you start doing tricks with hiding content in weird ways, etc, etc.
Don't break accessibility. Hijacking scrolling can easily confuse screenreaders, spiders, old browsers, etc. Especially when you start doing tricks with hiding content in weird ways, etc, etc.
Larger jumps in page-scroll-position could possibly be less distracting on our vision systems. I just don't want to be unsure about what will happen when I trigger the scrolling behavior.
It makes me sad that very little applications support scrolling by clicking the mmb/scrollwheel then dragging the mouse, this is my preferred method of scrolling.
I liked that too, but for some reason my KDE + Firefox didn't support it out of the box.
Real men scroll only with space bar (and shift + space) :)
There should be a fairly straightforward Javascript workaround for this, intercepting the spacebar or pgdn keys to scroll the height of the unobstructed viewport instead of the full viewport, but I haven’t seen anyone implement it (I’ve been considering creating my own open-source library for it but I have no experience managing an OSS project).
Still, I wouldn’t consider that ideal, and maybe it’s time for some standards action. Here’s my proposal: