Niels K. logo Niels K.

Wenn ich mit meinem geschützten Account jemand ne Mention schreibt, der mit nicht folgt, kann er die dann lesen?

App.net: Sending PMs to people who can't receive them results in…nothing

Last weekend I sat together with @map and we noticed the following behavior on app.net: When you send someone a private message that has his privacy settings set in a way, that the person can’t receive a message from you, then well, nothing happens. For you it look likes that they received the message, but they won’t get it.

Except one of two things is happening:

  • they send you a private message
  • they change their setting to something that they can receive a private message from you and you send her a private message

In both cases they will see all private messages sent previously.

To understand that behavior I have to get a bit technical here and since I am not a developer, I hope that I do not mess up :)

Sending someone a private message creates something called a channel. Depending on the private message-settings of the user, you have the ability to subscribe her to this channel or not. If not, the channel will be created, it will look like you both are a member of that channel but in fact only you are (at least in my tests it seemed that way).

Now my question: Why doesn’t the sender get an error message? After all for the sender it will look like you are ignoring her and not as if you cannot get the message. Which can lead to real life social problems (like people thinking you are a prick).

From what I gathered my understanding what the reasoning on app.nets side is that:

  • the receiver could have a setting in place that he intentionally ignores you (like a mute)
  • clients could implement it, if they wanted

Do you see already the contradiction in that argumentation?

If not, I will explain it to you. You can check if you can subscribe a user to a channel (there’s a flag for it in the user details when you ask for it called “you_can_subscribe”). If the user has privacy settings in place that she can’t receive messages from you, the flag is set to false.

Now what happens, if a user has muted you but has her private messages set up in a way that she can receive private messages from all? Well, “you_can_subscribe” is set to true, but she won’t see your message.

Well, if a client implements a check wether you can send someone a private message or not, the client would as I understand it check for “you_can_subscribe”. When the person has appropriate privacy settings in place, the flag is set to false, if not it is to true, wether or not she is muting you. Thus people who intent to ignore you will still seem to ignore you.

And now again my question: Why the hell doesn’t get the sender an error message? As in an error from the API? Clients usually have already something implemented to show you error messages - they are not always look nice, but they can do it. But the check for it, is an extra step that has to be implemented. And since they can only implement it in a way an error message from the API could show it, the API could directly throw the error. That way, when it gets implemented even clients that are not getting updated often (I look at you Netbot) could have this feature immediately. Or am I seeing something wrong here? If yes, please correct me in the comments.

If you see it similar to me, that there should be an error message thrown by the API, please write the app.net-staff.

Best chances are probably to write support@app.net and writing directly to @dalton, @berg and @mthurman. The more who write them, that this is a problem, the better the chances that it gets corrected in the API. After all, it is a network where we are the customers and which thrives not only from good clients and happy developers but also from happy users. And I know already some unhappy users because of this.

Double-Dipping and the DIP

Yesterday the guys from Riposte released an update of one of their clients, which is fairly popular. Originally it cost $5, then went free and now they added an in-app-purchase for $5 for some additional “pro”-features.

Of course there were immediately some people that felt ripped off, it had a bit of bad taste for me but not for long and then there was also at several places a discussion about the Developer Incentive Program (henceforth DIP), too.

What is the DIP?

If you know what the DIP is, just jump to the paragraph after the next one. So, what is the DIP? Each month users of app.net get an e-mail from app.net to rate the usefulness of clients they used. If you are a subscriber to app.net your vote counts, if you are a user of a free tier, your vote is “just” important for the statistics. It was promised if I remember correctly that the developers will get at one point the feedback from those mails, thus the “free vote” is important here as well.

Developers can apply for their clients for the DIP and if they get accepted, any user who uses the client will get asked in the feedback-mail to rate that client. Then there is an unknown algorithm that weights the votes by the kind of API-calls the client does (specialized client or a client that does all you can think of) as far as I understood it and then developers will get a share of $30.000 (subject to change - with more users this amount will rise). That’s the DIP.

Some history

Now some recent history. Netbot got released by Tapbots and cost a certain amount of money. Everybody expected that they will be pretty succesful, since they are famous from their Twitter-client and many people still see app.net as a paid form of Twitter (which it isn’t). After some weeks they made Netbot free because sales dropped with the reasoning that they want to get more users to the platform, their client will help to do that and with more people using Netbot, they will get a bigger share of the DIP.

There was a big uproar in the community, and I have to say that I was also one of the people who didn’t like the move. After all a very popular client that will get guaranteed downloads from Twitter-switchers and it will be hard to get people use other clients. In addition Netbot makes app.net look like Twitter to them because they get the exact same experience as with Tweetbot. Therefore it might even hurt app.net.

