Bart 19 Jul 06

Microsofts www.live.com search-engine is using this technique also.

Des Traynor 19 Jul 06

Maybe I am missing something. Is this not exactly what the Live.com crew were banging on about when they talking about infinite scrolling?

Live.com has a shitload of problems technically, usability related and otherwise, but they have had this tech for a long time.

Dan Grossman 19 Jul 06

That’s a great idea.

Paul 19 Jul 06

Great idea agreed, but that scrollbar issue… man. And I’m assuming this is triggered by AJAX or similar (right?) so if I want result #89 of 90248, I’m going to have to rescroll to that exact point… versus saying that the result I want is on page 4. Not perfect yet.

Nick 19 Jul 06

Varma makes it seem as if the numerals have no meaning OR order (calling them random?), when, in fact, they represent several things to a user who’s looking for information located somewhere within several pages. Namely, the user is able to assess where within a time range he is reading, if the content is date based (“I remember this blog had a post on Farinelli around the time it first began, so it will be closer to page 10, rather than closer to page 1.”). Likewise, the user sees the numerals as a representation of the depth of search results and can fairly easily determine where to begin for “unpopular” or “more esoteric” results, if the content is weighted. It is this abstract quality that makes enumeration work; it actually requires very little thinking, neither about “what they are reading” nor about navigation.

Also his idea “there�s no telling what�s lurking behind a representing numeral�s bland exterior” is totally ridiculous when one considers that the infinite scrolling technique requires the message “More posts are being loaded…
If you are using the scroll bar, release the mouse to see more posts.” So you mean I have to sit here and wait and not know either 1) what’s next or 2) how much of what’s next there will we? I’ve gained nothing from this technique, compared to pagination. Seems much less semantic than an explicit list of 1…25 pages, each one immediately accessible and meaningful.

Andrew 19 Jul 06

I’m not convinced this is such a good idea, for a couple reasons:

1.) The idea behind pagination is to give people usable, discrete portions of text. It’s why we replaced scrolls many years ago in favor of the book.

2.) This is a case where technology is doing something that the user might not understand. They’re making an issue out of something that isn’t really an issue.

3.) I would imagine this breaks in-page search, so if I come to a page and search for a term with my browser, I wouldn’t get it, but I would scroll down and find it. Not good consistency.

4.) A much better semantic way of doing it is to somehow encode a dynamic “table of contents” in the site. This ToC could be built on the search terms the user uses, and would be always-present (I’m thinking a bit like the ToC in a PDF file, but built on-the-fly) This would allow discrete chunking of text, but also give the user the ability to navigate the content.

Jon 19 Jul 06

I’ve seen this never-ending scrollbar trick on a number of sites before and hate it.

One, the standard scrollbar is often replaced with an image-based scrollbar that isn’t as smooth, sometimes quite quirky (start dragging and the browser sometimes thinks you’re trying to drag and drop an image to your Desktop or something instead of moving the scrollbar image).

The worst part is what Paul mentioned above—you have to remember exactly what position in the scrollbar you saw a result you want to go back to.

And all this ignores the accessibility issue—the standard pagination system works everywhere even on mobile phones while this scrollbar technique requires a modern browser on the computer and a mouse (yes, there are people who browse with a keyboard-only).

Mr. Kahn 19 Jul 06

Clever. This is a nice tool to have and there are probably many situations in which it will be a marked improvement over pagination. It needs lots of improvements though.

And if you want a page footer your layout just got more complicated.

Also, there is no semantic meaning in the scrolling; there�s no telling what�s lurking as I scroll further down. If I find something good halfway down the page(whatever that means), I�ll be unlikely to find it again without aimlessly scrolling. Normally, if I don�t find what I want on the first scroll, I�ll usually just give up�

Jim 19 Jul 06

Excellent idea, but they still haven’t solved the problem of randomly searching for the previously found item.

After each search result block, there should be some sort of marker. A date, a time, or perhaps a color and letter like that found in many parking garages… but something!

Des Traynor 19 Jul 06

