RSS Part 14: Feature Reflections

There are many RSS clients available, and I have only tried out a fraction of them. I will likely try out some more clients in the future, but I think that now is a good time to wind down and reflect on what I have learned so far. First, I would like to focus on RSS client features.

Efficiency

Why do I focus on efficiency in RSS clients? In general, I am not a fan of “productivity porn” and do not try to maximize productivity in everything that I do. I care most about using my time wisely on a macro level, and I believe that a good balance among production, consumption, and downtime is essential for creativity. The target balance depends on your stage in life. For an adult developer, perhaps 70% production, 20% consumption, and 10% downtime could be a good target. Consumption and downtime are both anti-productive, but they are both critically important for creativity. Consume too little, and your creativity stagnates. Without downtime, you miss out on your best ideas. Too much consumption or downtime makes it difficult to finish non-trivial projects.

Like social networks, RSS can provide a seemingly infinite stream of “news,” and consuming the stream can be very addictive. If you are not careful, you can easily spend too much time on consumption. Through years of experimentation, I have developed various tactics that help me avoid this trap.

I only check RSS/news a few times per day. I generally do so once in the morning and once in the evening. Throughout the day, my RSS client is not open, and I do not receive notifications.

I only use my RSS client for discovering content. I want to process all of my feeds quickly in order to discover content in a timely manner. By “timely,” I mean that I want to know about content soon after it is made available. This is important if I want to be able to participate in a discussion or answer a question while people are still around. Note that this is particularly difficult for me because most discussions happen while I am sleeping, due to time zone differences.

In addition to making sure that I can finish processing feeds without being distracted by content, I found that separating discovery and consumption greatly improves my efficiency. I usually read item descriptions in my RSS reader only for the purpose of filtering. I open items that I am interested in and usually read them in my browser after processing feeds, prioritizing content and allocating time as I feel is appropriate.

Consuming some content, such as an academic paper, can take a considerable amount of time. I use a separate system for tracking such tasks. Like email clients, RSS clients are not an effective TODO manager for me, as the TODO items tend to accumulate and get out of hand.

I hope that this context makes it easier to understand the kind of efficiency that I look for in an RSS client. Some people have different goals, including relaxation and entertainment. Many RSS clients focus on aesthetics to make consuming content within the client a pleasurable experience. Such an RSS client may provide a user interface that looks like a magazine or entertainment system, for example. I do not mind if the client has such features as long as there is a utilitarian interface as well.

Item Deletion

One design choice that greatly affects the way that feeds are processed is item deletion. You delete items as you process them in some RSS clients, while you just mark them as read in others. I have used both methods for many years!

I personally prefer to delete items because I find that it improves my efficiency in processing feeds. In each category, I only focus on the new items; I do not see or think about items that I have already processed. Deleting items also keeps the software as light as possible, which may result in faster performance, smaller network transfer size (in web-based clients), and smaller backups, depending on the client implementation.

When items are deleted, I find that trash functionality is essential for efficiency, as I described in my client requirements. The trash functionality enables you to process items very quickly without having to worry about losing an item if you change your mind and decide to open it. It is important that the trash can be easily searched, in order to quickly locate deleted items.

The primary benefit of marking items as read instead of deleting them is that you can easily reference older items. For example, a new item may make you want to check out an item that you received the previous day but were not interested in at the time.

I have not seen an RSS client that supports both, even though it should not be difficult to implement. Specifically, the state of each item is either unread, read, or deleted. Deleted items are not displayed by default, but they can be temporarily displayed and searched when required. For people who prefer to not delete items, an option could be used to simply not display deletion functionality in the UI. Note that trash functionality is not necessary with such a design. I would like such a design better than any of the designs that I have seen so far!

RSS clients that do not (really) delete items as part of the workflow take up more and more memory over time unless old items are eventually “purged.” The clients that I tried generally allow you to configure when items are purged based on time or the number of items in the feed. I wonder if purging items that are no longer in the latest download of the feed would be too aggressive. QuiteRSS has an option to purge old items automatically when the client is closed, which is a nice feature.

Checking Feeds

Some clients allow users to check feeds manually, while others only check feeds automatically. I want to be able to check feeds manually so that I can get the most recent news at the time that I check it. I quite dislike how Tiny Tiny RSS checks feeds every 30 minutes by default; it is a waste of resources and does not provide news as current as manual checking. Such a limitation would be reasonable in a multi-user system where many users subscribe to common feeds, but it is not a good design for a single user.

FreshRSS has the best design for configuration checking among the web-based clients that I have tried. The idea is to configure both a minimum and maximum amount of time between checks. For example, a feed can be configured to not perform a check if it has been checked within the last 30 minutes and to automatically check 8 hours after the previous check. Defaults can be set, and those defaults can be overridden with custom settings for specific feeds.

I have not noticed any clients making use of TTL settings in feeds.

I was surprised that some RSS clients are really slow at checking feeds. Other clients check the same feeds quickly, so the problem is with the client implementation. Being able to check feeds quickly is very important!