But Netbot wasn’t the first client to be free. The first client on iOS for app.net was Rhino and that was free from the beginning. Another popular app.net-client called Rivr was free, too. It just offered an in-app purchase for push notifications. All the other clients cost money. But since they won’t attract users as easy as Netbot, it is in my opinion a bit of a different story.

After Netbot got free, Riposte, a very polished client that cost $5 got free. The reasoning was more or less: Netbot got free, our sales dropped, so we correlate that to Netbots gone free and to have a chance at all, we go free, too and hope for the DIP. Thank you all who paid, with that our push-servers are financed for quite some time.

Other clients went free as well, but none with the fanfare as Riposte (and hAppy went free and when some users complained that Felix still cost money while so many clients are free, Dominik Hauser, the Dev of hAppy began charging again for hAppy).

Double-Dipping?

Now Riposte released an update and added an IAP for $5 with some neat “Pro”-features. Naturally there were users who felt double-dipped. Others got Riposte for free and pay now $5 to get the features and they have paid after all $10 when they wanted the Pro-features. I had a bit of a bad taste in my mouth but then thought, well the first time I paid for it, I put some money in the pool for as all having push notifications with Riposte. That’s ok with me. Would be nicer if I got the features for free, but hey, it is their decision. And for people who use Riposte as their main client, then they probably use it on a daily basis. And $10 for a software I use daily is not a lot of money. Especially I have the feeling that people only feel that they get double-dipped because Riposte went in the meantime free and others get the whole package for $5 instead of $10 and so feel treated unfairly. But to be honest, how should the developers handle it? They can get their client out for free and if you really like the client, you can upgrade it. I don’t see how they could check when you bought the app, a separate app is not good, either etc. So, don’t feel double-dipped. If you don’t like it, don’t pay for it. If you think other clients are more feature-rich than use those. So why oh why all the time whining?

I think Riposte Pro looks interesting but it’s a bit hard to justify for me the payment since I have so many clients. But the features look very interesting. And it is the first time for a long time that a client could convince me to move from Felix for my day to day usage to it.

DIP - Pain or Gain?

But what about the DIP? In the Patter-room German there was a short discussion again about the DIP if it is an incentive for devs or if it hurts the platform, since it prevents further development. And now I have to come back to Netbot and Riposte going free.

One of my two majors in university is political economics (which I already finished) and there we talk a lot about incentives. The aim of an incentive is to steer people in a certain direction. The aim of the DIP, as I understand it is to steer the developers to continue to enhance their clients and try some other concepts as well. Since when they do good, they not only get a lot of usage of their apps, but also get continually money from the DIP. Since app.net determines the weighing regarding the API-usage, they could even steer developers into certain directions to develop certain clients. For example if they would be transparent in how their algorithm works, and they say now: Clients that only do a few specialized API-calls get weighted triple in comparison to a client that tries to do everything, it incentivices developers to develop specialized clients instead of a swiss army knife. If they would say API-calls for showing the stream of a users without any filters will loose some weightening, it could steer developers into a direction to not develop further clients that expose the microblogging-part of app.net.

But all that will only work, when app.net is transparent regarding their weighing. Otherwise it is just a bonus to development.

The next question is, wether only non-free clients should be included in the DIP. After all it seems that there are clients that can make some kind of a living just from the DIP. And since they are free, they have a bigger chance of broadening their usage and therefore broadening their share from the DIP. In addition they drive the prices down for other developers, since people will expect that clients are free or at least very very cheap (as in not more than 1 or 2 bucks).

I can understand that reasoning but at the same time those clients loose out on sales. When the free tier got released, I really wondered how much money Netbot could have made, if it wouldn’t have been free. Loads of the newcomers went probably straight to Netbot and would have gone there also if it wouldn’t have been free.

In addition it makes things really complicated. What do you do with clients that do some kind of promotion and go free for a day? Should they be removed from the DIP forever? What about clients that cost only $1 instead of 5? It would make the whole concept so complicated that no one could really handle it. So, I think free clients should be in the DIP as well.

Does it hinder clients from getting developed further? Well, there is the case of Netbot, which is a clone of Tweetbot with some small updates and which doesn’t get a love for some time now. It is still pretty popular. So, they might still get money from the DIP. But as long as income is not high enough to justify further development, it is a move I can fully understand from Tapbots to just let it sit there. Why should they put in more development time, if it is just too expensive because income is so low? I don’t say that I like it, but I can understand them. And the longer Netbot doesn’t get updated, the more users will search for alternatives. And over time the DIP-share will decrease. And at some point Tapbots will make their mind up wether there is enough money in the app.net-client-market or not. And it doesn’t cost them any money to have Netbot sitting there in the AppStore.

