Sorting Feeds

During the recent feature poll, during discussion in IRC and the occasional feature request in the tracker users did ask for the ability to sort larger feed lists. To allow this we've added a sorting feature to the folder context menu:


It is a simple implementation lexicographically sorting the feeds in ascending order. Nothing more. And we plan to keep it that simple.

In several discussion about the need of this feature the usual argument was about the feed lists being much too long and a specific feed to hard to locate. Sorting all feeds would speed up the feed lookup. To everyone having this problem: please use folders! Organize your feeds in topic folders, don't add more than ~10 feeds to a folder. Don't even start loosing the overview!

I personally do believe the sorting option shouldn't even be necessary. Using folders has too many advantages (recursive viewing, hiding read items) to not utilize them.

Nonetheless "Sort Feeds" is added to SVN trunk to be released with 1.7.5

Use Case 2 - Read latest headlines

The user launches Liferea by single clicking the notification tray icon. Liferea displays the main interface. The user clicks the “Next Unread Item” icon in the toolbar. Liferea moves focus from the currently-selected headline to the next unread headline. If no headline is selected then the first headline in the top-most feed in the tree-view is selected. The contents of the feed item are displayed in the content pane if visible. Liferea marks the feed item as read and updates the font of the headline to indicate as much. The user can continue to advance to the next unread headline by either clicking the button again, or using a configured keyboard shortcut (set in the user's preferences) to page through the article's content and then on to the next unread item once the article's content has all been displayed. Alternately if the focus is on a headline or a feed in the tree view the user can advanced to the next unread headline by using the 'n' keyboard shortcut.

Thoughts and Considerations

• The 'n' key shortcut seems to stop working as soon as the contents of an article are clicked (e.g. a hyperlink is clicked). In order to re-enable the 'n' key shortcut the user has to click a headline or feed name. Is it possible to allow the 'n' key shortcut to always work? Note that CTRL-N always seems to work, but if we can simply have 'n' work without CTRL it saves my fingers from cramping. Is 'n' an undocumented shortcut?
• There might be some confusion around the configurable shortcut to “Skim” through headlines and skipping to the next unread item. They are not the same thing, but the difference is not immediately clear to the user without trial and error (and reading the mailing list in my case). It might be beneficial to look at clarifying the two ideas. One suggestion might be to make it configurable which key is used to skip through as well as which key is to skim through. I'd suggest finding two concrete and distinct words, either within the mental metaphor you're trying to leverage (e.g. newspapers I believe) or within the expected user's vernacular.

For reference, this is related to my intro post.
Other use cases:

• Use Case 1 - Add URL Subscription
  

Feature Poll Results

A while ago I posted a "Feature Poll" blog post which as I expected had a lot of feedback. Everyone simply loves feature wishing list, must remind most of us of birthdays or Christmas :-)

We after reading through the various comments I tried to consolidate the topics and to weight them for the number of mentions (listed in braces). Here are the results and some thoughts on each:

1. Performance (6): Well... not actually a feature. But we are working on it!
   
   
2. tt-rss Sync (6): Syncing to tt-rss or another open source Google Reader competitor


3. Browser Context Menu (4): I grouped several points under this topic:
   • Save Link As (2)
   • Save Image As (1)
   • Copy URL (1)


4. Ubuntu Messaging Menu Integration (3): Actually a patch exists for this. But not a single developer runs Ubuntu, so we cannot really maintain this feature. For now we therefore have decided not to include it.
   
   
5. More Google Reader Features (3): Most asked for is the folder support. Problem is that Google Reader has label-based folders, where Liferea has stricly hierarchic folders, so there is no unique mapping in all cases and we see no sane way to map non-hierarchic labels into the feed list.
   
   
6. Better Tray Icon (2): Here we need artistic contributions! We are developers, not artist. Anyone? Volunteers!
   
   
7. Stability (2): Not a feature, but it is important. We believe the current code is pretty stable.
   
   
8. Alternative DB (2): While I understand the wish, this is a level of complexity 2-3 part-time developers cannot maintain. Sorry, but this is just unrealistic.
   
   
9. Confirm "mark all read" (2): This pops up more often lately. But does your favourite email client ask for confirmation? I believe it to be an untypical behaviour. What could be a solution would be a generic Undo feature requested one time in the comments and regularily in the bug tracker.
   
   
10. Small Icons Toolbar (1): We try to support all toolbar styles GTK does, which currently doesn't include the small icons mode.
    
    
11. Windows Port (1): I understand the wish, but we cannot support an OS we do not use ourselves. This is something that needs a maintainer.

Note: the list above is a quick summary and might miss some topics mentioned.

What happens next?

Please do not despair if your suggestion isn't immediatly realized. We will carefully consider complexity and importance and will realize as much improvements as possible. I believe we should start with improving the context menu and implement tt-rss support.