No More More Pages? Part 2

Our Products

I recently posted an article called “No More More Pages?“. It argued that the “more” pages used everywhere from Google to Slashdot are a possibly aging technology that might be given a face lift with the new tools available to Web 2.0. In short, it argued, “Don’t force the user to ask for more content: just give it to them“. A number of people wrote some thought provoking comments. This is a response.

First, Google is great. I’m not being facetious: at the very least, Google has transformed the way I search, the way I read email, and the way I look up geographic information online. The people at Google do a great job all while keeping the user experience first in their mind. I singled Google out because they’re a well-known company that often offers unique solutions to interface problems, but even Google uses page-chunking to present extended search results.

Many people have since pointed out that web searches are different than chronological RSS feeds. With information that falls onto a timeline, the benefits of the Humanized History over traditional methods are clear. Slashdot is a case-in-point: try to browse your way through the most recent week’s worth of Slashdot posts. Then try browsing the last week’s worth of posts on the Humanized Reader. You’ll notice how much easier it is right away.

As Alex pointed out, some web-based services already offer dynamically extending lists, such as the Google Reader. But with Google Reader, fetching older posts makes you think about getting more posts, whereas with Humanized Reader it just happens. You have to learn, explore, and figure out the Google Reader–not so with Humanized History, because scrolling down already has the semantic meaning of going back in time. You never have to ask Humanized Reader for more content–it just gives it to you.

But even with search results, I believe that Humanized History could make browsing a lot nicer. Search results have the same fundamental property of “navigating backwards through a sorted list, starting at the beginning”–only here the results are sorted by relevance, rather than chronologically. Finding a result that I clicked past just minutes before ought to be much easier with the Humanized History, because there is no notion of isolated pages to navigate: if the result I’m looking for exists, then it’s somewhere on the page, and I can just start at the top and scroll down or I can perform a text search using my browser’s “Find” command. Odds are, though, that we probably won’t resolve this argument by discussion; we’ll have to wait until someone builds it and gives it a try.

There are definitely some major unsolved problems with Humanized Reader. As Ted pointed out in the comments on the previous post, the Reader does not provide any mechanism for keeping track of interesting posts. A global search and a really long history doesn’t help you when the only thing you remember about the post you’re looking for is that (1) it was on Slashdot a couple weeks ago, and (2) you thought it looked cool. Perhaps what the Humanized Reader needs is some kind of favorites mechanism, like Gmail’s concept of starred items.

And then there’s the problem of landmarks. Many of the people who posted comments about page-chunking indicated that they use the page numbers on Google and other result lists as landmarks. Humanized Reader did have landmarks, in the form of “page breaks”–horizontal lines where the “more results” button would be on normal result lists. Some people who use Humanized Reader may have noticed that these page breaks have disappeared. That’s because after reading and rereading the many insightful comments, and trying it both ways, we’ve come to the conclusion that they don’t work very well.

People have a great ability to navigate by landmark. This can be used to great effect in the design of web pages and other browsing interfaces, such as zooming user interfaces. In order for a user to find content by browsing, the interface they are using should satisfy two criteria. Firstly, navigation should be as effortless as possible: you should be able to see where you want to go, and simply go there, without having to think about how. And secondly, there should be recognizable landmarks that tell the user where they are: you see a landmark, and you know where you are. We think that the Humanized Reader accomplishes the first with flying colors, but it doesn’t do so well on the second–as many of you pointed out.

So, the Humanized Reader needs landmarks of some sort. Exactly what those landmarks are, though, we’re still thinking about; suggestions, anyone?

Humanized Reader is in its beta infancy and we have quite a few more features to add before it lives up to the dream of “no more more pages.” But based on the feedback you’ve given us, our first priority is to get it to the point where the rest of you can set up your own accounts and use it as your own personal RSS aggregator. Don’t worry, Mike–we’ll let you in as soon as we can!

So please bear with us and keep posting the great comments.

First, allow me to say that I have not read a single book about interface, and hadn’t really thought about it until I started following this weblog. On the other hand, as a user of various products such as rss aggregators and gmail and spending way too much time navigating the the internet, there are definitely “yes” and “no” experiences.

The issue of landmarks is quite intriguing. I mean, landmarks work by association, right? So in a way, you give it meaning. For example, when I read to an interesting post in an environment where I have no way of actively placing a landmark (a star or a tag/label that I define), I would need to remember it be something nearby, simple, and convenient. The landmark helps me remember the location without actually having to remember the actual details of the post, so it should be a neutral mark that I can associate meaning to. On the other hand, it should also be able of acquiring meaning related to the post. I’m not being very clear here, so perhaps an example would help:
Remembering that this post is “next to the purple dot” would be confusing because this post has nothing to do with purple. On the other hand, if all the dates in May are purple and I remember that it’s “a purple date”, then it’d be associated with the post. Needless to say, having a purple penguin there would be worse than having a purple dot, because a penguin has its own meaning. Especially purple ones.