So usually you get money from your sales and with app.net you get a bonus because of the DIP. The better your client, the more money you get. And since the number of users for app.net is relatively small, it is not a lot of money you can get from sales. We have now ca. 90k users. Let’s say all use iOS and buy a client for $5 from the AppStore. Then it is $450.000 what you would make. That is actually not a lot, when I think about what it means to work full-time on a client. So the DIP adds the extra that could mean that your succesful client in the small market gets further developed, even so sales will be low because of the market size. If a government would do it, we would call it a subsidy. The effect of subsidies is that they distort the market. In terms of app.net this means that it distort the market in a way that clients get developed or continued to be developed, that wouldn’t have been developed in the first place or would stopped being developed because feeding your family is actually more important and so you would rather work on another project.

In addition it works as a signal (yep, signalling-theory is nice, too ;)) for developers that app.net cares about developers. They do not pay them to develop for their platform. That would send another signal. Microsoft is doing that as far as I know for Windows Phone. That signal would say, hey, we need desperately clients, so we pay you for doing it.

No, they give you a bonus, an incentive to develop for the platform. You still have to make something on your own that is succesful to get your share of the pie. It shows that they care enough to give out some of the subscription money to the developers. And this is probably far more cost-effective than paying directly.

Henceforth I guess in terms of signalling it is a very good thing that it exists. So it might also be called the Developers Signalling Program. But if they would make the weighing of the algorithm public, it could also be a powerful mechanism to steer development of certain types of clients. But my gut feeling tells me that people wouldn’t like it, when app.net started to directly influence which type of clients people develop with the DIP. So they are probably better off in not doing it in a transparent way.

Short reviews of app.net-clients

Today I created a bunch of app.net posts for short reviews of app.net-clients. All reviews have a max size of 256-characters. I hope you enjoy them. You can find a client that suites your needs on ADNCC which enables you to select features and operating systems to give you all clients that match the selected values.

Now for some short reviews for several clients. FYI the clients on my homescreen are Felix, hAppy, Patter and Sprinter. Have a look at http://adncc.nigma.de by @chemiker based on the client feature matrix by me to find a client that suites your needs.

Alphred: A workflow for Alfred2, the popular launcher on OS X. It allows to send a post or a pm right from Alfred incl. link entities. One of my favorite ways to do a post or reply to a private message from my main account.

Chapper: The only client I use on Win7. Support for Patter included. Feels cramped but in an upcoming update is theming support which enables me to set it up in a comfortable way. Good,could be better, previews from the upcoming update look very promising.

Chimp: Feature-rich, even with support for public Patter-rooms and it has push. An interesting UI-concept, which you might know from Path. Lots of information on the posts & can feel a bit cramped. Feels a bit slow. Nice client with a lot of potential.

Climber: The point & take a short video of app.net. 11 seconds have to be enough. Clean and fast interface, also support for the Places-API to set your location. Don’t forget to set the #Climber-hashtag.

Felix: Feature-rich and a good experience with a full-screen mode. Now also with support for multiple accounts and a dark theme. Has a clever implementation of link entities. To top it off it gets all the time updates. I use it all the time.

hAppy: Probably the feature-richest client. Sadly no push. Multiple account-support, link entities, a dark theme and the best client when your connection is slow. Also Complete Patter-support. Could I install only 1 client on my iPhone, this would be it.

Kiwi: A good client for Mac OS X. The only OS X-client with support for private messages. Regrettably no support for link entities or multiple accounts. My main client on OS X.

Netbot (iPhone / iPad): Feature-rich and some clever ideas, especially its support for “repost from” when you want to repost a post from another account. There’s also a good search. It has push, but not for PMs. Looks exactly like Tweetbot. For experiencing app.net like Twitter that might be the client of you choice.

Patter: The cleanest experience for chatting in Patter-channels. It supports PM and all features of Patter, incl. broadcasting. Otherwise features are missing like push or copying URLs etc but those are in development. Just for chatting it is great.

Riposte: A clean interface, with a good UI streamlined to be used with only one hand. Push, multiple accounts, dark theme, pictures are shown completely inline and it is really fast. Regrettably it has no support for link entities. But it is free.

Sail: A client that allows me to send a post fast on OS X with link entities to any of my accounts. Just a window, write a post, select your account, send. That’s it. Clean and quick.

Screenfeeder: Have several social feeds? Having your iPhone or iPad lying next to you or somewhere very present? Screenfeeder will show those feeds post by post to you. Your own neatly designed app.net-wall so to say.

Spoonbill: One of the first clients for the iPhone. The only client that supports an alternative but real threading-view for threads. Just for that it is worth a look. Featurewise there is not so much to say and feels a bit overdesigned.

