honekamp.net

It’s the Reading Experience

I have been a big fan of Reeder on all my platforms for a long time now. The app is rock-solid and gets updated on a constant, albeit sometimes slow pace.

I use Reeder every single day, it is easily one of the most-frequently apps I have used in the last several years.

This makes it very hard for competitors to even come close to the experience I get from Reeder. And still, from time to time, I’ll try one to see how it works out.

On iOS, The most prominent candidate in this category is Unread. Unread is an app that’s highly polished with respect to the appearance and also the user interaction, which boils down to fluid sequences of swipes that seem very natural and appealing.

One aspect, however, drives me away from Unread every single time I give it a try. The app has a limited preset of font sizes between wich you can select. Personally1, I prefer the lower end of the font size but unfortunately the difference between the smallest font (“atomic”) and the second-smallest (“tiny”) is uncomfortably big.

This means that “tiny” is way to large for my preferences and “atomic” is way too small. That really kills it. Undeniably, a lot of thought went into the design of Unread but the reading experience, which is essentially the point if the app, fails to deliver the same amount of polish. It’s tragic.

Reeder, on the other hand, may overall not be as pretty as Unread with respect to the app design. But boy, does it rule when it comes to customizing the article view, which is arguably the part of the app that is used the most.

You can not only control the font size, but also the font face and the density of lines of text. There’s really not much room for improvement left.

This strange relation between Reeder and Unread is mirrored by two other apps that address a very similar prominence for my personal app portfolio: read later services.

I guess it is safe to say that the two major apps in this domain are Pocket and Instapaper.

Frankly, only one of the two mentioned apps/services, Instapaper, delivers a reading experience that is on par2 with Reeder.

Nevertheless, both Pocket and Unread have a fan base of considerable size. Even though this seems weird to me there are certainly reasons. And furthermore: a lot of products arguably fail to deliver on their supposed core competency, but are still quite successful in their respective domain.

Cars, TVs, headphones, you name it.

  1. despite the need to wear glasses

  2. if not even more advanced

Evernote News

You’d normally find my grinning from ear to ear after reading this announcement written by Evernotes new CEO Chris O’Neill on the Evernote Blog:

Evernote’s strength is in its core: notes, sync, and search. That’s where we’re going to focus.

Unfortunately, the same article also mentions a round of layoffs and that is hardly a reason to celebrate.

For the last few months, I’ve been on a more and more desperate lookout for a replacement for Evernote that excels at exactly that1: notes, sync, and search. And nothing else.

I’ll more than happily stick with Evernote it this announcement gets anywhere near reality.

Oh, and if Evernote opens itself to the point that there is a non-creepy way to export or migrate notes to a different service. Just in case.

  1. And doesn’t bug me to check out the latest hype feature added to the service.

Todoist, Again

For better or for worse, I’m a busy person1. I’ve got stuff to do. Lots of. Contrary to many others, I’m not very good at juggling all those bits and pieces in my mind, I rely on some external help.

In other words, I enjoy2 the fact that I can off-load all the little and not-so-little tasks that I have to take care of into an app that allows me to organize, review, check-off these tasks and, if need be, remind me of deadlines that I have to take into account.

In other words, the GTD principle really resonates with me. That’s why I’ tend to have both an open mind and a weak spot for the figurative “fresh air” that comes with new apps and services in this domain. Of course, not every single one of them. But in some cases I just can’t help kicking a few tires here and there.

After all, fresh air brings new perspectives and that is hardly a bad thing. There is always room for improvement, as they say.

In this spirit, I have spontaneously replaced my app of choice by Todoist for the time period between beginning of June and mid of August. From the beginning, it was meant to be an experiment, to find out whether the strengths of Todoist would work for me.

The strengths, in particular, that I was interested in boil down to the following list of topics:

