Forcing favicon reload in ReadKit

February 18, 2014
by Riccardo Mori
Briefly

On my MacBook Pro, my RSS feed reader of choice is ReadKit, and I like it a lot, because of its UI similarities with Reeder for Mac, and also because of how it handles my Pinboard bookmarks (as if they were feeds, in fact). 

Like many other feed readers, ReadKit displays the site’s favicon next to each feed:

Readkit favicons

Sometimes, though, favicons may get corrupted or the site owner may update them (as I myself did with my site). It’s just a minor detail, but in such case I want the feed reader to show me the updated favicons. All feed readers usually keep a favicon cache to avoid loading them every time you launch the application. It usually resides in a folder inside [your username]/Library/Application Support/[app name]. Typically, to force the feed reader to reload all favicons, you’d delete such cache, but with ReadKit I couldn’t find anything of the sort. ReadKit doesn’t even create a preferences file in the usual [your username]/Library/Preferences folder. 

After a deeper search with the always excellent Find Any File, I found out that ReadKit stores favicons in a favicon folder inside [your username]/Library/Containers/com.webinhq.ReadKit /Data/Library/Application Support/ReadKit/ Simply delete the contents of that folder (keeping ReadKit closed), and relaunch ReadKit. All favicons will progressively reload.

App.net introduces the Comments Widget

February 14, 2014
by Riccardo Mori
Briefly

From the App.net blog:

We get a lot of requests to create a way to leave a comment on a web site using your App.net account. So, at the last App.net Hackathon @voidfiles decided to build the App.net Comments Widget, which does just that. […]

The App.net Comments Widget is built on top of the App.net API, and all comments are actually public posts. Conversations within the App.net Comments Widget – comments, replies, and stars — can take place on your web site, or inside an App.net client as well.

We wanted to make the App.net Comments Widget as accessible as possible, so it only requires one line of html to install on your web site. We also enabled login with Facebook, so folks can participate, even if they don’t yet have an App.net account.

This is a great idea and a straightforward implementation. One more reason to be a satisfied App.net paid user, or to join the platform if you’re not aboard already.

 

In related news, if you’re an App.net user you can subscribe to my Broadcast channel to get real-time push notifications every time I publish a new article here. I’m also testing the Subscribe via email service, which allows you to receive email notifications when a new article is published. (Check the sidebar.)

Here’s what a Broadcast email notification looks like:

Appnet email notif

Drop support, but leave old versions around

February 11, 2014
by Riccardo Mori
Handpicked

In a recent post called Dropping Support for Older OS Releases, Brent Simmons suggests that developers drop support for older OS releases as a way to optimise resources and keep making quality apps. From a developer’s standpoint, he’s certainly right. From a user’s standpoint, there are some observations to be made here. He gives three main reasons to drop support:

There’s almost no barrier to OS updates these days. They’re free and easy to install.

True. Unless your Mac doesn’t support the latest version of Mac OS X.

People who don’t upgrade their OS are also the kind of people who don’t buy apps.

If I may, this is a rather superficial assessment. There are at least a couple of reasons behind not upgrading to the latest OS release:

  1. Not everyone owns a new Mac, and not everyone purchases a new Mac every year or so. There are still a lot of perfectly good Macs in use that cannot be upgraded past Mac OS X 10.7.5 (MacBooks from 2007 and 2008, the original MacBook Air, some older MacBook Pros, etc.)
  2. There are people still on Mac OS X 10.6.8 (Snow Leopard) because they find it to be a better performer and a more stable version than Mac OS X 10.7 Lion on their machines. And if they also own one of the aforementioned Macs which can’t even be upgraded to 10.8 Mountain Lion, I perfectly understand why they’d want to stay on Snow Leopard. I recently helped a friend configure his home network, and he still owns an early 2007 MacBook Pro with Snow Leopard installed. While using his MacBook Pro, I noticed how snappier it felt than mine, which is almost three years newer and runs Mavericks. And while the ‘performance feel’ of a Mac might be subjective, things like Wi-Fi stability are not. Using my friend’s older MacBook Pro reminded me of how generally bad Wi-Fi performance has been in OS X from Lion onward.

In both these cases, I don’t see any correlation between not upgrading and not buying apps. On the contrary, I know people who would love to buy more apps for their older Macs, but with OS X 10.8 Mountain Lion as a minimum requirement, they simply can’t.

An app succeeds based on quality, not breadth of OS support. You can make a better app by using newer APIs. You can make a better app by not having to spend coding and testing resources supporting older versions of the OS.

Nothing to argue here.

Brent adds:

Yes, you will leave some small number of people behind. It’s worth the trade-off, though, because it’s your job to make the very best app you can make.

Well, I don’t know about that small number, especially outside the North American tech bubble. Anyway, I have a humble suggestion to add to Brent’s overall very agreeable point of view: developers willing to drop support for older OS releases should keep older versions of their apps available for those users who don’t own the latest Macs and/or can’t upgrade. For example, if version 1.2 of an app is the last version supporting OS X 10.6 Snow Leopard; 1.5 is the last version supporting OS X 10.7 Lion; and now the app at version 2.0 only supports OS X 10.8 Mountain Lion and above, then they should leave those previous versions available on their site (since it’s not possible on the Mac App Store), clearly indicating that support is only available for the latest version. This way, even users on Snow Leopard and Lion can enjoy that app, even if it may lack features introduced at a later date. 

Many (Mac) developers don’t seem to do so, instead they maintain very streamlined websites showcasing only the latest version of their app. I don’t see any significant downsides in leaving older versions available for download. They can focus on perfecting their app for the most up-to-date audience, while leaving virtually no one behind.

Why the WordPress iOS app is useless to me