I agree its a problem to an extent, but to be fair if the search engine isn’t getting it within the first page or so, you’re probably search the wrong way.

Also, as for reference points, Google rankings change regularily enough, when you get past the top 10 or so for a relatively vague search term, so knowing that Basecamp is on page 7 in a google search for “really good project tools” isn’t really useful information, is it?

Tumble 19 Jul 06

(I’m turning this post into a chat room this morning.)

Did anybody notice that the new Yahoo portal has launched? I seem to remember that when it was in beta, they had adopted a 1000px wide layout, and now in final production it’s been trimmed to 760px. I was so happy to finally have one of the big dogs to point to and say ‘800px is over’, and *poof* they let me down.

Does anyone have any insight into why they narrowed the design?

D4V 19 Jul 06

I just checked, and it seems to be 1024 now… Um. Neat.

Rupert 19 Jul 06

I don’t think the problem is pagination per se, but to implement in a meaningful way. Sometimes an alphabetic pagination would be appropriate (A, B, C, …) sometimes customer or order numbers (0..100, 101..200, 201..300 …) etc. It’s about what to expect on a certain page.

BTW: Wouldn’t it be nice to have a ‘partial’ that you could tell the ‘key’ and the ‘grouping rules’ of and for a given collection, which would result in a pagination of your liking?

Tom Michlig 19 Jul 06

For those not reading feeds or other content chronologically, it seems like a “lesser of two evils” discussion. Out-of-context numbering systems vs scrolling endlessly down a bottomless pit of content. Both cause you to think about navigation, just the method of navigating is different.

The small victory here is that when scrolling, even if you are skipping over posts/sections, the content is passing by the reader on-screen, and could garner some attention. As opposed to numbering sytems which allow you to randomly click “5”, for instance, and not even see what’s lurking behind #’s 2 through 4.

In an ideal situation, your numeric menu is numbered according to relevance, so there is a little bit of context when choosing a number.

Kudos to Humanist for taking a shot at it. They don’t claim that it’s perfect, but small steps are what will get it there.

milan 19 Jul 06

Its a great idea that needs some help. The truth is that frustration sets in when you appear to be at the end of a page and can’t get there, which to be honest can be seen as more of an error than an actual functional element, however the idea of nixing the pagination is great, it just needs some more simple thought put into it such as adding a link that says “display more results” that will continue to keep a user on the same page and just load more of the results, thus giving some more control over where a user is on a page as well.

I think im gonna try and use this somewhere and (ab)use the hell out of it…

(m.)

David Benton 19 Jul 06

@Tumble: Thanks for pointing that out. It’s still wide (950px) on my computer (Firefox 1.5, 1280x1024). What’s your setup?

Ryan Allen 19 Jul 06

I think often pagination is overused. It’s perfectly legitimate to display, say 50 items instead of 5 pages of 10. We have scroll bars and scroll wheels, we’ll cope. If it were 1000 items, it’s a different story.

Probably the most annoying problem with pagination is how people make the page links so small. They’re used very often and they take up 0.2% of the space on your page, ridiculous!

Tumble 19 Jul 06

@David: how interesting, I’m FF on XP, and the new Yahoo page is 780px wide on my screen, as measured in Photoshop. I might just have to point Browsercam at it to see what happens. Interesting.

Des Traynor 19 Jul 06

Eh, what about just putting a damn number beside each link that appears.

i.e. I search for “Usability Reviews” I initially see

1. InfoDesign

2. InfoDesign

3. 37s br />
4.

5.

6.