Without further ado, the experiment is over, and I have more or less unceremoniously stopped using Todoist. This is what comes out of it3:

  • The biggest obstacle in using Todoist is the software quality. In many cases I had to force-quit the iOS app to stop it from butchering the list of tasks to the point where specific actions were only halfway visible. The “native” app on OS X is (as much I regret to say this) still a joke. And then there are design decisions that are really hard to understand. A GTD-app, in my opinion, should never put anything between you and the ability to dump tasks into it. In Todoist’s iOS app, there views where it is positively impossible to add a new item.
  • The ability to use a Web Browser to work on the list of tasks is a nice thing to have, but I ended up using it not nearly as much as I expected it to use.
  • The integration with e.g. my calendar works pretty well, but after a couple of days I stopped using it. It is hard to explain, but the appearance of tasks in the calendar seemed bloated. Maybe that is because I usually have way more open tasks than calendar entries. Consequently, it seems more natural to have it the other way round: display my calendar entries inside your GTD app4
  • I like the simplicity in the design of Todoist, but the simplicity is also what made me more and more unhappy. I ended up wanting more.
  • The natural language input works in a lot of cases5, but there are also cases where it was positively standing in my way. For example, if the task description makes a reference to an event at a certain date it happens that the natural language parser gets confused and doesn’t know what to do. To be fair, this also happens in Fantasical, which runs one of the best natural language parsers around. I found myself regularly reviewing the help pages that give hints for formulating the natural language queries. The necessity to memorize certain “trigger phrases” in order to productively use NLP reduces its benefits, by a lot.
  • The custom filters seemed like a good concept at first. The ability to define arbitrary views on the collection of actions got me intrigued. However, in part because the query language also takes some memorization and/or lookup in the help pages I eventually I never really used a custom filter. I heavily used the built-in filters, on the other hand.
  • Attaching stuff to actions grew on me. I realize that it should be taken lightly in order to keep syncing under control, but in some cases it is really a game-changer.
  • Interestingly, the integrations with third-party services didn’t take off for me. I’m just not a heavy user of all the services Todoist intergrates with. I played around with some of them, but not in the “productive” sense.

There are a lot of good ideas in Todoist, and I can see folks with a bit more emphasis on integration with third-party services happily use Todoist. But the balance between feature and problems doesn’t work for me.

On the other hand, I realized in reviewing my own conclusion that I had indeed gained new perspectives into the general issue of managing my poor brain:

  • As mentioned before, the idea of a “unified timeline” of to-dos and calendar entries has some appeal to me, if served insight a GTD app.
  • The other conclusion is that different views on the list of actions, as implemented by the the filters offered by Todoist, still seem like a good idea. I want to use this or a similar approach in the future.
  • I just don’t want to go without attachments any longer.

What can I say, all these conclusions consequentially made me switch to OmniFocus.

  1. A consequence of which is that I don’t have the time to write as much as I’d want to.

  2. In some cases, literally.

  3. This list mentions some terminology (e.g. “filter”) that is specific to Todoist. I take the freedom to not explain every such aspect, more more details please have a look a the respective product pages.

  4. Unfortunately, Todoist provides no option to implement this view. To my knowledge, the only GTD app that supports this option is OmniFocus.

  5. And it is a big improvement that Todoist changes the background color of all words that it has identified as part of a date input.

El Cap and My Printer

Beta versions of software are always good for a surprise and this is especially true for beta versions of system software. After trying out the current beta of the new OS X release (a.k.a. El Capitan) it turned out that my printer (a Dell C1765nfw) would no longer work.

The PrinterProxy displayed an error message along the lines of