Sprinter: The point & shoot of app.net. Open the app, make a photo, apply a filter, write your post, don’t forget to add the #Sprinter-hashtag, add a location based on the Places-API and send it out. Clean & fast. But it feels like something is missing.

Stream: Stream is clean and looks very polished, reminds me a bit on the old Tweetie for the iPhone. It has push, no link entities, no support for private messages. Needs to work on its features and could become a very good client.

Wedge: A good client for OS X that I use for my secondary account. Unfortunately no private messages but a nice interactions-view. Sadly it seems that it is not in development anymore. It was the first real good client for OS X.

OmniFocus and Things: A comparison

tl;dr

Things for design and and an ultrafast sync but you have to follow a certain way to be able to work with it and it can clutter up fast. OmniFocus for flexibility and when you have more than a dozen active projects but it’s not as nice looking.

Introduction

This text shall be about OmniFocus and Things. It is not definitive and I probably miss features since I will write here as objective as possible how those two Mac-applications and their iPhone-counterparts present themself to me and to my workflow.

I guess the best is to tell you where I come from. In 2005 I got introduced by a colleague to GTD (“Since I am using it, my desk is always tidied up and I always have backup batteries for my Bluetooth mouse”). He lent me the book, I read it and I was sold.

I started with a modified moleskine (something like this), used a Hipster PDA but was never really happy with the solutions. On my Mac I tried iGTD, kGTD (the precursor to OmniFocus, essentially a pimped OmniOutliner-document) and some other stuff. When Things became public I used it happily and when they released the iPhone-version I was in heaven. I had a look or two at OmniFocus (henceforth OF) when it got released but it looked always ugly and far too complex.

So I used Things and was always happy but I got unhappier. The always promised over-the-air sync (henceforth OTA-sync) didn’t get released, the updates were slow and stuff like the tagging-UI on the iPhone drove me nuts. So I had again a look around and suddenly OF didn’t look that bad anymore and I bought with it over two years ago the iPhone-app, too. I also bought an ebook about it and read loads if articles because I wanted to get the most out of it.

So after approximately three years I switched from Things completely to OmniFocus. Now it is two years later and because of the looks of Things I was still interested in it and recently I decided to give it another chance.

And what I found I will write up here.

Mapping features

There are some features which are similar in both apps but different enough that I have to explain them here to make the rest of the article easier to understand.

Contexts vs Tags

Things uses tags, OmniFocus uses contexts. When you know GTD, you know that a task should usually be associated with a project and a context. A project is something you try to achieve (clean up the garage, publish a podcast etc) what needs several steps. The single steps of a project are the tasks. A context is depending on definition a location (home, work, at the computer, at the phone) or state you are in (highly focused, zombie). In OmniFocus you can only add one context per task. You can have them divided like Errands and then a ton of subcontexts like the supermarkets but that’s it. One context per task, as it is written in the book. In addition you can add a duration, and a flag to a task.

Things on the other hand has tags. Therefore you can add unlimited tags to a task and use it for durations, priorities etc. tags can also be hierarchical like the contexts on OF, two levels, that’s it.

I will write more about the weaknesses and advantages of both later.

Start Dates vs Scheduling a Task

In OF you can set a start date for a task. That means that the task will be marked as inactive until it reaches it start date.

In Things you can schedule a task which means that it will be marked as scheduled (kinda like inactive) and it turns up in a daily review sheet when it reaches the date and then you can decide what to do with it. The two main options are “show in today” (a view for tasks in Things for tasks which are due, overdue and you decided on todo today) and later (reschedule it) but you can also modify the task in any way you like.

For the purpose of this articles when I speak about start dates I mean in terms of Things the scheduling of a task.

Inactive vs Someday

In OF you can set a context (all tasks with that context are inactive), task or project to inactive. Depending on your filters it won’t show up then. There is a similar feature in Things which is called Someday. You can place a project or a task there and it will be removed from the side bar and the projects view on the iPhone and will turn up only when you switch to the Someday-view.

When I talk about setting something inactive I mean in terms of Things that I move it to someday.

The Design

Things looks better. No doubt about that. The desktop-app and the iPhone-app are well designed in terms of looks. OmniFocus on the Mac has support for themes and there is a plethora available and I even use custom icons from Icons & Coffee but nothing gets OmniFocus to look as polished as Things. On the iPhone it is not even themeable. But at least the OmniGroup gave it nicer looking icons on the Mac and on the iPhone which is at least something. The OF2 α looks better than OF1 but it still is not at the level of Things. Looks are important for me because I want to look at nice things when I use something all the time.

Entering Tasks

Both applications on the Mac have quick input windows which work fine and have auto-completions. There are workflows for Alfred for both which work fine. The only difference is that I can’t add a start date in Things but I can do so in OmniFocus.