… (then if you scroll down here, you’ll eventually see
7.

8. Usability Reviews Podcast

9.

And then I can just remember its number 8.

[How long it will be number 8 for I don’t know, I’m still not sure that its a good idea to remember a search engine ranking.]

To me remembering a search engine ranking for something as a reference point is kinda like remembering all the different places you had to look last time before you found your car keys. Well lets see, I first check my jeans, then my car, then the kitchen table, and finally, BAM there they are in my jacket

Why not just store the link properly the first time?

Mike 19 Jul 06

But how are the search engines going to constantly feed new ads? On google, every ten results that you scroll through, they feed you a new batch of ads. You can’t really do that on a continuous screen.

I would be surprised to see somebody like Microsoft, Yahoo, or Google roll something like that off of a little beta experiment. They would lose too much money.

Michal Migurski 19 Jul 06

Very anti-REST, this is. The biggest sin of AJAX for me is the way it’s often used to override system-level behaviors and conventional expectations, in this case the meaning of the scrollbar and the contents of the URL bar.

I can imagine preferring this to the old way, if I encountered it with little prior experience of scroll bars. It is definitely a very slick technique that may come in handy on pages that establish the expectation of frequent updates.

Bob 19 Jul 06

Seems more appropriate for something like a newsreader than a search results page—as Des alluded to, the pause at the bottom of the page can be a good thing that forces you to think about what you’re really searching for…

pwb 19 Jul 06

“You can�t really do that [feed new ads] on a continuous screen.”

Sure you can. Live.com does it.

I find it hard to get grounded in live.com. Is “looking at more search results” really the objective? I think not.

Also, thank goodness Yahoo is still under 1000 pixels wide. When will people learn that even as displays get massive, people do not want to view web pages that wide. Sheesh.

Mahjong Montr�al 19 Jul 06

(sorry, English is not my mother-tongue)

To me, infinite scrolling is the perfect example of yet another feature (gadget) that completely contradicts the “Less is better” philosophy. Yes, it’s (kind of) an innovative use of AJAX. Yes’ it’s fun to try it out. But does it simplify or eliminates the fundamental issue of finding what you are looking for? Absolutely not.

Lets imagine for one moment the perfect search result page. How many links should we have to click or how far should we have scroll down on a result page before finding what we are looking for? Zero! Ideally, only the few relevant results should appear, up front and explicitely.

Lets imagine for one moment the worst search result page. Surely, it would be an infinite scrolling page offering unsorted links to everything ever published on the Web.

Which of the numbered click-here-for-more pages or the infinite scrolling page drives us more toward the ideal situation and farther from the worst scenario? None. Both are bad, maybe even more so the infinite page scheme.

When solving a problem, one should always try to cure to cause not the symptoms. Here, the representation of output data is not what really matters. Garbage in, garbage out. We need better, more meaningfull, usable, input of requests.

David Mulder 19 Jul 06

I think this is very cool functionality.

To me, it sounds like the people who don’t like the idea of implementing “infinite scroll” on something like Google are so used to paginated search results that they cannot imagine anything different. However, when a superior system comes along, convention will and does change.

I like this thing a lot, and with the right care it can become incredibly useful.

CJF 19 Jul 06

I played around with the Humanized Reader for a little while, and I liked it. It did what I wanted, which was provide more content to read with useful summaries, with little to no cognative overhead. That break while you load a new page has often been enough to kill my interest in reading something online.

It does need to be rethought to work well for more cases than the browsing news case. If the background was shaded alternately in page sized chunks and given a page label, then you regain some of the benefits of pagination.

I agree with others on the scrollbar issue. It’s being abused here. The Google reader almost gets it right when it allows the mouse scroll wheel to page through entries in its own infinite navigator. The downside is it requires two actions, a scroll and a click on the right item (which I suppose is three, since you need to target as well) which takes your attention away from the real task at hand. If it loaded a new entry when I scrolled, I’d be much happier, because I wouldn’t be thinking about the interface, I’d be thinking about the news.

Julian 19 Jul 06

I think this infinite scroll thing is not for texts which you just want to split in pages and where you have to find something again later on. It is just for infinite amounts of things, i mean really endless.. it goes on and goes on. That’s not the case with normal articles and so.

John Zeratsky 19 Jul 06

Any navigational system for long lists needs to include two things: 1) landmarks and 2) a consistent positioning interface.

#1 is about remembering where something is and returning there. Like, “oh, I saw that result up there by the top of the page.” This matters whether pagination or scrolling is used.

