FeedDemon Tagging Update

Thanks to the great feedback on my previous post, I’ve made a couple of updates to FeedDemon’s upcoming tagging support.

First off, I’ve added tags to FeedDemon’s subscription tree, as shown in this screenshot (click to enlarge):

Selecting a tag in the tree displays a newspaper containing all posts with that tag.

I’ve also added “suggested tags” to the tag editor, which attempts to recommend tags for the selected post:


I’ll be fine-tuning the tagging features even more before this version is released, of course, but I plan to keep it simple.  I know there’s a lot of tagging-related stuff I could add, but complexity is something I hope to avoid :)

25 thoughts on “FeedDemon Tagging Update

  1. Now we just sit back and wait for the beta, while you do all the hard work :)
    Is there a limit on how many tags it will suggest underneath the used tags box or is it going to end up spilling 50 tags underneath that box?

  2. I would like to see the tag tree to behave like the one in Window Live Photo Gallery, e.g. a selected top-level tag can be expanded to show the other tags on the items tagged with the top-level tag so the user can filter the items by more than one tag.

  3. This looks perfect, Nick! Awesome!
    Regarding your previous comment about RSS category as the source for “suggested tags,” consider also itunes:category, itunes:keywords, and dc:subject as sources.
    @Björn – I’m not sure I understand what you mean by “top-level.” Tags are not (or, I think, should not be) hierarchical. If you mean translating the existence of multiple tags into a tree structure to enable progressively zeroing in on the post(s) you’re looking for, I agree that would be cool … but I can’t imagine what that SQL query would look like. ;-) (Actually, I think that’s one of those nested set problems, but without the hierarchy,)

  4. Looks great!
    I agree with Bjorn that it’d be great to have some way of organizing posts that have multiple tags (i.e. I’ve selected tag X, so now group the posts that are tagged with X, but also Y and Z)… but I’m not sure a hierarchy is the right way to do it and I’m not sure how it would be done in the context of how FeedDemon currently works? A breadcrumb trail is one way, where you click through and progressively narrow your search.
    i.e. at the top of a page of results for tag X, you might have a list of non-X tags that are associated with posts tagged X. On clicking one of those tags — tag Y — the list then filters to show posts tagged with X and Y and, at the top, show non-X and non-Y tags that are associated with posts tagged X and Y.
    And a breadcrumb trail shows the history… but this would be confusing if it was launched from a tree view because it suggests a hierarchy. What you would probably need to start this off with is a page just called “Tags” that showed hyperlinks to all of the tags in use, and progressively narrow the list of results as you click through, as above… to a view showing both the results and the related tags that can be used to narrow the results.

  5. @Björn, @mattbg: I hate to be the bearer of bad news, but a tag heirarchy (or something along those lines) isn’t planned. I believe that would complicate things too much, so at least for now, I’m sticking with a non-heirarchical tag view.

  6. I don’t think I would bother tagging posts. I don’t really see how this is an improvement over flagging/clipping posts. If there are posts I really want to hang onto I’ll send them to Delicious and retain/tag them there.

  7. @Scott, Nick already mentioned in a comment on the first tagging article that the Cleanup Wizard will give you the option of leaving tagged posts alone.

  8. @Nick: I mean the tag thing only for filtering, not transforming the tags into a hierachy themselfs. The SQL should not be too complicated (well, depending on the table structure) to get the other tags on the items that have the currently selected tag, for a three table version it might be something like this:
    SELECT *
    FROM tags
    WHERE tags.id IN (
    SELECT post_tags.tag_id
    FROM post_tags
    WHERE post_tags.post_id IN (
    SELECT post_tags.post_id
    FROM post_tags
    JOIN tags ON tags.id = post_tags.tag_id
    WHERE tags.name = ”
    GROUP BY post_tags.post_id
    ) AND tags.name ”
    GROUP BY tags.id
    As the query should be performed when the user expands the item only this beasts performance is negligible.
    Having that said I can live without this feature – for now :]

  9. @Nick: That would be pretty cool.
    One of my main concerns over tagging (aside from the time involved in doing the tagging) is that by allowing us to tag posts, you are implying that you want us to save those posts for later reference. But that is in direct contrast to the whole FD cleanup functions that we are encouraged to use.
    Personally, I prefer to use FD as a reader and to tag and retain posts for future use using other products and tools. But I guess it really is a personal preference.

  10. @Peter: That’s one of my concerns, too. I never really intended posts to be kept forever in FD, but at the same time, I don’t think purging/cleaning tagged posts would sit well with a lot of customers. Not exactly sure how to handle this at the moment…

  11. @Nick: I’ve always wanted to keep posts indefinitely, in order to have a body of material I can search. I would certainyl like that option, after all, disk space is not exactly expensive. Perhaps you could comment on the technical implications, FD database scaling etc? I would very much like that as a “power-user” option.
    Any thoughts on being able to configure a Watch to do an AND or an OR search for tags ie.
    software AND windows AND backup
    software OR windows
    -not that you would use that in the UI, just that that would be the logic.

  12. @Nick: btw. I’d love to see some kind of delicious.com integration, but it would be the icing on the cake, and come behind features in my last post for desirability, IMO.

  13. @Colm: Technically, the biggest obstacle to keeping posts indefinitely is that FeedDemon uses XML for storage (each cached feed is a separate XML file). This works fine for a small-ish number of posts, but the performance would be abysmal with thousands of posts per feed.
    Tag data in the upcoming release is stored in a SQLite database, which is far better for querying/storing large amounts of data. At some point, I expect to move cached feeds into SQLite as well, which would take care of the performance issues (as well as make searching across feeds easier and faster).

  14. @ Nick: I see your point, that would be a good idea, moving the feeds to a single DB- it would open up some possibilities! Perhaps even my personal favourite, having all of my program state (watches, posts, preferences) sync as well as feed status – a little like Opera does, syncing history and bookmarks etc. Dare to dream!

  15. Interesting concept. Though I use tags extensively in my notes applications, I hadn’t really considered tagging in my newsreader. I’ll certainly give it a good try when either the new version or a beta is available.
    Thank you for your continued efforts, Nick!

  16. FWIW, with respect to keeping posts, I think that the expected behavior would be to purge read posts when the Cleanup Wizard runs, even if they have tags (presumably, they’re less relevant due to their age), UNLESS the posts have been saved to a News Bin … I mean Clippings folder. :)

  17. @Dan, that’s not true. Tagging is a manual operation done by the user. Why bother tagging a post if it’s going to get deleted soon anyway?
    Tagging something (again, manually. If those are just automatically generated tags then it would be different) makes sense if you want to keep the tag on the post, and for that you need to keep the post itself.
    Otherwise you go from answer to “What are all the posts about politics/economics/tv/whatever I found interesting and wanted to keep as reference?” To answers to “What are all the posts about whatever I found interesting, in the last 2 days for busy feeds and the last 30 days for slow updating feeds, and wanted to keep for undefined temporary reference?” .
    I think that the tags would (for some people, myself included) in effect function as a superior version of the news bins.
    Maybe, from the technical side, there may be a fixed news bin used for “Tagged” posts, and anything tagged will be copied there automatically. But that’s an implementation detail, and not something that I think users should constantly maintain manually.

  18. @Dan – Yes, well, I do agree with that. Checkboxes are very good. Especially if it’s someone else who has to write the code to support both options.
    I just felt it’s appropriate to make it obvious that the alternative option is indeed wanted, or expected, by users. It reduces the chance of a false assumption that my expected behaviour is not one of the expected behaviours of users, and that maybe it’s not worth the effort of adding the nice checkbox.

  19. Nick, can i have a beta version to test, please? I’m a loyal power user of FD and i really, really miss exactly this feature. My feedback might be especially useful as i use FD for offline reading about 80% of the time.

Comments are closed.