Stupid Users

The recent discussion of RSS readers run amok got me to thinking about how much of such a problem is the fault of the user and how much is due to bad design or default configurations. With any good design there is a trade off between simplicity and functionality and we rely on users to have a certain level of competence. The trick is to make the system work well without placing an undue burden on users to be experts from the start.

So the question we have to ask is if we should blame or punish users who cause problems as a result of ignorance or incompetence. Perhaps our design was too complicated and they couldn’t figure out how to change the settings. Perhaps the various options were not labeled in a meaningful way so they didn’t really understand what the ‘server polling period’ (or some other term) was about. As designers we have to ask ourselves if the failures or problems are a result of our own bad designs or a failure to provide adequate instruction to users.

If we want RSS readers to be truly popular with the masses we can’t expect the majority of users to think about server loads and other issues. Pete Freitag has made some interesting suggestions about how we could use cookies and proxy caches to fix some of the technical problems related to IP banning. Thinking about how we can solve the problem without asking users to understand or fix technical problems is a move in the right direction.

I’m not sure where the balance point is with RSS that will leave non-technical users able to happily use a reader while still allowing power users to tweak away. Whatever it is, we need to make sure that we are not asking too much of users or punishing them for not understanding complicated technical problems. I know most people, myself included, have muttered to themselves about the ‘stupid users’ screwing things up. We just need to make sure that when we mutter that it’s not a reflection of our own stupid designs failing.

Kevin Hall
Latest posts by Kevin Hall (see all)

5 thoughts on “Stupid Users

  1. What if there was a way for the CONTENT WRITER to determine how often the RSS/Atom reader polls your feed for new content. Then you could select a poll rate that fits your own bandwidth/server capabilities. Big news sites could allow polling every few minutes, and smaller weblogs could allow polling every hour. Of course, we would still be at the mercy of the feed reader’s compliance with any such standard, but it would put the power back in the hands of the feed owners. It would also do away with the unpleasantries of IP banning and notification messages and whatnot. Sure it’s a long stretch, but that never stopped us webfolk!

  2. Tom, I really like this idea. It seems that a simple addition to the RSS or Atom spec would allow for this (it may be in there, I’m still relatively new to feeds). A reader could then extract the polling frequency from the feed itself the first time it is read. If it is updated in a later feed the reader could automatically change to match the content publisher’s desired minimum polling frequency. This could be an optional attribute in the feed’s XML file and could be configured easily enough in most systems. The reader could then use the minimum time provided in the feed or the time provided by the user, whichever is greater. It also takes the responsibility away from the user who shouldn’t have to think about things like server load anyhow.

    I actually don’t see why this would be that hard to integrate into a reader. A simple file containing the various polling frequencies for the feeds the user subscribes to could be used and all that needs to be tracked is the time of the last feed so the reader knows how long to wait before checking again.

  3. I did a little reading, and it turns out RSS already has this feature. It’s the “ttl” element, and specifies exactly what I was saying before. Nick Bradbury, author of Feed Demon goes over how his software handles this issue.

  4. Way to take the initiative there Tom. And way to go Nick for thinking about this and including it in the design for FeedDemon. I’m using intraVnews in Outlook and wasn’t sure how other readers handled these things. Not only does FeedDemon support the ttl (minimum polling time) attribute of RSS but it also uses the skipdays and skiphours as well. This is a simple elegant way for content producers to take control and make sure that readers aren’t polling the server too often. Glad to see this handled well in FeedDemon, I hope that other RSS readers come with similar functionality and reasonable default polling periods.

Comments are closed.