So whatever landmark you choose to put on the Reader would also influence how people associate your posts. If you make the date/month a more convenient landmark (by making it visually easier to associate), then I’d remember by chronology. If you make the poster (Aza, Atul, etc) more associative, then I would skim for entries by Aza. Sometimes I also skim for comment count, because that indirectly marks the post’s level of general interest.

Livejournal provides an interesting way of landmarking. The Livejournal “friends page” is basically a customizable prettified RSS aggregator where you can read on one page the latest posts from your friends’ livejournals, as well as communities and rss feeds. Different people associate posts differently, but I’m a very visual person, so I assign each person/type of feed a color. The Friends Page would show a vertical color-bar of my choosing next to posts. For example, comics are white, famous people are black, certain of my friends are green, others are different shades of blue, depending on how they are associated with each other and which color I associate with them. This way, the colors have meaning that is directly associated with the poster, and allows me to skim through my friends page looking for specific posts. If I’m in a hurry, I can tell myself to completely skip all the white ones. If Humanized were on my Friends Page, it would be the Humanized shade of green.

Of course, Livejournal provides lots of options for landmarks.
- There is the “memories” function, which is a small button next to each post that allows you to essentially bookmark the post in your personal nested memories folder. I have “memories” of all the college addresses that my friends have posted.
- tags allow you to tag your posts with general categories and terms, much like the labels on Gmail or the tags in many photo websites.
- Users have avatars (”userpics”) that come with every post. I’m color-based, so I don’t notice when people change their userpics, but others prefer to customize their Friends Page to emphasize the avatar.

Anyways, that’s just my feed-reading experience, if it’s any help to you.

Sushu is right on. I don’t use Livejournal, but I was thinking of that exact solution–colored bars associated with the date. I think it would be easiest to have one color (preferably no color, actually) be today, then (say) a light blue for yesterday’s posts, a light green, light red, then darker blue, darker green, and so on for each older day. Could be bars, or be the background for the whole chunk of text. Whatever is least annoying yet most informative.

Tags are extremely useful as well, and thankfully a lot of bloggers are starting to tag their posts for places like technorati.

This brings me to my main beef with the current Humanized reader: quantity. I have over 30 feeds and not a lot of time, so I tend to pick and choose what I’m going to read using the sidebar Bloglines provides. But this is where tags would come in. Users would group similar blogs together with a tag, then they could click on whatever tag they feel like seeing, and it’ll display the latest feeds from the blogs grouped into the tag.

Just my 2 cents. Are you guys coming out with anything else soon? You couldn’t have spent all that time on the reader… did you?

Don’t worry Cold Wolf, we have something much larger than the Humanized Reader in the works.

I think this post is moving towards a bit more productive discussion than No More More Pages? part one. It seems absolutely crucial to me to differentiate between browsing and referencing–a distinction not clearly made in the first post–whether it be in RSS feeds or search results.

It seems that the arguments put forth here in favor of the Humanized Reader apply largely to browsing, for which the reader suits me fine. I can endlessly sift through articles, never stopping to find that pesky “next” button; my focus is on the content the whole time. And this could carry over to Google results, I think, if I’m doing a search just to see what comes up. In that case this same mechanism would be great–I agree that the Humanized Reader is an improvement as far as browsing is concerned.

The problem is, I don’t only browse news articles or search results, sometimes I want to locate a particular one. And as soon as I know what I’m looking for–as soon as I’m attempting to reference information–the situation changes. In this arena, both traditional page-chunking and the Humanized History suffer, for reasons discussed in the later replies on the first No More More Pages? post. Google throws up hurdles in the forms of page navigation and meaningless indices, while the Humanized History currently lacks indices altogether and shifts the terrain under your feet (for those who haven’t read that post and the following discussion).

As somewhat of a side note, there’s an interesting middle-ground between browsing and referencing you bring up: jumping back to something you’ve already browsed past. You know it’s on the page, but not exactly where. While using the Find function will probably work for many, I feel I’m more visual: I know what I want when I see it, but would potentially be hard-pressed to come up with a good search term to relocate the item.

This brings up the idea of landmarks. While I guess any old landmark would be of some utility, I think what you really want when you’re trying to locate an item for reference is a heirarchy of some sort. Google provides you with a single-level heirarchy where the information has been divided fairly arbitrarily into 10 unit bunches with no guarantee that any bunch will have the same 10 units on two subsequent searches; the Humanized History on the other hand is akin to taking all of your reference files out of your filing cabinet, taping them end to end and hanging it on the wall. Neither is terribly useful.

