== Why feed readers are not good for skimming things Here's a somewhat counterintuitive thing that I've come to believe: the conventional syndication feed reader design is the wrong thing for fast, casual skimming. (I call this counterintuitive because feed readers were initially presented as a great way to deal with a a lot of feeds and feed entries, as just the thing to deal with the river of news and so on.) With fast skimming, the goal is essentially to throw things away. You want to drastically limit your time consumption and limit the mental load that the whole effort puts on you. But feed readers are by and large oriented to keeping things around and in your face, with mechanisms like unread entries (which are often given extra prominence so you can spot them easily), having a history of entries (often keeping even old, read entries visible), and so on. From the perspective of conventional reading, all of these are a good thing. But from the perspective of rapid skimming, they are a drawback. If you want to limit the amount of time you spend reading things, you don't want things to stay around and nag people, you want them to go away if they aren't interesting enough to get you to look at them the first time you see them. When skimming, things do not improve with age. (And you want your display to be very dense. Having full entry text right at hand is nice if you often read entries, but if you're skimming you're mostly not reading entries so the text is usually pointless; the same screen space (and mental attention) could be used to summarize more entries for you to skim.) From this perspective, the only thing wrong with the [[social web approach to feeds ../web/SocialWebvsFeeds]] for skimming is that they don't necessarily fade old entries out fast enough. It might be interesting to do an interface where any old entries (well, entry headlines) that were still present were literally faded out, rendered in a muted and easily skimmed over colour. === Sidebar: how we got here My theory of how we got here is that conventional feed reader design applies the basic approach of email reading to syndication feeds. You map syndication feed entries to email messages and feeds themselves to folders, and you come up with the usual interface I've seen. But, the conventional assumption with email is that you basically want to read all of it. This might be right for some syndication feed reader usage, but it is definitely wrong for people who are skimming. (In the process, feed readers inherited the conventional email approach of really only being [[single context applications ../programming/SingleContextApplications]]; they were designed to expect you to only be doing a single thing at once, ie reading a single entry in a single feed.)