Though I personally do not have any need for it at this time, support for authenticated feeds is a nice feature.

Liferea and RSS Guard both support running scripts to generate or post-process feeds. Generating feeds allows users to add “RSS support” to anything without having to run a separate service, and post-processing allows users to fix problematic feeds. These are great features!

Layout

I am able to process feeds much more efficiently when item content is displayed separately from the item list. I prefer three separate panes:

1. Feeds organized into folders
2. List of items in the feed/folder selected in (1)
3. Content of the item selected in (2)

When using a GUI, I prefer the following layout:

+-------+---------------+
|       |               |
|  (1)  |      (2)      |
| Feeds |     Items     |
|       |               |
|       +---------------+
|       |               |
|       |      (3)      |
|       |    Content    |
|       |               |
+-------+---------------+

When using a web interface, I appreciate a responsive layout. With a small screen, only one pane should be shown at a time. Note that this applies to TUIs as well; using the above layout in a terminal results in quite poor usability.

Hierarchical Organization

As I described in my client requirements, organizing feeds into categories allows me to focus on one topic at a time, increasing my efficiency. Of the clients that I tried out, only the TUI clients do not have support for hierarchical organization.

I greatly prefer that clients show individual feeds, so that I can easily process items for specific feeds. Of the clients that I tried that support hierarchical organization, only Thunderbird lacks this functionality. I therefore have to create folders for each feed, which is an annoyance and causes trouble when importing the resulting OPML file in other clients.

When selecting a folder, the items for all descendant feeds should be displayed, so items of feeds in a given topic can be processed at the same time, when desired. Of the clients that I tried that support hierarchical organization, only Thunderbird lacks this functionality.

Feed titles should default to those specified in feeds, but it is important that they can be customized by users because some feed titles are too general and do not identify the feed.

Some clients automatically sort feeds and folders. Liferea has the best design of the clients that I tried: it allows users to manually set the order of feeds/folders but also has a command to sort them.

The number of unread items per feed/folder should be displayed. Without such information, the user must look at all feeds/folders to see if new items are available. The yarr client is the only one to miss this.

User Interface

Trying out many RSS clients was an interesting tour of user interface design. Usability is difficult!

In GUI applications, the embedded browser is a critical part of an RSS client because item content is usually HTML. Almost all of the GUI clients that I tried looked fine, while RSS Guard’s use of the Qt web view resulted in a surprisingly terrible user interface. Allowing users to customize fonts is a good idea. Almost all of the GUI clients that I tried looked fine with the defaults, but QuiteRSS was an exception.

It must be easy to open links in an external browser. If clients support opening links in a new tab within the RSS client, I greatly prefer that that feature can be disabled completely. It should also be easy to copy URLs. Clients tend to provide a way to copy the item link URL, but unfortunately a number of clients do not make it easy to copy the link for an enclosure. RSS Guard does not copy to the primary selection, making it very frustrating to use on Linux!

I saw a lot of basic usability issues in various clients:

• Some clients fail silently. Error messages in popup windows are frustrating, but silent failure is even more frustrating! A good design provides non-obtrusive feedback of a failure and allows the user to get more information about the failure when desired. As an example of good design, Tiny Tiny RSS indicates when feeds have problems and allows the user to see the details by clicking a link.
• When actions take a long time, the user interface should let the user know that progress is being made. In some clients, I have no idea if I am seeing a silent failure or if I just need to wait longer.
• Web-based interfaces should work with the browser back button. This is especially important when using the interface on a smartphone or tablet.
• Double scroll bars should be avoided! The “global view” in FreshRSS is difficult to use because of this issue.
• Do not place an icon right next to a browser icon that looks the same, as it leads to confusion. Tiny Tiny RSS makes this mistake.

Search

Search functionality is important for finding items. All clients implement search that searches all content, but only some of them support searching for words in titles only. Some clients use a separate “filter” text box for searching titles. Tiny Tiny RSS supports searching titles using a title: prefix.

Statistics

FreshRSS is the only client that I tried out that provides statistics. The provided statistics are unfortunately not very useful. I would really like to have statistics that help me determine how useful a feed is. Perhaps I should write a blog entry just about this topic, but an example of a useful statistic is the percentage of items that were opened. It would be really interesting to see a graph of the open percentage for a feed over time, using exact counts of opened items and total items per month. Such information could be used to decide if it is worth staying subscribed to a feed or not.

Backup

Most clients do not provide any guidance about how to create effective backups. A notable exception is QuiteRSS, which provides ways to create and restore backups from the GUI.

The Newsboat configuration file is plain text, which is particularly easy to backup! The list of feeds does not include information about which items have already been processed, but such information is not strictly necessary.

I would really appreciate a way to programmatically export an OPML file. Native applications could easily provide a CLI command to do so. Web-based applications could provide an API method, but note that authentication may be tricky, depending on the implementation and network configuration.