On the iPhone both apps have a universally available button for pulling up the “enter a task-sheet”.

But they differ in some ways and here the way both apps work start to diverge.

OmniFocus

When OmniFocus does a “cold” start aka wasn’t in the background, it always optimizes the database. When your database has a certain size, this can take up to a minute in my experience. Since I am archiving my tasks on a regular basis it’s often a max. of a view seconds. Anyway in this time the sheet misses the ability to put in a project or task. So, that can be annoying.

If OmniFocus was in the background you can do everything incl. making recurring tasks and it even lets you attach a photo or an audio-recording. The only thing missing is a way to add a duration.

When entering a project or a context, a new view is pulled up that lists all projects or all contexts and you get a fuzzy search that searches while you type. I usually only need to type in a few letters and it is filtered down to a point where I see what I search.

Maildrop

When you use the Omni Sync Server as a way to sync your todos OTA (you can also use your own WebDAV-server), you can use the OmniFocus Mail Drop (which you find in your sync server account page). This means that you get a mail-address and when you send something to this mail address it gets added to your inbox when you sync the next time. The subject becomes the task, the body a note of the task.

I use this often when I am on my phone and find some interesting piece of software or video which I want to have a look at, when I am on my Mac. And app.net-, twitter- and RSS-clients and browsers on iOS have usually an easy way to share something via e-mail. It’s really fast. And as I noticed it is kind of a dealbreaker when I have a look at other todo-apps.

Things

In Things on the iPhone I can add a task, set a due date and project it belongs to, add tags and a note and schedule it. No way to make it a repeating task, add a photo or audio recording.

In addition for adding details to a task (like tags, note, due date) you have to do an extra tap to open the details. It feels like they discourage entering those details when you are entering a task. It might feel a bit cleaner than with OF but it also discourages you to think about it already when you are putting it in the first place imho. When you have a task in the inbox and get its details-view, you can move it but need to push the edit-button to add tags for example. One more thing thatched me think that CulturedCode (henceforth CC) discourages you to use those. When I used Things a lot I often didn’t enter tags on the iPhone, one reason was that it is hidden until you actively want to use them.

When I started to use OF I suddenly started to actively use contexts because it was right in front of me and I thought about where I actually have to do this. And therefore I could filter for it easily later.

The next problem with Things is that tags and projects are list views without a search. You can reorder them (and have to do so manually) to have the most used tags on top but I wouldn’t enter sub-tags of Errands for several supermarkets for example because it clutters up the list and I need ages to find what I search. And remember you also do priorities and durations with tags. But that’s missing one of the big advantages of tags: I can apply multiple of them to one task in contrast to OF. But I wouldn’t add a lot because it clutters up the list. It’s not a problem on the Mac though because there tags auto-complete when you add them to a task.

The same problem have projects. When you have more than let’s say 15 projects it becomes a hassle to get to the correct one. This will be a problem in the next section of this article, too.

Folders, Areas of Responsibilities and Projects

In both applications you have projects and they work similar. They group tasks (OF bad even the ability to enter sub-tasks to a task but I did not yet find a real use case for me). In both cases they can have notes, start and due dates, can be repeated and scheduled.

The first important thing to note is that projects in Things cannot contain recurring tasks. CC says that projects are something definite that is not ongoing and thus they shouldn’t have recurring tasks. They probably never had a project which took up only a short while like a few weeks where you had to do a specific task every day of the project.

But in Things you have Areas of Responsibility. You can group there projects and recurring tasks. So for big projects the best thing would be to create an Area of Responsibility and add there the smaller projects that are part if the big one and recurring tasks which belong to the big project. But I wouldn’t want to create an Area for a small project.

In OmniFocus you have folders to organize your projects. I use them like Areas in Things and have folders like “home”, “work”, “university”, “administration” etc.

One big difference is that tasks in Things can actually have no project associated with them, while in OF it always has to have project. My “project-less” tasks are in a project called “Misc”. When I moved from Things to OF I had to get accustomed to this and when I tried Things again I had to get accustomed to the fact that tasks do not need a project and therefore the project Misc. is not necessary. Btw. most of my repeating tasks live there. So it is actually a minor annoyance that Things doesn’t allow repeating tasks in a project. But it will be one of the pieces of my conclusion.

There are two more differences regarding projects and their organization.

Parallel and Sequential Projects

In OF projects can be parallel or sequential. In a parallel project you can do the task in any order you like, the top most is the “next task” though (important for filters), while in sequential projects only the top most task is the next one.

I have for example projects when I have get a bill from the doc with the following tasks: write the letter for the insurance, put in an envelope and write the address on it, bring it to the post office, wait for the money on the bank account (due a three days before the bill is due), transfer the money. The waiting for-task is an inactive task (like all my tasks with the waiting for-context) because I won’t do anything until I get the money or I really have to transfer the money. So all tasks after that are inactive as well which is good for filters when I want to see only active tasks. But when the inactive task becomes due it will turn up anyway in my due tasks.