Stopped - ntdcmsmac open fail:dlopen(/usr/lib/dlthm1zcl.dylib…

I went to my preferred search engine and it came back with a couple of hints that suggested trouble:

Perhaps you need to disable sip before using your printer. Some folders in /usr/ directory has[sic] been locked due to sip.

Well, System Integrity Protection (SIP) is here for a purpose and I wouldn’t want to permanently disable it only to be able to use my printer. I needed a better solution.

Since I wasn’t able to find the solution that finally worked for me on the Internet1 I’d like to share it here (the usual caveats apply):

  • Download the latest printer driver.
  • Reboot into OS X’s recovery mode.
  • Open Terminal and deactivate SIP by typing csrutil disable. The purpose of this is to let the printer driver’s installer properly do its job.
  • Reboot.
  • Run the printer driver’s installer.
  • Try out printing. Yes!
  • Reboot into recovery mode.
  • Open Terminal and re-activate SIP by typing csrutil enable.
  • Reboot.
  • Try out printing. Still: yes!

I’m pretty sure that there will be a less painful solution for this issue once the dust has settled. But for the moment this approach worked pretty well for me.

  1. After all, I was tipped off by this page about how to disable and enable the SIP.

Is 3 Read for Prime … Wait a Minute

Stop, I’ve already spent this headline, albeit on a different subject.

This time, however, I’d like to briefly discuss my first impressions of Octopress 3, the next evolution step of the static blogging engine I use for publishing this blog.

Octopress 3 has been around for a couple of weeks. As I write this, Octopress 3 can already look back to a rapid succession of bug fix releases ending up in the currently available 3.0.11.

Of course, as a user of Octopress 2, I’d be intrigued1 to see how the platform is making its way into the next major release.

When using Octopress 2, it does not become immediately visible that the heavy lifting of blog generation is actually done by Jekyll, and that Octopress 2 is basically a convenience wrapper around Jekyll that takes away some of the rough edges of directly using Jekyll for blog generation.

Octopress 3 takes a different approach in that it clearly separates its job to “logistics tasks” on top of Jekyll, and then let the user actually call Jekyll as part of the publishing workflow.

I don’t have a problem with this approach, as long as it’s working as advertised. Which it does, as far as I can tell.

At least, I was able to install Octopress 3 and further gems2 as well as to port my blog to the new engine quickly. Menaing: it took a short amount of time after having installed Octopress 3 until I got my site up and running served locally by Jekyll.

That’s not the end of the porting effort, though. The slugs generated by the combination of Octopress 3 and Jekyll are different than the ones generated by Octopress 2.

This is a bummer, and leaves the option to either tweak the new workflow to the point that it creates identical slugs as my existing engine, or else create redirect permanent rules into a .htaccess file to accodate for the change.

Of course, the .htaccess file is sort of the last resort. And it would be nicer if the job could be done directly as part of the generation process.

And it turns out: the easiest way to generate the slugs as required is to drop all the categories from the blog. Which is OK, I have used the categories more or less halfheartedly and getting rid of them is not such a big deal.

The landing page that I end up with consists of a list of article headlines as opposed to a list of full articles, as I end up with in Octopress 2.

Customization will be necessary. This has been foreseen by Brandon Mathis, the main contributor to the Octopress project. It seems that it will be possible to define Themes as a measure of customizing a blog extensively.

There is a default theme available, called Octopress Genesis. According to its description, it is a “work in progress”. It is certainly possible to use the theme as is, but I unfortunately failed to find out how to apply any customization to it that was respected in the generation.

In principle, it should be possible to overwrite the default theme by putting the respective files into the _plugins directory. I tried several variations of putting the files into the directory, but to no avail.

Maybe this is part of being “work in progress”. I looked up how plugins are processed by Jekyll. I didn’ get the impression that themes are processed as plugins, but maybe that’s just me.

Anyway, the theme also does not generate a landing page that is a list of full article text either. On the bright side, it takes care of footnotes in the way I prefer footnotes to be taken care of: Bigfoot style. And, just to name another nice feature, it is possible to add pages to the site in a very simple way.

Granted, it would be possible to tweak the theme in its default installation location. But, frankly, that’s an evil hack. In conclusion, without being able to customize3 the theme Octopress 3 is not really usable.

So no, not ready for prime time so far. Not for me, at least. I’ll need to invest more time to better understand how the customization of Octopress 3 is supposed to work. But never mind, I can wait, no problem.

  1. I’m not a web developer, but I’ve always enjoyed tinkering with Octopress, and thereby get in touch with technologies unexplored.

  2. From the technical point of view, Octopress 3 is delivered as a gem rather than a bunch of rake tasks.

  3. I mean, a serif font, come on …