To-do apps. Again. I know, this is starting to look like an obsession. But it is fully under control. Trust me on this.

The point that I’m trying to make is that there is room for more than one, depending on the requirements applicable for a given situation. In other words, there is an entire spectrum of capabilities that a to-do app can come with and which may or may not recommend it for a given purpose. Allow me to explain.

There is the “feature-heavy” end of the spectrum that is firmly occupied by apps like Things or OmniFocus. These apps come with a rich feature set and a sophisticated UI to support the user in utilizing these features as good as possible.

And then there is the “lightweight” end of the spectrum that consists of apps that come with a very minimal feature-set with respect to keeping track of your tasks.

For the sake of the argument, there are TO-DOs and there are to-dos. The difference is fuzzy, of course, but here are some characteristics of the lightweight to-dos:

  • They don’t have a deadline or a collection of them shares the same deadline.
  • No need for push notifications and reminders.
  • No recurrence, i.e. once completed, it is OK to throw away the to-dos.
  • The items on the list are thematically related.

Clearly, it would be possible to track this kind of to-dos in apps like Things or OmniFocus as well, albeit with a certain amount of friction.

To overcome this friction, it would be possible to utilize a kind of app behavior that facilitates adding a bulk amount of (fine-grained) tasks to the list. This typically comes in combination with the ability to easily mark a given task as completed or assign further qualifications. Fittingly, there is little or no UI to work with. For example, this kind of app is well suited for setting up shopping lists.

I have always had a weak spot for the idea behind TaskPaper that used to be the prototype of the lightweight to-do apps. The app uses structured plain text for the specification of tasks as well as tags (e.g. @done, @cancelled) that further qualify the task. TaskPaper as a product is available on OS X only.

Back in 2011 I wrote:

The most compelling feature is that the content is stored as a mere text file that can be put on the dropbox so that other instances of Taskpaper can access the same to-do list. Just let dropbox take care of the syncing!

There used to be a first-party app for iOS as well but this one has been discontinued nearly a year ago. Recently, I came across an article on Macdrifter endorsing the app Taskmator as possible counterpart of TaskPaper on iOS.

And sure enough, I like the approach taken by Taskmator1. The app is nicely designed and a pleasure to use. I like the swipe gesture to set a task to “done” and also the strikethrough applied to these tasks has a nice touch:

After I had created a couple of files TaskPaper-style in Taskmator the app started to crash on my iPhone. Unfortunately, it wouldn’t stop crashing. I tried the usual suspects but could not make any progress in achieving more stability.

I guess there is something wrong with the connection to Dropbox, i.e. the crashing stopped after I disconnected Taskmator from Dropbox. This conclusion does not provide any comfort, of course.

The bottom line is that I have to either wait for a fix or start looking for a replacement. Fortunately, there is hope: Editorial 1.1 supports the TaskPaper format. The developer, Ole Zorn plays it low:

Now, before you get too excited, the new TaskPaper mode is not a full replacement for the TaskPaper app, it’s actually more like an additional syntax highlighting mode with a couple of convenience features for editing lists, but it should be possible to build workflows for a lot of the other things.

But in my opinion the implementation of the TaskPaper format in Editorial is more than decent and doesn’t need any excuse. Sure, the presentation doesn’t look exactly like Taskmator and it is necessary to use the file extension “.taskpaper” in order to make Editorial apply the applicable presentation, but that’s hardly a reason not to use Editorial for this purpose:

I especially dig the fact that this is another way to take benefit from a great app, in the spirit of the idea to use one app for many aspects and learn to use it really well.

Again, neither Editorial nor Taskmator will ever replace Things on my devices. However, for all the lightweight tasks that are easier maintained in a pure text format I’m now having a proper alternative at hand.

  1. Although I’m slightly irritated by the fact that the “developer website” registered in the App Store is a generic Facebook page

Elusive Markdown Package

For some reason, a popup-window complaining about the lack of an available Markdown package started to show up on every launch of Sublime Text:

This is strange because the Markdown package is a stock package delivered with Sublime Text itself. It is hard to see which other package might have messed with my installation to make the Markdown package unable to parse.

While trying to hunt down the cause of this issue, I found out that there was no Markdown package whatsoever available in either of the following folders:

~/Library/Application Support/Sublime Text 3/Packages
~/Library/Application Support/Sublime Text 3/Installed Packages

In my particular case, the Markdown package is on the list of ignored packages anyway in order to fulfill a requirement for running the far more capable Markdown Editing package:


But still, Sublime Text is complaining about the missing package and will do so on the occasion of every single launch.

It was obvious that to make the error message go away I’d have to provide the package. But how? See, it’s missing.

I started digging into the contents of the Sublime Text.app itself and sure enough, I stumbled upon the missing package

/Applications/Sublime Text.app/Contents/Packages/Markdown.sublime-package

So, the fix would require me to copy this to the “Installed Packages” folder, right?

Unfortunately, that does not work. What did work, however, is to rename the file Markdown.sublime-package to Markdown.zip, and put the contents of the archive into

~/Library/Application Support/Sublime Text 3/Packages

According to the Sublime Text Unofficial Documentation, the classification of packages is arbitrary and should therefore not really impact the behavior as long as the package format in the respective folder is correct.

Fortunately, I don’t really care about the stock Markdown package as long as Sublime stops throwing error messages at me. As for this aspect, my mission is completed.

You Read It Here First

Several years ago, I was wildly speculating that Amazon might release a tablet with two displays: LCD and e-ink, one on each side1.

This didn’t happen, but now The Verge runs an article about the YotaPhone 2 does exactly that.

I still find this approach interesting, although I can see the downsides in terms of price and device thickness. I’m also not sure how the existence of two displays impacts the mechanical stability of a device with a (well, approximately) 5” display.

And yet, what if this becomes2 the new normal a couple of years into the future? I probably wouldn’t be unhappy about it.

  1. I’m trying to omit the terms front and back for the obvious reason that it may depend on your point of view to decide which is which. It seems that there is only one side with a speaker at the top and this may help to settle the issue.

  2. I know, I know, several years ahead display technology will blow everything that we know now out of the water. But still.


In theory, I have zero need for yet another GTD tool. Things is fine for me, I use it every day and couldn’t be happier with it.

On the other hand, what engineer worth his salt would not be willing to here and there check out other stuff in the pursuit of something1 that may even be better than the already quite sophisticated workflow.

On a related note, Todoist has received flying color endorsements from Federico Viticci during recent episodes of the Connected podcast.

So I gave the whole thing the benefit of the doubt and dipped my toe into Todoist water. Like Things, Todoist is available on all the platforms I care about.

Unlike Things, it is also available in the nearest Web browser. This doesn’t make a big difference for me because, as mentioned before, there are native apps on the platforms I care about.

Did I say “native”? Well, at least when it comes to the Mac app, doubt is more than warranted. I didn’t care enough to research whether my impression is correct, but this screen shot speaks volumes.

The screen shot has been taken right after one of my desperate attempts to create a recurring item in Todoist. I tried in the Mac app and I tried in the Web app, and the result looks identical on both platforms.

Entering recurring deadlines is, as far as I can see, only possible by trying to convince the natural language parser to start making sense of my input. This works for simple cases, but everything falls apart as soon as things get a little bit on the non-trivial side.

Mind you, I’m totally OK with natural language input as long as it gets me 70-80% to my goal. Even showcase apps for natural language parsing stumble here and there over my input. That’s OK, at least as long as there is a dialog-based fallback where things can be sorted out properly.

But if natural language is your only option, as in Todoist’s case for recurring task deadlines, it’s either 100% success or fail.

So, in my case: fail2. And that’s exactly when Todoist displays an error message like the depicted that is only partly visible. Yes, the left part of the pop-up dialog is clipped at the very left border of the Todoist app in the same way that this dialog is clipped in a web browser3.