In Things however there are only parallel projects in terms of OF. Which can be quite annoying. To explain that I have to explain a view in Things. I will get into more detail about views later.

There is a view in Things called Next. In there are all tasks listed that are not in someday, ordered by project and at the bottom are all scheduled tasks (except on the iPhone where a scheduled repeating project is listed with the other projects but I guess that’s a bug). Now I have my project with the bill from the doc. Guess what, the task after the waiting for task is listed there, as well as the project itself. Even so there is no task that is actually active right now. So it just clutters up the next view.

I thought for a long time that sequential projects are not necessary but when they help to filter stuff and get an overview they are quite some help. I already had also the case where I had a parallel project and suddenly couldn’t continue until I got an e-mail from someone. So I added a waiting for-task, made the project sequential and all tasks became inactive and some perspectives (the term for special view in OF) became cleaned up.

At last there is the side bar. Both applications, OF and Things have a sidebar where they list projects and in the case of Things some special views (Today, Next, Someday, Schedule - but more about that later). Things doesn’t have folders but the aforementioned Areas of Responsibilities.

In OF I Put my tasks into projects and most projects into folders. And I can fold the folders and the projects are removed out of the view. I see only the folder.

In Things there are no folders. So the more projects you have, the more projects you see in that sidebar. Putting a project into an Area doesn’t allow you to remove it from the sidebar. Clicking on an Area just shows you all projects and tasks associated with it. If you have a lot of projects, at some point eve. The areas get out of the sidebar and you have to scroll. More clutter. It works fine when you have only a few but I tend to have rather more than view because I have projects for each podcast-episode (that’s two), big blog entries that need research, several projects for my master thesis, upcoming birthdays of friends and relatives, home projects, administrative projects and so on. If you think a bit about it, you can get really fast to a lot of projects. And it is easy to clean your views up in OF, in Things it is not possible.

Templates

Both applications don’t allow template-projects but I will shortly describe what my solution to the problem is.

Templates in OF

I have a folder Templates and in there a couple of inactive projects (one for tidying up the apartment, one for paying a doctors bill, one for a new podcast-episode etc). Usually they are done like “Doctors bill [date of bill]” or “Retrozirkel [episode name]” (the podcast I am part of). When it’s time, I duplicate it, make it active, change the part of the name in the brackets and move it into the according folder. Afterwards I add due dates to the project and the tasks if necessary.

Templates in Things

In Things I have the templates stored in Someday and tagged them with “template”. The rest is the same as in OF, I just remove additionally the word template of course and move it to the according Area.

I like the folder a bit more because I can fold it up and don’t have them clutter up the someday list. But since I do not have that many templates, it is not really a problem in Things. But I can see that it might be really annoying for a power user of templates.

Contexts and Tags

I wrote already in the introduction and in the part about entering tasks about contexts and tags. Here I want to discuss how they actually work out.

To freshen up your memory, contexts in GTD are some kind of location where a task can happen. The word location is pretty broad like “home” or “phone”. There are new ideas out there that move contexts from location to something like state of mind since many people can do their work everywhere. Nowadays you are pretty much all the time online, so why have an online-context? And you carry your phone all the time with you, so why a phone-context. And our phones can do most of the stuff our computers can do, so a computer-context becomes redundant, too. Therefore you can come up with contexts like “focus” or “zombie” (you know, right after waking up and before your first coffee). But I think you get now the idea.

Contexts

OmniFocus uses contexts which can be hierarchically in two levels. I have as written before a context called Errands and sub-contexts of supermarkets and other shops. Or I have a library-context and several sub-contexts which bear the name of the library. In OmniFocus I can go now to the contexts-view and select “Errands” and it will me show all errands. When I select “Errands/Postal office” it will show me all those. In a search for Errands all tasks within the current view that belong to the context or one of its subcontexts.

Unfortunately OmniFocus doesn’t allow multiple contexts. Why multiple contexts you might wonder. When I do research it is not uncommon that I find books that are available in several libraries and not only in one. So I would like to create a task that says “get book so and so” and add all libraries in which it is available as a context (and add the signatures in the notes-field). That is not possible with OmniFocus.

There are ideas to add tags to OmniFocus for something like this via the notes-field but it is just a work around and nothing more. Regrettably it doesn’t seem that OmniFocus 2 will add tags, judging from the current Alpha.

Tags

Things uses tags which can be organized hierarchically like the contexts in OmniFocus. Unlimited metadata \o/