But in order to navigate landmarks, you need #2: an interface for indicating position. Pagination does a decent job — even if the page “names” are not particularly meaningful, you can easily get a sense of where you are in the list. (E.g. page 1 of 1000 = lots more to go.)

Endless scrollbars totally screw up #2. It’s impossible to tell where you are in the context of the list, how long the list is, or how to get back to something in the list.

I’ll agree with many here who’ve said that this (the Humanized approach) is a great idea — but we still need to address some fundamental problems. That said, pagination is not the answer either. (Hopefully I don’t come off as defensive of pagination, because I am not a huge fan.)

Either way, there’s still room for an innovative solution to this classic problem.

Julian 19 Jul 06

John: Like I said, it is not for “long things”, it is for endless things.

Aza Raskin 19 Jul 06

Jon,

After we came up with Reader, we were forwarded to Microsoft’s live.com which implements a similar concept of infinite history. We found that their poor implementation got in the way of the concept for the reasons you mention. However, just because one implementation is poor does not mean that the concept is poor.

Live.com focused on solving the problem of how a scrollbar should behave in an infinite history environment. The result was painful. Humanized History makes use of the browser’s scrollbar, rather than re-implementing the wheel without improving it.

We’ve been using Reader for a while now, and we’ve found that most of the problems we and other’s anticipated weren’t really problems. Pontification is fine, but user testing is better. We are still working on the concept of visual landmarks to help mitigate the “lying scrollbar” problem that we are stuck with. We recently added large in-line dates to help you find your place. But it is worth pointing out that if you use the keyboard or scroll wheel to navigate (our preferred methods) you’ll almost never even notice the scrollbar jumping around.

John Beales 19 Jul 06

Julian: You are right.

Aza: If you can figure out a way to get around the “lying scrollbar” you will have gold. I usually use the keyboard or scroll wheel for navigation but there are times I want to jump a very long way quickly that I find the scrollbar better for. Also, my laptop doesn’t have a scroll wheel so there are a few extra times I end up using the scrollbar for it. Also, the non power-user crowd almost always uses the scrollbar in my experience. Continue the good work on getting around the “lying scrollbar.” I look am interested to see what else you come up with.

Joe 19 Jul 06

Big deal…people have been coping with turning pages for ages…

street 19 Jul 06

There�s no semantic meaning in these numbers

Since were having fun with language terminology in this post.. read up on ‘Pragmatics’.

Tom Michlig 19 Jul 06

To David Mulder’s comments: At least in my case, and many others’, it’s not a case of being so used to pagination that I’m resisting change. It’s realizing that infinite scroll isn’t “superior” (not without some serious work, at least) and not proclaiming to love it until it solves the problem more thoroughly. It solves many of pagination’s problems, but opens up it’s own set of problems along the way, which people have acutely pointed out here. Not to mention ease-of-use problems that have always been part and parcel to creating extremely long, vertical pages on the web.

So what we’re left with are two distinct schools of thought, each with strong points, each with inherent problems. But at least there are options.

To defend those who haven’t taken to the infinite scroll idea, they do have valid reasons.

People are Stupid 19 Jul 06

Why do you have a video of the site when you can just click on the link and go there yourself?

nate 19 Jul 06

Um, maybe this is cheating, but why not do both?

Why couldn’t there be a floating status widget in the corner of the screen giving you a relative idea of where you are?