I am very well aware that this description of my first impression of Todoist is not properly supported duly by a thorough research of how I could have improved my initial time with Todoist.

In other words, I’m admittedly not playing fair at this point because I could have spent more time to find out how to embrace Todoist and follow Federico on his journey.

Maybe it’s because I’m just not desperate enough. See, I’m in the comfortable situation to already have a perfectly working solution.

One way or the other, this concludes my experiment. Whatever goodies Todoist may have in store that may convince me to move over will remain unexplored. There’s simply too much friction. If I cannot manage to do the easy stuff with little effort I have totally no incentive to even try the potentially harder things.

  1. As they say, better is the enemy of good.

  2. In my case, the deadlines are set to one minute before midnight no matter how hard I try.

  3. Trust me on this, I checked.

Standardization Woes

For many people, Markdown is the front and center of their textual workflows, and rightfully so.

Comes Jeff Atwood and says that Markdown needs standardization to become even more useful because, come standardization, 15 Markdown processors wouldn’t create 22 different results of the same source (or maybe it was the other way round).

This has caused a lot of discussion, mostly around the naming of the standardization project, less so about the question whether it really makes sense to standardize in the first place.

Personally, I’m not so much interested in trademark discussions. My primary interest is the standardization goal as such. In other words, is there really a point for a standardization effort, given that the tool landscape for Markdown-related tools is arguably thriving.

So, what is the use case for the standardization, what comes out at the other end that substantially benefits the users of Markdown? Or else, could it be that the standardization effort is not so much aimed at the benefit of the users but at the convenience of the creators of Markdown tools?

Dunno, the participation of John MacFarlane (who is the original author and maintainer of pandoc) in the standardization initiative may be an indication that the latter question could be key to understanding the motivations behind the project.

In this article, I’m trying to identify the potential use cases that may be taken as a motivation for a standardization effort.

So, here is a list of use cases that may benefit from the existence of a standardized Markdown along with some personal comments.

Markdown files are exchanged between several users

This case describes a scenario where Markdown sources are shared, or exchanged between a group of authors. I would assume that, in the absence of a standard, it seems totally feasible to agree on a commonly agreed toolchain for the processing of the sources.

To some extent, this is similar to the creation of a software project in C. Especially when it comes to the deployment to an embedded platform it is necessary to come to agreements about the applicable tool chain, whether the underlying language is standardized or not.

For practical purposes, a standard would be nice but far from being indispensible.

Same source is processed in different toolchain for different purposes

Again, I’m not sure.

Granted, I (for example) use different tools that may or may not produce the same output on the same piece of Markdown source. But the thing is that these tools cover different areas and therefore the situation that they would all be taken to process one specific piece of Markdown is not very realistic.

One example for this is the usage of tables. These may (for example) be relevant for creating a blog post or a scientific paper. But, on the other hand, for keeping a daily journal of your activities a table is probably of secondary interest.

Don’t want to remember which markup flavor to use in which tool chain

This is basically the opposite situation to the first use case where many authors work in one tool chain. Here, one author works with multiple tool chains.

In this situation, people may not like the idea to distinctively consider which specific style of markup to use in different authoring tools and post-processing toolchains executed for the different purposes of their writing.

Admittedly, this concern may hit home, or some kind of home. On the other hand, the same situation comes up if you (have to) work in two different flavors of the same programming language, like Python 2.x vs Python 3.x.

And if you like it or not, the existing chasm between different flavors of Python (or Ruby, for that matter) is the result of moving a living standard forward. This may come with breaking changes.

Let’s assume that a standard definition of Markdown exists and that, after some time, this definition needs to go forward to meet future requirements. Then, the probability of Markdown creators ending up in pretty much the same situation as today is certainly non-negligible.


To summarize, after considering these cases I’m personally still fine with the current situation and the tools available for various purposes. I guess we’ll see what comes out at the other end of this “standardization” effort and whether there’s any benefit for the rest of us.