But it doesn’t work as well, as one would think. And my latest mail-exchange with a support-guy from CC doesn’t let me think that this will change. Anyway, why doesn’t work it that well?

On the one hand there is the input-problematic on the iPhone. I at least enter a lot of tasks into the iPhone-version because when something comes into my mind, I put it into my iPhone. The trusted inbox, you know. But there it’s this extra tap and the bad UI I described above that I do not really want to enter tags there.

On the other hand there is the problem is a matter of the hierarchical tags. Let’s say I add to a task the two tags: “Central” and “State” which are both sub-tags of “library”. In the UI of Things it will show me the tag “library” with a hint that there are sub-tags and then I can open them specifically and filter for those. Or I click on “library” and it will filter it correctly. But when I search for library, it won’t show me tasks that have only a sub-tag of library.

And both in combination don’t really let me use tags in Things, even so they should be superior to the contexts of OmniFocus.

Search

Both apps have a search. But it works quite differently. Even so I usually start with the OmniFocus-part, I will this time start with Things. Things' search is great. On the Mac it is always in the lower right and it always searches all projects etc, independent from the view you are in. Results come up while you are typing and are ordered by Inbox, Next, Scheduled, Logged and Trash and you can filter the search-results by tag. On the iPhone it is available on the first screen of the application with, you just have to scroll up and is a universal search, too. When you start typing it shows an extra bar that says “Title”, “Notes”, “Tags”, “All” for doing a bit of filtering. As written above there seems to be a bug though with scheduled repeated projects on the iPhone. The only thing that bothers me is the tag-search I described in the previous section

On OmniFocus search is available universally as well but it only searches your current view. Therefore when you are in the Inbox and you start searching, it will show you only results from the Inbox. You have to go to a view that shows you all task to search over all tasks. I never understood that. Usually when I search, I don’t want to filter first and then search but want to search and maybe filter when I can’t find it.

On the iPhone there is an extra search-view which searches everywhere but it is not search as you type and it doesn’t search for contexts. So it is far inferior to the search in Things.

But the way both apps are constructed lead at least for me to the following: Since I usually give every task a context and a project in OmniFocus everything is well ordered and because of the weaknesses of the search, I rarely use the search but still find everything very fast because I usually know to which project a task belongs and it every phone call that I have to make is in the context phone.

In Things the search is so good that I really like to search but because of it can’t find the parent tag of a sub-tag it has kind of a bad taste for me. In addition I do not have everything as well sorted since it doesn’t really encourage you like OF to give everything a project and a tag.

Due Dates and Times

The next thing I want to write about are Due Dates. I am not sure anymore if the book Getting Things Done mentions due dates. Tasks shouldn’t have one if possible. Because usually stuff with a specific time or date is an appointment and not a task, thus it should be in your calendar and not in your todo-list.

OmniFocus has due dates and times. It defaults to a day at 7 pm. You can change the time though. The task will turn orange (and an icon badge will appear) when the task is due soon which is a time period set in the preferences between 24 hours and 7 days.

When a task becomes due and therefore overdue you get a notification and it will turn red, as will the icon badge.

In my experience the icon badge on the iPhone will only turn up for due soon tasks, when you open the app while a task is due soon. So not opening the app will only give you a notification when the task is due and then add the badge.

Things allows only due dates. When a task is due it will turn up in your daily review and the iPhone will remind you that there are due tasks at a set time (like 8 am in the morning). But you can’t give tasks a due time. Hence you have to rely on another app for that, like the built-in app Reminders or the great app Due.

I have to say that I don’t like that I have to have two apps for that. I often create tasks like “phone person x” and set a due date some time today. So I see it all the time at the badge that there is something to do but I will get an additional reminder at a certain point of time. In Things I have to create that task and do it a second time in Due. Or leave it out of Things (and therefore don’t have it in the project and logged that I did it, when I did it) and have it only in one app. Sure it’s kind of a first world problem but it annoys me. And to be honest being able to decide between OmniFocus and Things is a first world thing, too.

And CC mentioned several times that they won’t change it because a task shouldn’t have a due time. But it is something I could live with, it is just inconvenient.

Reviews

You should review your projects and tasks in a regular interval. The idea is that you do not loose oversight and you think about what might need an update (additional tasks or cross off tasks that are done or not necessary anymore). There are people who do it daily, I do it weekly on the weekend. When I have really a lot to do I do it daily.

OmniFocus supports you in doing reviews. You can determine a time how often a project should be reviewed (n days, weeks, months, years) and when you hit the Review-button, you will be presented with a list of projects and the tasks they contain which are up for review. You go through them and can mark them for review.

I have a repeating project for my weekly and monthly review. The weekly review contains not only stuff like “review projects” but also tasks like review previous and upcoming calendar data. The monthly review contains tasks that I have to do monthly like set up your budget or do a backup of you website.

