molly.com
Friday 3 November 2006
No More Next Page: Embracing the Non-Linear Web
For many years I’ve pointed out that the Web is essentially a non-linear environment. Yet, we insist on imposing linear processes and function on it. I’ve long felt this imposition has been far more limiting to innovative thinking than any other influence, including the cry for standards and best practices.
In workflow, linear patterns are not effective because web sites and web applications are inherently non-linear. Web sites and apps are also iterative, requiring cyclical attention for the entirety of their lifespan.
I compare the process of creating, and then maintaining a real-world, working web site or application to pregnancy: You’ve got the incubation period, where months go by in developing and perfecting the entity.
Then, there’s the birth, which is rarely peaceful and usually involves lots of screaming and crying followed by an exhaustion that seems to never leave. At this point, you can’t abandon the outcome. Our baby here, our web site or app, is going to require parenting for the rest of its days. It will have to be nurtured, guided, even corrected. Over and over and over again.
In design, linear patterns can only work for very specific pagination approaches. A good example would be paging through images on Flickr. Still, the mere existence of other pathways makes it nigh impossible to stay on a linear path on Flickr.
The Web’s non-linear environment calls us and it’s an opportunity to do better work. Which brings me to the inspiration for this little ditty, Pete Forde’s Endless Pageless: No More Next Page article and example, in which he shows a means of ending the “Next” phenomenon forever.
When I met Pete at The Ajax Experience last week, he (somewhat) jokingly said I’m sure we’ll argue on lots more stuff.
In theory, I have no arguments with innovation, and I am obviously attracted to script-based techniques of any kind that move us into the realm of more imaginative, less linear interface options.
The only dissent I have, and it’s an important concern, has to do with the fact that with JavaScript turned off, the technique is non-functional. Which brings us to another issue entirely: Unobtrusive scripting and accessibility. I, and so many users truly want useful features of this nature, but we have to think from the ground-up and be inclusive, providing some way to still offer practical if not elegant function for those without the scripting support.
Filed under: general
Posted by: Molly | 07:50 | Comments (37)
Comments (37)
Google’s RSS reader uses this technique to great effect. Some other concerns I have are bookmarking (both for my own use and for sharing with others) and using this technique with very large data sets (is your page eventually going to become too large, do you need to remove earlier content as you add content to the end?).
Molly I agree with your concern.
In life, I have learned the dangers of making assumptions and the kind of traps that they can lead you into.
In web development, I don’t think that we can really make assumptions about the users who access our sites and the kind of setup that they have (i.e. javascript or no javascript support.) At my old job, i discovered one day that my boss uses 800×600 resolution on his monitor and turns his font size way up. I never knew.
Especially with the World Wide Web really being world wide. You can’t assume that someone in a developing country and is accessing the web on their mobile phone is going to have great JavaScript and AJAX support.
I am not saying that we should stop innovation. We just need to be smart about it. The power of the web is that everyone can get access to it. (i think someone important said that.) 😉
I think this technique shows promise–it’s a good foundation for something more intuitive. I share the concerns of Patrick regarding large data sets and bookmarking. Also, I’m not sure that the browser scrollbar is the appropriate control to facilitate this. An interpolation of the data beside the scrollbar would be an improvement (based on how the set is sorted – date, name, etc), so the user would be free to skip to a specific point (much like page numbers in addition to prev/next links).
Perhaps the accessible version would have prev/next links replaced by the ajaxy-goodness onload?
When Pete came to me with this I had the exact same comment you did Molly. I love the concept, but didn’t like that it didn’t degrade gracefully. I think a simple script to remove the pagination links for non-JS (really non-Ajax, as you can have JS without Ajax, but not the other way around) browsers would be the icing on the cake.
I think it’s a nice, innovative approach to the boring old solutions, but I’m not sure the Web is quite ready for it just yet. Just as pagination has its own pitfalls, “infinite scrolling” has its own, too. The idea that page 4 may not contain the same results tomorrow is replaced by the problem of the item you were looking for now exists somewhere on one page, but not quite sure where because it hasn’t rendered yet – preventing a “find” on the page. Paging to me seems like a better reference than some distance down some unknown length of data, but I could just be tarnished from all of the pagination to which I’ve become accustomed.
I find it interesting that live.com promoted this approach for a long time and now they’re back to pagination like everybody else. I really, really wish I could find out why they decided to change to pagination after all of that effort.
I’d love to hear about anybody’s experience in usability testing this approach, or feedback from users of a production implementation.
The delay for new data often creates a cumbersome experience – not the quick, easy scrolling we’ve all become accustomed to with data which has already been downloaded on a page. Then if you have to remove content which has already been displayed to manage memory and performance, the user has to wait for it to appear again when scrolling back up. I left the Yahoo mail beta in favor of the old paging system for this reason. It was driving me crazy.
Anyway, I like the idea, I just think it has a lot of its own problems to overcome to get to a point where it’s significantly better than the well-known pagination.
Bookmarking is still important. And a decent functional page that has the information you want is still important… for those with JavaScript off, but still CSS is turned on. That may very well be a marginal percentage… CSS seems to most definitely be more widely supported over JavaScript.
All in all, people should never expect the same rich experience w/o JavaScript. They’re just asking for a lesser wow experience… they’re probably after your content anyway, so just give it to them.
This is quite an interesting idea. I’ve had a few people take a look at it and it seems to me that although it seems a little odd at first, seeing the scrollbar grow as you’re scrolling. I know I could get used to it.
The point raised here is accessibility. It can’t be too hard to make this (more) accessible. Add the usual page numbering bar in the bottom and have javascript remove it when it’s capable of performing these functions. Same for the category selection, this can easilly be done with checkboxes and have javascript replace them. This takes care of scripts unable to use javascript.
Another thing is search engine linking. They would crawl trough this page per page. Have javascript detect the page number and use ajax to add query results above it in the same way it’s down below. This would even add functionality since a search engine will point to the exact position of an item on a page.
Leaving the final problem; screen readers. Most users of screen readers have javascript on. Page changes will make screen readers restart at the top of the page. This could be solved by adding one of those ‘skip to content’ links like Molly has above here. But instead have it say something inthe lines of ‘Disable automatic page updates for screen readers.’
Really enjoyed this post Molly and alsso appreciated all of the excellent comments on the subject.
Got me to thinking… What should I do with all of this information relative to the website / blog / wike that is currently being developed for me?
I’m afraid I’m not terribly ennamored of this technique. It is interesting in its own right and as a developer I like that aspect of it. But as a user… not really.
I believe that having a large set of information items broken down in smaller chunks may be more natural than you think. Think of book pages. Even better, think of ancient scrolls, which used to slide the scroll from one stick to the other. The reader was able to decide how much he would see at once, but it would be a subset nevertheless.
It’s not really about bookmarking page 4. It’s about not being able to relate to the information if it’s too much or too small a chunk. If you’re given the entire set at once, you’re swamped. If you’re given too small a subset, you lose perspective. There’s a sweet spot that everyone decides for himself, but it’s there nevertheless.
Breaking stuff into chunks is here to stay, in one way or another. The only thing that’s worth advancing, IMHO, is letting the users adjust their various viewports easily. How many items on a page is one example. And if it was possible for me to grab the corner of this reply box and adjust it to my liking it would also be great. I say, let’s concentrate on viewport customization instead.
The only dissent I have, and it’s an important concern, has to do with the fact that with JavaScript turned off
That’s why AJAX is Old And Busted, HIJAX is New And Shiny! 🙂 …and on an entirely unrelated note, Jeremy has not influenced me at all.
Seriously though, the whole web2.0mfg phenomenon has encouraged a return to bad old habits – eg. script-reliant pages/apps (and poor browser support – hey if it works in Firefox, we’re done!). The permanent beta thing doesn’t help – it gives people an easy excuse, “we’ll fix it in another release, hey man it’s BETA!”. If it has tons of users and you’re charging for it, it’s not beta any more. Flickr I’m looking at you (and don’t give me that “gamma” crap).
Then AFAIK search bots still don’t use javascript; sites that need Google Juice™ need to degrade gracefully. If you’re selling stuff, surely you want to turn up in web searches?
Oh, and graceful degradation’s still the Right Thing to do. But as I regularly say, the moral highground doesn’t motivate action… so we won’t linger on the point 🙂
Returning to the point… the example page needs the search features right there on the results page, I don’t want to click “search again” every time. Plus it needs a method to deep link – eg. how do you email a particular item to your mum?
It’s an interesting approach but I’m not sure what sort of user groups would really like it. Probably tech-/search-savvy people would be ok with it, but average users might not follow it so well. Needs user testing, I guess.
I’m sorry, I’m definitely not into this technique. My problem has nothing to do with how it degrades without JS; I just think it’s a bad idea.
I immediately thought of something we deal with on blogs; posts that get to having a lot of comments (over 100 even) where it gets to the point that the page is so long that it’s hard to really go through those comments (and the page is so long that it’s almost unusable). Because of this problem, developers made plugins that allow you to paginate your comments, so if there are more than 20 or so they will be split across multiple pages. In this case and many others, pagination is used to provide a MORE usable solution.
Even if the data on a particular page changes when you come back in a week, that doesn’t change the fact that pagination solves a huge usability problem: that long pages of endless information present an overload of data to the user, and many users find it incredibly difficult to process all of it. Pagination isn’t the easy solution; the easy solution is to just put all the data on one page and give that to the user. Pagination is used because it is far more usable than having a long page of data. And it doesn’t just apply to webpages; we always take large processes and break them up into manageable chunks that we can handle in order to process the whole thing. Pagination is how we make large datasets manageable.
I know Google Reader is being “innovative” by using a similar technique, but to be honest, once I get more than 20 posts loaded in Google Reader, I don’t want to read them anymore. I think Google Reader would be much better off with pagination, and I would hate to see that convention be removed from other interfaces.
The simplest solution to make this technique degrade gracefully would be to add LINK REL=”next” and REL=”prev” as well as a couple of A elements pointing to the same URIs, wrapped up in NOSCRIPT. No sniffing or coding or anything required.
I wonder why NOSCRIPT is almost never thought of as a replacement technique for scripts. “Oh, you don’t have script support, eh? Then we have to jump through all these hoops, stand on one leg and spin around, making animal noises while we pull our fingers to make it work! Since our script is so advanced, we need to have a very advanced way to give you the alternative too, you see”. I just don’t get it. 🙂
what doesn`t mean non linear web?
Aza, from Humanized, here. We are the guys that implemented the Humanized Reader, which was Pete’s inspiration for his infinite history implementation. The idea of “Don’t force the user to ask for more content: just give it to them.” is powerful. But, as one of the commenters here pointed out, you don’t want to overload the user with more than they asked for. That is exactly what the pageless design patterns does.
Now, there are still some problems with our, and Pete’s, implementations–lack of good landmarks, lack of the ability to bookmark, and lack of good degradation without Javascript. However, these problems are all solvable (think location.replace). Although Humanized is currently working on getting our main product out the door, we are planning on returning to this design pattern to address all of these issues.
I am looking forward to seeing what others use the pageless design pattern for in the future!
whoa…..i am not sure if you guys get into the concept of “new interfaces” for large datasets, but here’s two clips from the guys at channel9, demo’ing some of the new interface controls, easily using WPF.
i don’t know about you – but these clips are 2 years old, and NOW – NOW we are entering a TRULY tag based, non-linear hierarchy – where URI OBJECTS have metadata, then u’d better have a chair nearby!
i call this….”what year is it”?
– here’s a real basic one, remember when flickr was just starting…awww
http://channel9.msdn.com/Showpost.aspx?postid=121804&pvrid=442
and maybe this one, semantically mapping the browswer output, umm, i mean…photo output to infinite elements along a 3d camera path:
http://channel9.msdn.com/Showpost.aspx?postid=62621&pvrid=6
and where were we now? a script that hands content to the bottom of a page – am i missing something philsophical here?
As for the “Pageless” aproach suggested in the article linked to, mainly for search engine results and the like, perhaps a simpler method than lots of JavaScript to determine the current scroll position would just be to have a “more results” link at the bottom of the current list, which dynamically adds another batch of results (what would traditionally be on the “next” page) to the bottom of the current page (using AJAX)
To account for situations when scripting isn’t available, well, in your plain HTML, have “page” links, but when scripting is available, have the script “hide/remove” these links and use the “dynamic add” method mentioned above.
The reason I suggest this is so that the user knows what’s happening, rather than the page seeming to get longer and longer, and never reaching the bottom (imagine them scrolling rapidly, or hitting the “End” kep repeatedly). Allowing the users to know where they are is one of the fundamentals of navigation.
Live Chat service for websites to increase sales performance and customer support response time. Real time visitor tracking and chatting. Detailed hits log analysis, number of visitors, search engine referrer, pages viewed etc
vbnc
jkhj
sss
1212
gffd
erred
fdde
qqsss
Cool