Sunday, March 3, 2013

Problems with auto-expand web views

In a previous post (Facebook footer links), I mentioned auto-append views: information views that automatically expand to display additional content when the user reaches the end of the currently-displayed content. More generally, views that append additional content to the content currently displayed, instead of splitting content into multiple pages, have become rather popular recently. (There are both manually-appending and automatically-appending versions of these.) Let us call these append views.
The button for appending additional content to a Yammer news feed.
I consider append views to have the following problems:

  • An append view gets bigger and more unwieldy as more content is appended to it. Getting around the content requires a lot of scrolling. (On the other hand, navigating multiple pages of content can be done using clicking. I'd need to do tests to see which method is more efficient.) Furthermore, bigger pages are harder for resource-limited browsers (such as smartphone browsers) to handle -- in my experience, they can slow such browsers down. Google Chrome on my iPhone has occasionally crashed while trying to display large append views.
  • Append views often break web history navigation. Since they tend to be presented on a single webpage using HTML5 techniques, instead of on multiple pages, append views possess a specific piece of state information: how much content is currently being displayed. This state information isn't stored as part of a browser's web history, which is why navigating back to one of these views usually requires the user to append the same content again.

    On the other hand, multiple pages of content are usually displayed as separate webpages, with separate URLs, so that the browser doesn't need to remember any additional state information in order to accurately return the user to the specific page he was at previously. (Note that I've seen multi-page displays implemented using HTML5 on a single webpage, in which the case the same issue might apply.)
  • Because append views are often presented on a single page, it usually isn't possible to provide a link to a specific portion of the content (such as the fifth page of content, for instance). (Note that this can also be a problem for multi-page displays, since their pages are often numbered from the most recent one, so that the page number for a given page of content could change, as could the set of items grouped together on a single page.)
What improvements would I make to append views? I'd find a way to make browsers remember how much content has been loaded into a particular append view, either through session variables or URLs. URLs would also be an easy way for users to create links to specific views of content.

No comments: