- Faruk Ateş
- Andy Clarke
- Kris Hadlock
Robert Hoekman, Jr.
- Designing the Obvious Clinic: Google Docs & Spreadsheets
- Designing the Obvious Clinic: CraigsList
- Designing the Obvious Clinic: SlideShare.net
- Designing the Obvious Clinic: RSS
- Designing the Obvious Clinic: Tumblr
- Designing the Obvious Clinic: Going Social with Ning
- Redefining User-Centered Design, Part 1
- Redefining User-Centered Design, Part 2
- Redefining User-Centered Design, Part 3
- Molly Holzschlag
- Sarah Horton
- Miraz Jordan
- Jonathan and Lisa Price
- Catherine Seda
- Dave Shea
- Dave Taylor
Table of Contents
- Web Basics
- Publishing on the Web: Putting Files on the Server
- Web Design Process and Workflow
- Project Management
- Mark My WWWord: HTML and XHTML
- Standards Compliance
- Meta Tags and Search
- Enhancing Web Page Interaction
- Web Graphics
- Web Page Optimization
- Overview of Servers
- Server Programming Basics
- Careers in Web Design
- Intellectual Property for Web Designers
Designing the Obvious Clinic: RSS
Last updated Oct 17, 2003.
By Robert Hoekman, Jr.
About Designing the Obvious Clinics
The goal of each Designing the Obvious clinic is to see how a particular web application measures up to the principles discussed in my book, Designing the Obvious: A Common Sense Approach to Web Application Design. To learn more about Designing the Obvious, visit my Web site.
What The Heck Is Wrong With RSS?
In this Designing the Obvious Clinic, I'm going to switch gears a little bit. Instead of focusing on a particular web application, I'm going to discuss a whole technology: Really Simple Syndication, otherwise known as RSS.
With the web becoming more and more of a platform for software services, it's time to start looking at how these experiences, which do not rely on a traditional person-to-computer interface, are designed. This is a tricky area, because a good design for RSS is not something a single site can employ to solve the entire problem, it's something every site needs to employ. With that in mind, today we'll take a look at the best and worst ways the subscription process is handled, and see how they contribute to an obvious design standard.
The value proposition of RSS is genius. It eliminates the need to manually check each and every blog, news site, and project management tool all the time. Instead, you simply subscribe to the feeds and check them all in one place. But there is no standard way to implement a subscription process, so every team that integrates RSS into their applications struggles with the same issues. As a result, implementations vary wildly, making the whole technology relatively unapproachable to mainstream web users. Despite this, RSS feeds continue to pop up everywhere from eCommerce sites to forums. People outside the web software industry, who should never be forced to understand XML or RSS aggregators, let alone all the different versions of feed technologies out there, are constantly exposed to the clunky task flows and ugly experiences of subscribing to RSS feeds.
What can we do about this? We can start learning from those who design the obvious.
To do this, we'll take a look at a few of the principles covered in my book. Namely, we'll look at how RSS subscription processes can better support a user's mental model, turn beginning users into intermediate users quickly, and design for uniformity.
Supporting The User's Mental Model
To start off, let's look at some of the examples that don't do a good job of supporting a user's mental model. By doing this, we'll see where the problems are so that later on we can understand why the good ones are good.
Keep in mind, however, that my intent is not to place blame on anyone who hasn't implemented RSS well. Not everyone is in a position to implement great solutions for this. If they did, great solutions would be more prevalent.
Before developers started finding better ways to do so, RSS feeds were represented as straight XML files. Users were expected to navigate to a page full of XML content, and then copy and paste the URL for the page into an aggregator. Unfortunately, this still happens today.
Figure 1 Ick. XML is simply not meant to be seen by the millions of non-experts out there.
This process is not only anti-intuitive, it's just pain ugly. Clearly, this isn’t going to entice all the non-expert computer users out there to get going with RSS.
This is true because of the lack of a basic mental model. Users have no real-world models, or models based on previous experiences, that help them understand RSS. Really, though, users aggregate news all the time, in the form of the daily news, whether it is retrieved via the Internet, television, newspaper, or radio. RSS is really no different than this in concept. In fact, it's more useful because users can pick and choose the information they want aggregated. Communicating this to users is vital to making RSS catch on. More on this in the next section.
Some browsers try to compensate for this by featuring a built-in RSS reader. Safari, for example, formats RSS feeds so that users don't see chunks of XML, but rather a nicely organized page with options for what and how much information to display. And subscribing is as simple as bookmarking the page. Still, Safari makes no real attempt to create a mental model of RSS for users, making it very difficult for users to see the benefits.
Figure 2 Safari formats RSS feeds so they look nice, but it still doesn't help create a solid mental model for new users.
Turning Beginners Into Intermediates, Immediately
One of the principle problems with RSS is that it requires the user to have an RSS feed reader of some sort, and for him to have a feed reader, he must first understand the value and benefit of having one. But most subscription processes fail to deliver this information in a way that's meaningful.
For site developers to communicate this, instructive elements should be used. For instance, short instructive text can be used to tell users how to subscribe and how to get an RSS reader application or use the ones built into various browsers. Short video clips can also be used to demonstrate step-by-step procedures. At the very least, a page containing a list of available feeds can link off to another page with more in-depth information.
The key is to relate RSS to users by highlighting the benefits of being able to pick and choose the information a user can aggregate. Many users, in response to hearing about RSS for the first time, say things like, "Why can't I just go to those sites when I want the information?" And this is a perfectly valid question. The trick is in helping users realize that while they may only be saving a few clicks right now by aggregating the information they want into a single application, it also enables them to get more of the information they want, on a wide range of topics, from several sources at once, and still read it all in five minutes. For a new user, this really seems to be the key piece of information. Instructive text can be used to communicate this.
FeedBurner makes a solid attempt to help out new users with its formatted subscription pages. First, a FeedBurner page explains where and how to use RSS feeds in a very short bit of text at the top of the page. Then it offers "chicklets" (small subscription buttons) with which users can subscribe to a feed using various aggregators. Finally, it formats the feed content to create a nice display, complete with optional links to do things like email a post or add a comment. Combined, these things teach users quite a bit about RSS in on fell swoop.
The added bonus here is that by displaying all of these chicklets, FeedBurner also tells users they need to have a feed reader in the first place. In this case, the functionality serves an instructional purpose as well.
Figure 3 FeedBurner explains what's going on, how to leverage RSS, and even a way to subscribe to various feed readers.
Designing for Uniformity
Google does a great job of providing a cohesive experience with Google Reader. It can't necessarily do anything to assist with getting users up to speed—that job is up to site developers—but once you're set up with Reader, clicking an RSS subscription button on a web site produces a page that asks if you'd like add the feed to your Google home page or to Reader. The page continues the look and feel established by so many Google applications, including Google's classic, rainbow-colored logo and screenshots of the two applications you can use to subscribe.
Figure 4 Google Reader offers up this page whenever I subscribe to a feed, so I don't have to see XML, copy and paste a URL, or even think at all beyond deciding where to display the feed content.
How do they know I've clicked on an RSS subscription icon? I have absolutely no idea, and I shouldn't have to know. All I need to know is that Google has my back. It knows what I'm trying to do, and it's there to help me do it. Nice.
Until site and browser developers start standardizing the way RSS subscriptions are handled—and the technology's purpose becomes more obvious—RSS will have trouble generating mass appeal. For users to understand the benefits, we need to devise clear and concise ways to communicate them and make the process simpler. We also need to tell users how RSS works instead of assuming preexisting knowledge (as is the case when showing only a page of XML).
By learning from the good examples out there, however, this goal is not unreachable. A few companies, like FeedBurner and Google, have begun to light the path to standardization. The key is to follow their lead and leverage instructive elements to guide users through these interactions, as well as demonstrate the value of the technology. If we do these things, RSS has a chance to gain mainstream popularity.
An obvious design is not far off. We just need to focus on what will make it work.