February 6, 2014
by Riccardo Mori
Briefly

The WordPress iOS app has indeed improved over time, especially for writing a blog post, but still not enough to be a solid official client, in my opinion. I don’t know you, but the main reason I installed this app on my iOS devices was to manage my blogs, rather than using it as an on-the-go solution to write on them, or to ‘interact’ with other WordPress blogs in the same way one does with Tumblr, for example.

Therefore, in its current state, and for my current needs, the WordPress app is of no real use to me. There are a few little annoying things, interface-wise, which have led me to get rid of it.

 

#alttext#

1. The mildest peeve is visible in the figure above: the default section when you open the app is Reader. Since I’m not following any blogs, I keep getting this screen. It would make more sense that the app defaulted to the Me section, wouldn’t it?

 

#alttext#

2. When you get a notification, and you go and act on it, the action buttons have no feedback. In the example above, I received a comment which I need to mark as spam. When I tap on the flag icon, nowhere in the interface I get a confirmation that my action was registered, and I’m left with the doubt whether the app has acted on it or not.

 

#alttext#

3. When I return to the Notification screen, some comments in the moderation queue are marked as Pending, even after dealing with them. At first I didn’t know why this happened, then I remembered that I had handled those comments via the admin interface in the browser on my Mac. Evidently the app doesn’t sync what gets moderated outside the app. The result may be confusing, especially when you tap again those Pending comments, try processing them again, and nothing appears to happen because of the aforementioned ‘no feedback’ problem.

Wherefore art thou, Poster?

In June 2013, Automattic acquired the great Poster, a WordPress iOS client by Tom Witkin. I personally find a bit infuriating that they removed Poster from the App Store, when they could have simply rebranded it and make it the official WordPress client, like Twitter did with Tweetie. Poster had a really nice interface and was definitely more mature an app. Instead, at least for now, we’re left with this rather bland offering.

Unread: the brief review

February 5, 2014
by Riccardo Mori
Software

Unread article list dual

Unread is a new RSS reader for iPhone by Jared Sinclair, also developer of Riposte (an App.Net client) and Whisper (a group messaging app for App.Net).

Jared Sinclair begins his article Designing Unread by stating that at the time he decided to make Unread, he wasn’t using RSS anymore. I had stopped checking and reading my RSS feeds on the iPhone soon after Google shut down Google Reader and my then-favourite RSS app, Reeder, stopped working as a consequence. Then Feedly debuted, and I decided to use that service mainly because it made the transition from my previous Google Reader account very painless. 

But when I resumed reading RSS feeds on iOS, it was only on the iPad, and with the Feedly iOS app itself, which I instantly liked for its Flipboard-style article presentation. On the iPhone, at first I thought about returning to Reeder after its update as Reeder 2, but I admit to not being thrilled by having to pay €4.49 for an app that had essentially regained its ability to synchronise with a RSS service, and not much else. In recent times, an interesting app — My Paper by Harry Works — brought me back to reading RSS feeds on my iPhone. It’s a free app, with a nice iOS 7 design, and there’s much to like about it. But I ultimately knew it was a temporary solution.

As soon as I heard about Jared Sinclair’s project, and read his article The Philosophy of Unread, My Forthcoming RSS App, I was sold. Considering how much I like Riposte, I knew that Unread was going to be an app made with care and attention to those details that really make an app work. I knew I would purchase it as soon as it hit the App Store.

I promised a brief review. Here it is, in the form of a list of personal highlights about Unread.

  1. The choice of typefaces is perfect. Whitney and Whitney Condensed by Hoefler & Co. They make for very pleasant reading (see image above).
  2. Gestures. In a post directed to Sinclair over at App.Net, I wrote: I usually don’t like apps whose navigation relies on gestures a lot (I am a button fan), but your apps are something different — gestures are implemented so thoughtfully it all feels very natural. And I mean every word. Perhaps the reason I like gestures in both Riposte and Unread is well explained in Sinclair’s Designing Unread: “One of the things I learned from people’s positive feelings about Riposte was the importance of using gestures solely for navigation and not mixing navigation gestures with action gestures.”
  3. The bottom bar. You always know where you are.
  4. Article summaries are not truncated.
  5. This: If an article is determined to be a Linked-List style article — i.e. the article’s URL is a link to another site and not the permalink — then the domain of the linked item’s URL is displayed at the bottom of the summary. (I’m quoting again from Sinclair’s article)
  6. The tasteful use of colours. Unread’s basic palette revolves around white, black, red and dark grey. As a result, all icons appearing in menus throughout Unread really pop. I like that.
  7. The easter eggs (hidden colour themes).
  8. Gestures. Again. You don’t have to position your thumb on a particular spot to swipe and navigate inside the app. “This helps make Unread comfortable to use with one hand, no matter what size iPhone you have or how big your hands are.” (Again quoting from Designing Unread)
  9. Unread has character. See this other quote from Sinclair: “I didn’t make it to be a feature-for-feature replacement for an app you may already be using. That would make Unread merely a thin coat of paint on old ideas.”
  10. The bottom bar in Unread’s built-in Web browser. Nothing special, you may say. I say it fits perfectly the app’s fluid navigation.
  11. Unread performs very well on an older device like my iPhone 4.
  12. There are 1.0 apps which, after purchasing them and using them for a bit, get me thinking about which features they lack. You know, when you think It would be cool if (App X) had this and/or could do that…. After purchasing Unread yesterday, I had 395 unread articles in my feeds and spent a good while reading them, enjoying Unread for a good couple hours of continued use. Never for a second did I think something was lacking or needed refinement. To me, Unread is that good. But of course it’s a matter of personal tastes and needs.

Launch price: $2.99/€2.69. It’s worth every cent.