Sometimes having scrollbars on a web page is a good affordance. Scroll bars on a web log that’s a series of text areas makes a lot of sense — scrolling reflects both time and text. The app and the widget go together.
But for a lot of web apps scroll bars aren’t a great affordance, and they make the site harder to use rather than easier. These current gen apps let the app saturate the entire browser window but don’t overflow it:
Web page design usually starts by assuming a scroll bar. But that overlooks the problem of how users discover what’s accessible via the scroll bar.
On Myspace the most important navigation technique is to scroll the page until you stumble on what you’re looking for. Just keep going and eventually you’ll see that bit of text or widget somewhere in the thicket of bling. Hunt in the visible page, and if you don’t see what you want expose some more of the page.
A nav bar or some other explicit navigational aide would be a lot easier and more effective. To find the comments, have a link to them *above the fold* in the first screenful. Not just comments — anything that a user might look for needs a discoverable path above the fold.
And once you’re putting all those links above the fold, what exactly is the benefit of a scrolling page? Why not move that functionality — the comment widget, the player widget — to units that aren’t loaded until the user asks for them? The original page will be lighter and faster, and users won’t have the cognitive burden of divining what the scroll bar will allow them to access.
One kind of thing that a scroll bar is the right metaphor for: more of the same. When you have a table of names, and it starts “Alice”, “Bob”, “Carol”, and the next row is hidden offscreen, then a scroll bar is a natural way to navigate. You know what’s coming when you scroll down.
But a lot of the time a scroll bar is olden days thinking, just a habit from the days when web sites were static text by default. It’s paper-oriented thinking.