Enter the ZUI! I think a good zooming interface is really the way to go about solving this problem: it provides a fairly natural method of navigation for heirarchical information, and you can get a picture of the overall “terrain” (which you can’t do with the reader now, making it fall short, in my opinion, of the first interface criteria you posit) and seemlessly move between browsing or referencing it. I would love to see the Humanized Reader integrated with a zooming interface, though from what I understand, the technical challenges are substantial.

There is a kind of zooming that is easy to implement. Initially you would see only headings. Zooming in, you would see details about articles (number of replies, etc), then the first few words of articles, etc.

As for finding things you’ve encountered before, Google History Search shows you your searches and the most recent access time for each. A more general solution is a good browsing history mechanism. One paper about this is http://www.w3.org/Conferences/WWW4/Papers2/270/ and TrailBlazer is apparently similar.

I use a primitive zooming interface when reading things like slashdot and blogs all the time. It’s called Text Size.
If there is something that has alot of comment or entries, I tend to use Ctrl+Mousewheel to make the text smaller so I can scan through until I find the title I want, and I can have a quick peek at the content. If it’s what I want, or it looks interesting, I can use Ctrl+Mousewheel to increase text size until it’s normal/larger (I actualy prefer reading huge text, even though I have good enough eyesight, it just makes things easier).
Unfortunatly the humanized website doesn’t allow for text size changed, and neither does the reader. The website, fair enough. The reader, it really should respect the users text size settings. If you could get the incrimental loading to work with changing text sizes I would most definately use it as my main rss reader.

It’s very nice to see you took my comments on board and the website now scales text.

I like your life-hack for doing primitive zooming. Quite clever!

In terms of text resizing, this appears to be a cross-browser problem. In Firefox, scaling text works just fun. But, as I recently discovered when investigating your comment, it does not work in IE. I wasn’t even aware that text resizing could have browser compatibility issues. Go figure.

It seems in older versions of IE you have to dissable it from using the defined font sizes by going to Internet Options->Accessability and checking one of the options there.
Fortunatly it works like Firefox in IE7.
Opera has the best zooming feature, in that it zoomes rather than scales text. This means the layout doesn’t get screwed about. Shame just about everything else with Operas interface is poor.

p.s. Love the live preview.

I’m a little worried with the idea of having the posts marked by *relative* time. Landmarks are to locate articles. Not only to locate them as you browse, but also to find an article you saw a week ago. They are useless if they change all the time. So, once the article is associated with any particular landmark, it should stay like this forever.

Another idea I’d like to throw here is how you look for old articles in newspapers or magizines — you usually look at photographs. They seem to be only visual sugar or distraction when you read the articles for the first time, but later on they become very good landmarks. The more variety in content, size, position, border, color, etc., the easier it is to remember such a landmark. Note that slashdot’s “category images” do not work this way — they are too repetitive.

Another, fancy, idea is to make some kind of pattern on the margin. It would be something decorative, maybe a floral pattern, or a geometric composition — but it wouldn’t be repetitive — it would consist of randomly generated parts for every new article. Of course, it’s not easy to come up with a good algorithm for generating such a thing…

I noticed tha you have added a “Humanized Favourites” section. Except it takes a little while to work this out. I did guess it pretty quickly, so the icon is fairly intuative. However, I had to look at the name of the icon (by viewing the URL) to check. I would recommend adding an ALT text to it, as my first instinct was to hover over the image to see what it meant.

I have an idea for landmarks. Mile markers like on the highway. 37 Signals does this in campfire. For them, 5 minutes is the mile marker and that’s when they drop a timestamp. For you it could be a numerical marker off to the side every 10 posts . 10 20 30 40 etc.

I really like how Microsoft did this on the live.com image search.

Slight correction. Live.com does this on all of their search results: web, news, and images.

Great ideas here, guys! I’ve created a Javascript library, somewhat in response to your concept here, that solves the problem of landmarks, at least for bounded datasets. There’s a demo available, with an overview of how it works and how to set it up. If you find it interesting, let me know what you think.

The humanized reader, and it’s loading the page longer and longer, is pretty nifty. I like that it loads the content without having to do anything, and it doesn’t take a huge amount of time to load the page. A question I have though is once I get all the way to the bottom, i’m gonna have a huge ass long page… navigating back up might be a pain?

Looks like an old discussion.. however, I’d like to post my comments and brainstorm a little.

Zoom vs TOC.

Makes sense as long as the landmarks are basically the same in all resolutions. Just make some of them disappear, and keep some important ones.