You could designate that 10 items equals one page, (Page 5) or just show how many items from the top you are (#50).

And rather than page numbers, why not add a button to the widget that allows people to mark places on the page that they might want to jump back to? How’s that for semantic meaning?

And as far as the lying scrollbar, couldn’t we at least mitigate that by removing items off the top when adding them to the bottom?

Cliff Spence 19 Jul 06

I think the main problem with this method is that you’re taking away the some of user’s control of the page. Leaving a user feeling helpless in a navigational situation isn’t a good thing.

It also seems like it would be a bit disorienting for people who use the scroll bar as a reminder of where they are on a long page.

I agree with what Milan said above; instead of automatically adding to the page — clever, yes, but not very practical — why not give them a link at the bottom that will extend the page for them? This way you can still utilize a design with a footer and not confuse the user so much.

You might argue that if we use links to extend the page, then we’re right back where we started; pagination. Not really, because you still are only ‘paging’ in one direction. Going back is as easy as scrolling up.

J 19 Jul 06

Umm, how do I bookmark these “extra inline” pages?

nate 19 Jul 06

@J:

I’m not talking about a literal browser bookmark, although, I suppose, you could.

Unfortunately this medium of blog comments is woefully inadequate when it comes to sketching interfaces, so for now you’re just going to have to smile and nod.

pwb 19 Jul 06

To me, it sounds like the people who don�t like the idea of implementing �infinite scroll� on something like Google are so used to paginated search results that they cannot imagine anything different.

Or maybe they prefer that what they are looking for appear towards the very beginning of the results? What do you feel is better to optimize: ordering results such that the desired result is as high as possible or making the experience of scrolling down the list as good as possible?

asdf 19 Jul 06

Sorry, but sequential navigation, as slick and clever it is, doesn’t cut it with me.

…it is not for �long things�, it is for endless things.

Exactly. It’s perfect if you want to navigate about without a definite destination. Fine to make yourself acquainted, for instance, with the content of a blog. But, little of use if you search with a purpose or want direct access to content.

To me, it sounds like the people who don�t like the idea of implementing �infinite scroll� on something like Google are so used to paginated search results that they cannot imagine anything different.

To me, it sounds like the people who are ready to acclaim any new thing only because it departs from mainsteam interfaces tend to forget about basic Web content accessibility. Any navigation system should remain fully functional with JavaScript disabled or unavailable.

Andrew 19 Jul 06

What the hell? I just tried that thing on Microsoft Live. It was the most horrible scrolling interface I’ve ever used. There was no feedback that the page was loading more data, it simply locked up momentarily. Then suddenly the scrollbar jumped from under my mouse where I was trying to click it to its new updated position. Then when I clicked to scroll, it was smooth scrolling, causing me to have to wait still longer to see the next set of results. Horrible, horrible thing to use!

asdf 19 Jul 06

Live.com : One thing we learned from our research with users is that most people don�t click on the �next page� link. So, we got rid of it.

It could be argued differently. Most people don�t click on the �next page� link. So, Live.com implemented a client-side script to systematically fetch and display content most users dont care about!

Normally, if I don�t find what I want on the first page, I�ll usually just give up�

The problem is that every time a user is required to click to the next page, they are pulled from the world of content to the world of navigation: they are no longer thinking about what they are reading, but about about how to get more to read.

Normally, if I don�t find what I want on the first page, I don’t have any other choice than go back and refine my search, usually elsewhere. It’s too tedious to continue browsing, and lets face it, I’ve hardly ever found anything useful in the `next pages`.

The problem with the �infinite scroll� is that the user is lead to continue browsing inadequate results, instead of being offered alternative search queries or, even better, an immediate, easy way of clarifying his search needs.

They are no longer thinking about what they were looking for, but about how to stop this never-ending page to stretch with more irrelevant content. Because it breaks their train of thought and forces them to aimlessly wander in the wrong direction, it gives them the opportunity to leave the site. Many simply loose track of what they first wanted and click eventually on some random link. They become Internet zombies, only to wake up long time after they left your site.

asdf 19 Jul 06

Oops. In my previous post, this paragraph should also be in italic:

The problem is that every time a user is required to click to the next page, they are pulled from the world of content to the world of navigation: they are no longer thinking about what they are reading, but about about how to get more to read.

Alex 19 Jul 06

This is a ridiculous idea that breaks one of the most basic UI features of modern desktop applications. If you want to modify the way web browser interfaces work, work on web browsers.

Copongcopong 19 Jul 06

The “More” or “Next” link is the same as changing the page of a magazine or a book. Creating an “Ajax sort of scrolling more content” brings a lot of problems to solve, that programmers, developer and theorist loves. Keep things simple, no need to reinvent the scrolling experience.

When a user click on the “next” link, he/she needs that information, which is why they click it in the first place.

Just make it sure that page will load fast enough so that the information from the previous page they are reading is still in their thoughts.

For a list ( like Search Results), you can increase the number of results to 30 or 50. Improving the quality of search matches/results will also make it sure that the contents of your first 30 or 50 list is relevant to the searcher.

Kenny S. 20 Jul 06

This totally works well with a newsreader, I think — not search results. I love Humanize and 37signals are even cooler in my book now because they linked me to them.

Like everyone is saying, If you had some kind of indicator in a static location telling you that you are at results “50-100” and a quick way to sift back through the list, it’d be much more sane for going through 200,000 search results. (although, who ever looks past 20?)

While search isn’t a great example (thanks, Microsoft!) — de-paginating browsing through flickr might be a good test.

Say you knew there were 100 photos and you display 20 with each chunk. How about just making filler space for the other 80? Put in placeholder 1x1 pngs at the correct thumbnail height of all the images, then fill them in correctly as the user scrolls down.

Makes sense to me — anythink i might be missing?

Stephen Jennings 20 Jul 06

Would a real study of users find that they are confused by the idea of pages? Probably not, we’ve been using pages for hundreds of years. This model is neat from a research perspective, but I don’t think the “problem” it solves is as serious as it proclaims.

In search results, the pages do have semantic meaning: the first results are the most relevant to the query. If users don’t find what they’re looking for in the first page, they probably assume that their query was bad. This hinges upon the search algorithm being a good judge of what the user was looking for. This was the reason why Google took over Altavista’s market share: first-page results were more likely to be relevant. So, not traveling to a second page could very well be a good thing.

I believe image search is probably different. I know that I always use image search in a “clip art” kind of way: I know what I want the subject of the picture to be, but I don’t know what specific “looks” I have to choose from. So in this case, infinite scroll may be a good model because images on the first page are not necessarily less relevant than on the second page.

Mark 20 Jul 06

The removal of pagination would be a terrific improvement deployed in an environment with a comparatively low volume of results/records. For instance in an rss reader parsing feeds individually…or a database query results with a more limited number of records.

Jachin Sheehy 20 Jul 06

Mahjong Montr�al has hit upon something here… we are busy discussing the best way to resolve the symptoms rather than tackling the root problem.

The problem at hand is not pagination: it is the presentation of information in useable (and reuseable) fashion given the constraints of a human’s ability to transport or store said information, view it comfortably or process it in short-term memory.

It is reasonable to expect that the solution will differ for different types of information, and we see this already: chapters and page numbers for books, site maps for websites, etc.

Pages are great when:
- the information being broken up is more-or-less ‘linear’ and follows a coherent path
- the transition between pages does not unduely interrupt the processing of the information (compare the time taken to turning the page in a book to loading a new page of search results at a search engine)
- non-semantic symbols (e.g. page numbers) can aide in finding ones place to contine the ‘linear’ communication

Search results are typically a collection of options rather than a coherent ‘linear’ communication. As Mahjong Montr�al pointed out above, what is needed is the ability to increase the relevance and accuracy of search results, and thus reduce the result set to precisely and only those options that are relevant. This would eliminate the need for paging because it then becomes desirable to have this carefully selected group of options presented together.

Such a goal is beyond the scope of a user interface. What is required in the meantime is a way of allowing the search user to reduce the search results to a list of options that are relevant to him.

iht.com allows visitors to click an icon beside the headline of any story to add it to a personalised list of ‘Clippings’. This clippings list acts as a store of what is relevant to that visitor, who can then visit each ‘clipped’ story at leisure.

This would be ideal for search engine results: let the searcher pick which of the proffered results he is interested in further exploring. By ticking these off, create a list of options that is relevant and no one longer has to worry about page numbers, endless scrolling and relative positions to find any particular search result again.

A9 goes part way by saving searches and which results I clicked through on; but what is needed is to save the search along with the options that I would mark as be worth pursuing and then perhaps track if those options have been visited or not.

RSL 20 Jul 06

Maybe the reason people failed to use the “next page” button isn’t some irrational fear of navigation but a lack of engaging content. Piling more content on the reader’s page isn’t necessarily going to accomplish what could be done with better writing and better concepts. I myself often decline [after reading, okay… scanning an entire page’s worth of article] to continue reading on another page for this very reason.

Eric 20 Jul 06

Why isn’t it possible to have the best of both worlds? If you’re scrolling a long list of items, it can’t be that difficult to number them - viewing “item X of Y loaded” and letting the user arbitrarily jump to “item A”. So if they remember “Oh that thing was around position 90 or so”, make it easy for them to navigate back to.

I agree the scrollbar behavior of Humanized Reader is a little weird - but I’m not sure a dynamic page size is something we couldn’t get used to, assuming we know the number of items that have been loaded so far - it’s pretty intuitive to realize that item 50 is going to have a different relative position in a list of 100 vs. a list of 1000.

Donna T. 20 Jul 06

So, I can see the pros and cons of both approaches, but I would really like to see the numbers represent context instead of just a random number. For example, if you are looking at a list that is alphabetical, then the page links should represent the location in the alphabet (i.e. Be - Bu), or if it is chronological, it could represent the date range (i.e. 7/12/06 - 7/13/06). Adding rollover text to the numbers could provide this.

Likewise, using the scroll bar method, you could add a rollover to the slider on the scroll bar that indicates the context as you scroll through the list (similar to the way the scroll bar functions in Word).

I realize that this could be problematic to implement with large or dynamic data sets, but it sure would improve usability immensely.

Christian Romney 20 Jul 06

> This is a ridiculous idea that breaks one of the most basic
> UI features of modern desktop applications. If you want to
> modify the way web browser interfaces work, work on web
> browsers.

Why is it ok for scrolling to work like this if I release InifiniBrowser 1.0 beta but not if I build a web app for reading feeds?

And what’s up with the dogmatic pronouncements? ex:

Foo, you’re right.
Bar, you are mistaken.
Any interface must have A, B and C.

The one thing I’ve learned about HCI is that it’s not quite so easy to tell what’s right and wrong without real human testing and the results are often surprising.

Personally (and my opinion means squat), I dig the endless scroll. The whole point of the application is that it does the same old thing differently. I am not *expecting* it to work in the same way as every other website out there in all respects. The Humanized Reader is opinionated software. If you like it use it, if you don’t there’s bloglines, or Rojo, or Google, or … well, you get the picture.

Ara Pehlivanian 21 Jul 06

I think the point is being missed here. Search results or anything else that requires pagination is more often than not “transient” data. The same problem comes up with infinite scroll in that, I’ll have to scroll down a three mile long page every time I want to access that information and it may or may not be there… same as clicking “4” and hoping the result I found yesterday is still there. No, infinite scroll while catering to the lazy, won’t fix the problem of dealing with transient data.

One drawback with infinite scroll is the anxiety it causes (don’t laugh) in never knowing when you’ll reach the end of the search results. Nor do you know how much progress you’ve made in scrolling (thus not knowing how irrelevent the results you’re now viewing are vis-a-vis your query).

Oh, and what do you do for visitors who don’t have JavaScript support?

ben 21 Jul 06

I think this is a great mechanism because of one reason. It simplifies. Instead of having pagination and scrolling, you just have scrolling. I agree that if you need to jump around the results you can just use some more semantic way links. All the other issues that people pointed out can be solved in other ways, like having your current position in the results displayed either in the results or in some header for tracking where you are and tracking back. I think people will easily get the scrollbar updating position because it makes sense and its something scroll bars do anyway when they are loading a page. Plus I don’t think people use the scrollbar to track where they are. Just how much they have left to scroll.

Danno 22 Jul 06

Why not use some contextual information for the alt tag with the pagination.

Like, if the pagination is determined by time, you can list the start and end times of the page when you hover over the link.

Mi 23 Jul 06

Well - not JSPAN, but JSON :)