OmniFocus 2 will have a new review-view which is apparently taken from the iPad-version (which seems to be awesome from what I’ve read). From what I’ve seen so far I like it but since it’s in its early stages I cannot say a lot about it now.

Things, like most To-Do-apps doesn’t support reviews at all. It has a daily review which will show you in your Today-view all tasks that are due today or are scheduled for today but that’s it. I have my weekly review-project. But it means that I always have to review all projects because keeping track of what when to review is cumbersome. It doesn’t matter when you only have ten projects, but with many projects it is not feasible imho.

Perspectives and Views

Things offers several views. Inbox, Today, Next, Scheduled, Someday, Projects, all Active Projects, all Areas, the Logbook and the Trash.

The Inbox is the inbox. Quick Entry defaults to the Inbox and the way the Entry-sheet is designed on the iPhone tasks put in there usually land here, too. Today is a view where you see all overdue and due-tasks and tasks you decided you want to do today. Next is a list of all active tasks and projects, Scheduled shows you scheduled and repeating tasks and is the only view were you can create repeating tasks (remember they can’t belong to a project), Projects shows you all Projects sorted by Areas of Responsibility, a click on a project shows you all tasks in it, a click on a single Area shows you all projects and scheduled tasks in it. The Logbook all logged tasks and the Trash all tasks which are in the Trash. That’s it. When I used Things a lot I lived basically in the Today-view. In the morning I looked through the next-list, selected all tasks I wanted to do today and from then on it was usually the today-view or maybe a project I was working on. When the Today-view was empty I got me new tasks from the Next-view. And there was a big maybe that I filtered the Next-view for tags (because, well I said enough about tag-entry on the iPhone, didn’t I?).

Let’s talk about Perspectives in OmniFocus. Or better not, I will give here only a brief abstract about them. Perspectives are one, if not the most powerful feature in OmniFocus. Merlin Mann did a 56 minute talk about them, if you are really interested.

Perspectives allow you to create any view on your projects and tasks you want. I have for example a today-view which has no side-bar, and shows only the tasks that are flagged, overdue and due today. Or there is the predefined context-view that shows you in the sidebar all contexts. And clicking on them will give you a list of tasks. Or you could create an inbox-view that shows you only the inbox and nothing else, not even the toolbar. You can essentially setup your window a way you want it, take a snapshot and when you want that presentation of tasks and projects you choose the perspective.

Perspectives can only be created on the Mac but can be synced to the iPhone. Because of perspectives you can essentially emulate any view of Things in OmniFocus and make it as clean or as cluttered as you want.

OTA-Sync

I want to talk only about the over-the-air-sync here. Things didn’t have it for a long time but has it now. And howly mowly it is damn fast. You can type a task on your iPhone or Mac and see it turn up on the other side more or less instantaneously. But you have to rely on CC for it because you have to use their infrastructure (for free).

The sync of OmniFocus can be fast and pretty slow. It is never as fast as the sync from Things or at least doesn’t appear as fast. When you want to keep it fast, you should archive your tasks on a monthly basis (one of the tasks in the monthly review project) and sync all your clients on a regular basis. Yeah, that one rarely used laptop can make a difference.

But if you want to use your own infrastructure, you can sync with a WebDAV-server of your choice and do not have to rely on Omnis sync server. But if you use Omnis sync server you can use the above mentioned Mail Drop which is ingenious in my opinion.

But the sync of Things is really neat. Rome wasn’t built in a day, too.

Conclusion

Now coming to an end with this big comparison. And you probably can guess that I will keep using OmniFocus. It is very flexible and powerful. But as I have written in the introduction I read (most of) a book and a lot of articles about it. It has a steep learning curve. And you really should have read Getting Things Done by David Allen when you want to use OmniFocus. But while it is heftily invested in GTD it doesn’t take the book word by word (but with contexts unfortunately) and seems to see it more as a guideline. Henceforth it allows you to model things to your way to get things done.

Things on the other hand is clean and easy to use from the get go. It hides stuff like tags and therefore looks clean. If you have more than 20 projects it becomes fast unclean and cluttered.

I always have the feeling the people from CulturedCode have a specific way to do Getting Things Done and if you want to strife from that way, you have a problem and need workarounds or can’t do it all. I do not even understand their reasoning. They say that tasks shouldn’t have a due time but at the same moment they allow tags (which aren’t “pure GTD”).

If good looks and a really fast sync are important to you and you do not have a lot of projects and don’t care about having a second app running for your tasks, then Things is probably the way to go.

If you want flexibility in the way you deal with your todos and projects and even be able to work in phases when you have a lot of projects on hand, then OmniFocus is the way to go in my opinion.