Shrook Thoughts, Day One

So this is both my general thoughts on Shrook to everyone as well as an open letter to Graham Parks, who shows up regular as kibo every time I mention Shrook. I assume he’s following Feedster or something to catch folks blogging about it. After having read about it a few days ago and seeing it had the OS X 1.3 dependency, I was waiting. Yesterday mornng I saw a reference on the page to the fact that Graham was working on making it work with OS X 1.2 and by the time I checked yesterday it was done and available for download! I installed it yesterday and have only been using for about 18 hours. These are my early impressions.

I’ll talk first about the web page and the integration, because the combination of Mac client and web client is the attractive part of this app for me. They two appear to link together quite well. The latency between changes in one appearing in the other is quite low, low enough that as I move back and forth I haven’t really noticed it not being in sync. The web client is usable, but really needs some work. In my view, Graham should download a copy of FeedOnFeeds and check it out to steal everything good from that interface. On, there is a button to click to mark an individual story read, or a button to mark all stories read. 99 out of a hundred times, I will want something in between those two points. Usually with FoF, that is marking most but not all items read, leaving behind the ones I want to explore further or perhaps blog later. I suppose that as I get used to this, I might begin to use the “flag for later” to take the role that I currently assign to unread articles. I really think, though, that any action you can take on an individual article in the web client should be able to be batched with checkboxes and a “mark all selected read” and a “flag all selected for later” type action. If those were available, I’d be in hog heaven.

The client is pretty good, using the multipanel left to right style that the OS X Finder does, where selecting something in one panel gives a look into that in the next rightmost panel. I like the way the icon in the system tray gives the count of unread items, ala Mail or NetNewsWire. There are a lot of bits though that aren’t that intuitive. For example, in my view of all incoming items, some are greyed out and in some the title is still dark. What is the difference between these two? They have all been read, but there is some form of difference that I can’t yet figure out. In the Channel menu list is “Check All” and “Update All.” Call me stupid, but without reading the manual I have no idea why those two should be different. They sound like the same thing to me.

I like the ability to quickly bop between the 4 panel view and the 2 panel (just the list of items and a view window). I predict that I and almost everyone will spend most of their time in the 2 panel view. I like the snappiness of the checking, and the generally intuitive nature of the UI (with the exceptions noted.) If you are a fan of the brushed metal look of iTunes and such, you’ll like this UI. In fact, it looks a lot like iTunes. Overall I like this tool and find it useful.

Now the negatives. What is a glaring functionality omission is the same thing that was missing in FeedOnFeeds until I patched it – searching. It is highly common to know you’ve read something in one of your blogs but not remember which or when. Searching is essential for me, and to lack it here is a problem. Another huge operational problem – I can tell by watching my server logs when it checks my own blog that it is not using the Last-Modified header. Every 30 minutes it is checking to see if there are new articles by downloading the whole RSS. That is not cool. Even with the synchronized checking to spread out and reduce the load, I think it is a minimum of any modern RSS aggregator to utilize the basic HTTP headers to avoid loading where possible. Even if using a tool that doesn’t make it easy to do the If-Modified-Since in the request, it’s simple enough to do a HEAD first, compare the timestamp in the Last-Modified to the most recent check and avoid loading if unnecessary. Why use bandwidth you don’t need to? If your tool gets popular, this simple omission in your product makes it a part of the problem.

In this tool, new items come in and are unread. You can read them or manually mark them as read, or also flag them for later. Confusingly though, this distinction is called “mark read” and “mark” in the menus, which means you have to pay attention to make sure you are doing the right thing between two choices with opposite intentions that are named almost the same.

Another very large problem for me and why I only have a few subscriptions now is that it will not read the OPML file that FeedOnFeeds generates for me. On attempting to import it, it gives me an error that says “Unable to parse XML – Shrook can only import channels from a valid OPML file”. This is highly frustrating, as the file is obviously good XML. I can import it in Mozilla without parse errors. I have enough subscriptions that I’m not too keen on the idea of cutting and pasting them in one at a time. This is a big problem, because it is one that can make potential users (like me) decide that the cost of switching to this tool is too high. Some people have hundreds – if the OPML import isn’t robust those people are going to bail. I can provide the OPML that won’t import if it helps get this fixed.

Overall, I like it and will consider popping for the $20 to register it before my 30 days are up. It really desperately needs these couple of issues fixed, though – import most of all and Last-Modified compliance nearly as badly. It’s a great start but needs work to become an unqualified killer app.

Published by


Dave Slusher is a blogger, podcaster, computer programmer, author, science fiction fan and father.