Now think of the real world - here we usually don’t have different zoom levels, but we see close things and faraway things at the same time. There is just one object and one distance we focus on, but we do still notice what’s happening around, in the near and far vicinity of that object - just with a lower level of detail. Unlike a computer screen, the human eye’s viewing area is a dynamical thing, and does not have hard limits.

When viewing physical objects, level of detail is usually no more than the optical zoom level. In a conversation, level of detail is controlled by the number of questions you ask. In text, level of detail is usually given by the hierarchy of headline and images, subtitle and highlighted quotes, abstract, full text. A more fluid hierarchy would be to continuously reveal more of the text. Newspapers use big captions, images and highlighted quotes in a way that the optical zoom will perfectly represent this information hierarchy.

In the pure optical sense, a floating level of detail could be accomplished with some kind of fish-eye zoom (one-dimensional), which would squeeze the loose-bounds human viewing area on a screen with sharp edges.

With more or bigger displays, ‘distant’ information could be displayed somewhere out of focus, so a fisheye zoom would no longer be necessary.

The more conservative way is a table of contents, which also gives a low-detail view of distant information. Usually, this would appear on the side of a webpage. Top and bottom is no option, as vertical jumps will kill your ‘train of thought’. We could use frames (if sticking to html), but noone likes that. Or a toc jumping around on the side, so it will always be visible.

What I would suggest is a repeated toc, that can at the same time serve as a visual landmark. This means, while scrolling down, we would repeatedly hit colored navigation bars. The layout of these toc bars would need to somehow mirror the visual landmark structure of the page itself.

Leaving html, I could also think of navigation bars on top and bottom of the screen (not the page). Items above/before the current scroll position would appear black on top, and greyed out on the bottom. Vice versa with items below/after the current position.

Landmarks

This seems to be the crucial issue. The key is to find the adequate level of diversity, without screwing up aesthetics, or bringing too much distraction. In that regard, the layout in humanized reader is FAR too uniform. Imagine your newspaper looked like that - which article would you start with? Newspapers are also a good reference to learn about the different types of landmarks - images, headlines, boxes and separations lines, formatting (font and colors) and text flow.

Now where can your reader take these landmarks from? I can imagine three different ways.

Content-related landmarks. Usually, all the feeds items have a link to a website. From there, you can get headlines, images, highlighted quotes, fonts and layout.

Meta landmarks. Time and date, world time (current place where the sun rises), night and day, the weather, color of the sky (sunshine, clouds, night..), room temperature (if you can figure out), important events in the year, appointments found in the calendar.

For instance, the local temperature and color of sky (taken from a web resource) could be used to paint the background a little. This does even scale well in the table of contents - there you would be able to spot summer and winter, and periods of different weather. One problem is the different frequency of rss items at different times - so a 1-to-1 time scale would be difficult, but definitely have its benefits. Leads to some interesting thoughts, btw…

User traces. How much time did you (or the idle machine) spend watching a part of the page? How did you wiggle your mouse in there? In which scroll positions did you make keystrokes?

By recording some of this data (attention, privacy!!), you could paint the background a little (with smudged mouse trails etc), and this way create some useful landmarks. Recent traces would get a different color than old ones. Again, this would scale well to the table of contents.

Could also be distracting, of course :)

What I’d like to avoid is asking the user to manually tick articles for later use.

OK, outside the box, plopping a weird idea on top of Andreas’s comments.

(BTW, I *LOOOVE* the live comment preview, at least for short comments. Damn, that’s humane!)

This might be a total no-go for Enso, but what about CAPS-LOCK + “mouse wiggle” meaning “Blotch the scrubbed region with highlighter and remember it as a bookmark, possibly while displaying marginal mile marker info (/entry #)”?

Downsides include: That’s a trifle inconvenient for me when I am mousing left-handed (pesky kbd has no CAPS LOCK on the RH side). And of course markup could be arbitrarily complex or impossible to implement across all pages; but inside your own reader, maybe not…?

For those interested, I just wrote a Flickr mod (using Greasemonkey) to implement endless scrolling in Flickr results.

It makes Flickr much friendlier and addictive in my opinion.

Try Flickr - Single Page Results.

Same thing for Google results.
Try Google - Single Page Results.

One afternoon, I was in the backyard hanging the laundry when an old, tired-looking dog wandered into the yard. I could tell from his collar and well-fed belly that he had a home. But when I walked into the house, he followed me, sauntered down the hall and fell asleep in a corner. An hour later, he went to the door, and I let him out. The next day he was back. He resumed his position in the hallway and slept for an hour.
This continued for several weeks. Curious, I pinned a note to his collar: “Every afternoon your dog comes to my house for a nap. ”
The next day he arrived with a different note pinned to his collar: “He lives in a home with ten children - he’s trying to catch up on his sleep.”

I cried from laughter
Sorry, if not left a message on Rules.