FeedReader

A feed reader is a tool that collects various feed subscription into a single user interface, where the human reader then gets to read the items from the various feeds with a uniform user interface. The feed reader can be a stand alone application, in a terminal, within Emacs, on a phone, a web application, or simply a static web page regenerated on a regular basis by a job.

Feeds are traditionally RSS 2.0 or Atom feeds, but other variants have been suggested: subscribing to Gemini pages describes how the features of a Gemini page can be translated to the elements of an Atom feed; RSS 3.0 is a way of encoding a feed using a format we all know from mail and HTTP headers (and likely a joke). See WebFeed.

The benefit of the generic user interface

All the items from the various feeds are displayed by the feed reader. Usually this means that font sizes, font families, text colours are the same, and sidebars, toolbars, other navigational aids, ads, and all of that, are simply not shown. The result is a simpler, uncluttered user interface, with settings that apply to all the feeds.

The benefit of pulling information

The feed reader pulls information (the latest copy of the feed) from various sources, either on demand or in regular intervals. Before feed readers, people had to collect bookmarks to the various sites they were interested in and then they had to visit them one by one, checking to see if any new items had been posted. Clearly, a tedious process. Furthermore, as not all sites publish new items at the same rate, many of these visits will turn out to be in vain, as no new items are posted.

The association with bookmarks led to the implementation of “live bookmarks” in Firefox from 2004 to 2018: a bookmark turned into a submenu that was populated dynamically with items from a feed. That didn’t scale well to dozens or hundreds of feed subscriptions, though.

The drawback of network graphs

It is important to note that simple implementations of feed publishing and fetching don’t necessarily save a lot of bandwidth: if a site has n readers that visit every day even though a new item only appears once a weak, six in seven visits are in vain. If n readers subscribe to the site’s feed and fetch it every hour, 167 in 168 requests are in vain.

This is why feeds developed additional metadata to indicate how often they would refresh, and this is why RFC 5005 was added to treat feeds as archives of a site, or how to split up a feed into multiple parts and how to link them to each other. Otherwise, a podcast would either have to list all the episodes forever in an ever increasing feed, or podcatcher programs would be unable to fetch the back catalogue as it wouldn’t know where the older episodes are listed.

The drawback of linearisation in time

Feeds are well suited for a medium that adds meaningful items over time: blog posts are meaningful items and they get posted every now and then, thus treating each blog post as a potential feed item is a natural fit. This is harder to do when the items produced over time are no longer meaningful on their own: on a wiki, for example, page edits happen over time, but just the edit isn’t really a meaningful item (imagine just looking at the list of differences from one revision to the next, intermingled with all the other differences to all the other pages); at the same time, the wiki page itself is a meaningful item but it is not strictly added at a particular point in time. So what do you do now, do you just repeat it?

RecentChanges is a tricky piece of user interface design: it lists points in time (a date and time), mentions the actor (a user name), possibly a summary, and links to both the change made and the complete page. Trying to turn RecentChanges into a feed is difficult.

An easier problem to solve is to pick a subset of wiki pages that do come in a natural order over time: DatePages. Once you do that, there is a constant pressure to bend your writing style to the perceived audience that is interested to be fed meaningful items over time: if your wiki turns out to consist mostly of date pages, the WikiWay has been lost. By definition, the date pages no longer float in the WikiNow. The wiki spirit is lost.

Alex wrote about this on his blog: “All I can say is that my wiki turned into a bliki and then turned into a blog… I wonder how one would push back against this, or whether it is unavoidable.” – The Bliki Spirit

The drawback of a large imaginary audience

Did feed readers create an imagined audience of more than a handful of readers? They enabled larger audiences for smaller sites for sure. It used to be obvious that you need to visit sites like SlashDot to discuss with others. It was a natural consequence of the absence of feeds, and the UI limitations of bookmarks. People necessarily focused on a small number of sites because this was the only way to get replies to your comments. From there, you’d link to the smaller, personal sites, the homepages.

But has that changed our writing on our homepages for the better? I don’t know. If only five people comment on your blog, did you really need to cater to the others? What if you feel that your homepage should be more like a wiki, or more like a book, or more like a directory, and you find that a feed is not a good fit? Do you imagine an audience lost and try to make it work somehow, bending your site structure and writing style so that publishing a feed still makes sense? What is gained and what is lost? Those things might need weighing.


CategoryWiki CategoryBlog CategoryFeed?

(CommunityWikiFooter)

Define external redirect: CategoryFeed

EditNearLinks: SlashDot

Languages: