What's Eating OmniFocus, Part Two

Note: this is Part Two of a two part series on the problems in OmniFocus. This is the part where I get to show what I've been working on for weeks: mock-ups of how the suggestions I made in Part One could actually be implemented.


I'll make this quick so you can get to the mock-ups. I mentioned this at the end of Part One (you' be forgiven for not having made it all the way through):

Absent concrete ways of integrating these ideas into the application, they really aren't worth the bits they're painted on.

I really believe that. It's so easy to be an armchair design critic; when you have nothing at stake, don't have to worry about implementation, can ignore things that don't fit into your grand design vision, you can suggest anything with impunity.

I wanted to put something on the line, so I took on the task of showing exactly what my ideas for OmniFocus would look like. I used the iPhone version as the muse for this redesign as I feel that it is where the most work needs to be done.

I'd love it if you go visit the dedicated page for my redesign concept. I left no stone unturned — you'll find more than 70 mock-up screenshots, plus a pile of explanations for the decisions I've made. If you just want the screenshots, you can grab them here.

Hope you enjoy it!

What's Eating OmniFocus, Part One

Note: this is Part One of a two part series on me, complaining about practically every part of OmniFocus and how I would change it. So, if you don't like OmniFocus, or don't know what OmniFocus is, this probably isn't for you. Part Two, where I actually present concrete ideas on how to solve some of the problems in OmniFocus, is also posted, and is best viewed after reading through the textual marathon below.


I love OmniFocus. It may seem extreme to profess such emotions for a piece of software, but when the shoe fits it is indeed best to wear it. OmniFocus has helped me do incredible things, things I honestly don't think I could have done without the help of this piece of software. Now, after such a compliment, it's no surprise that I’m about to say, “but...”, and enter into the middle layer of the classic “shit sandwich” (compliment, criticism, compliment; you know the drill). And yes, you'd be quite right. But I need to make sure that the above is stated clearly and repeatedly: I criticize because I love. Really.


If I were to summarize my concerns about OmniFocus, I would say this: OmniFocus's roots are in OmniOutliner and, unfortunately, I think that heritage continues to shine through in a decidedly unpleasant way. OmniFocus, while it is an incredibly powerful piece of software, still feels like a database in many ways. A perfect piece of software shouldn't have its implementation in any way apparent to the user; the constraints and foibles of the underlying technology should be abstracted away until the software feels almost human. For all that is great about OmniFocus, I still, from time to time, feel like I am entering records into a Microsoft Access database. That feeling leaves an unpleasant taste in my mouth and, in doing so, commits the cardinal sin of a productivity tool: it creates friction and reduces my desire to continue using it. There are, of course, many other areas where OmniFocus is far from perfect (and even more where it is fantastic, but I digress), but I think most of the issues spring from this same well.

In breaking down what I think is wrong with OmniFocus, I'll look at two key areas: the model (what the application can do for you) and the interface/ interaction design (how those abilities are presented to the user). I'll be flipping between the different versions of OmniFocus in my critiques, but most will apply to the Mac, iPhone, and iPad versions equally.

Model

Dates

OmniFocus does an incredible job of modeling a certain style of thinking: the concepts of next actions, project groups, sequential and parallel projects, and folders combine to provide a rational, goal-oriented tool for completing tasks. However, dates are one of two areas (the other being context) where I feel the Omni Group has missed the mark and where makeshift solutions from the OmniFocus community have been leaned on for far too long.

In OmniFocus, two dates can be assigned to a task or project: a start date and a due date. Due dates are clear in purpose (though some still abuse them as a result of the same issue I'm about to detail): if something has to be done by a certain date, that is the date it is due. Start dates, however, are far more ambiguous; if not in their purpose, at least in their typical usage. I believe their name implies that they are the first time that a task becomes available; for example, you can only start working on your taxes on January 1st.1

What start dates have often been co-opted into, though, is a role for which they are just as ill suited as due dates: planning. If you want a particular task to surface on a particular day, what do you do? For many, this involves setting the start date (and, if you are like me, a flagged status as well). But if you set the start date in the future, the task will no longer appear as “available”, meaning you will never be aware that they are, technically, available for you should you go through your OmniFocus lists looking for something productive to do. This situation happens to me so often, and my frustration of having to set the start date and flagged status for scheduling tasks is so pointed, that I think the single most important change in OmniFocus would be the addition of a third date: the Target/Planned date. It's an additional layer of complexity, but it would be worth it to allow tasks to be scheduled without removing your ability to happen upon and complete them prior to when you had originally planned to do so. It would also be a better fit for a more robust Forecast view, as OmniFocus could display everything that comes due alongside everything you've planned to do on a given day, similar to how Things' “Today” view works.

In addition to this major change in the way dates are captured, I'd like to see these changes to dates to address some other nagging issues/ desires:

  • Setting dates relative to the date of the previous task. For example, setting the target date of a task to follow up with a coworker to be exactly one week after you completed the previous task of emailing her your question.

  • Smarter handling of repeated projects and tasks. I often have a repeating item that, for one reason or another, I do not want to do/ is not applicable for a period of time. Currently, you can either delete the project, change the start dates (which may not be possible, depending on the project), or “fake complete” the task. I would prefer some sort of “muffle” option, as it feels more honest than any of the available options.

Contexts

Contexts are a funny thing in OmniFocus. Where the rest of the OmniFocus model is incredibly flexible (projects can be as complex as you need them to be, notes can be anything you'd like, you can create new hierarchical levels of nested folders to your hearts content, and so on), contexts are frustratingly limited. A task can have a single context, and no more.

In another way, though, contexts actually are flexible: they have no defined meaning, so you can set them up to be anything you'd like. Traditional contexts like Mac, Home, and Office are the defaults (and, in fact, are still my personal preference), but there has been a lot of experimentation; no contexts, energy-based contexts, priority-based contexts, and more have been floating around the OmniFocus community without much traction. It seems as though we, the OmniFocus community, aren't really sure how they should be used. Therein lies the problem: uncertainty breeds fiddliness, particularly amongst the kinds of people who would be attracted to OmniFocus in the first place. And, as we all know, fiddliness is far from conducive to productivity.

So, yes, contexts are a tricky problem. Based on what I have seen, I think the way to go with contexts is to make them even more flexible, and to watch the way customers use contexts for patterns that can be given special treatment.

The flexibility part can come in only one way: tags. I'll be the first to say that tags are not my favorite choice for organizing digital miscellanea, but for the variability demanded by something like OmniFocus's tagging system, they fit the bill quite nicely. Here are a few examples where tags could help:

  • You have three devices, an iPhone, an iPad, and a Mac. You can accomplish certain tasks using some subset of those devices; for example, you can only make calls on the phone, you can do your weekly OmniFocus review on the Mac or iPad, and you can take screenshots for a post on iOS 7 only on the iPhone or iPad. Using tags, you need only three contexts, which you mix and match as you please. Using one-context-only, as is the current implementation in OmniFocus, you need eight contexts to cover every alternative.

  • You deal with a certain person a lot, so you give them an “agenda” context. However, you also have to wait for them to get back to you on something, so you set up a “wait” context for them. When you meet them, you have to look at two different places to get a full picture of your GTD-related interactions with them; using a tag for “agenda”, a tag for “waiting”, and a tag for the person would allow you to look at just that person's tag and see both what you want to talk to them about and what you're waiting for from them.

With Apple's adoption of tags in OS X 10.9, it feels like the right time for OmniFocus to join the crowd and kick the one-to-one context system to the curb. OmniFocus contexts feel, more than almost anything else, like a limitation imposed by a database; while I am not familiar enough with database systems to say for sure, I imagine it is far easier for a task to have a single context than to have an arbitrary array of tags. However, like I said up front, those kinds of challenges should be abstracted away to create a system that conforms to what users are looking for

The more important part, though, is actually an area where the Omni Group has done quite well, but in which I would like to see even more progress: making common types of contexts “smarter”. Location contexts, particularly on the iPhone, are a tremendously useful addition. I hope that this continues in the future: things like contact-based contexts would be wonderful, and would fit the way many people use their contexts set up. These kinds of “smart” contexts could take the place of time and energy fields in OmniFocus, which have also been a decidedly half-hearted affair.

Keep paving those cow paths so that common context types are given more brains that let you complete tasks more efficiently than a vanilla context would have ever allowed for.

Notes

And we've arrived at my most disliked of all OmniFocus features: notes. While not as important as changes that should be made to dates and contexts, notes are so unpleasant to use that I refuse to use them except as storage areas for AppleScript-related information. Why do I find them so lackluster, you might ask? Actually, I don't think you are asking that, because it should be apparent to anyone whose spent more than a nominal amount of time using the software. Here are my main complaints:

  • Rich text is gross.

  • Did I mention that rich text is gross? I should mention it again.

  • Not only is rich text gross, but it is only supported on the Mac. Go to iOS and it becomes (far more palatable) plain text. This seems like another holdover from the days of when OmniFocus merely a GTD-ified version of OmniOutliner.

  • Attaching files to notes is a frustrating, inconsistent experience. You can embed files or create symbolic links to them on the Mac (what's the chance that any non-expert user understands the difference?) which, of course, won't work on the iOS versions. You can attach images and voice recordings on the iOS versions, but doing so takes place not in the note view, but somewhere else entirely.

Step 1 is to address the first three items above: get rid of rich text. Rich text is bad for compatibility and gives users just enough rope to hang themselves. I would say that Markdown for the notes field on both the Mac and iOS would be a good choice; novice users will just get rich text, and more technically-savvy users get a format that many prefer to use anyways.

The mismatch of attachments is really the most frustrating part, though. I would suggest that photos and voice recordings, the main types of attachments you might create on iOS devices, should be the only content that can be embedded in notes, and that these should be presented in a unified way with the text-based notes. As I'll mention more below, I think that the existing options of linking files to notes on the Mac should be replaced with a more prescriptive feature that works across all three platforms. Specifically, I would like special links to Dropbox files/ folders that would open in the file system when possible (the Mac) or the Dropbox app when necessary (on iOS).

Projects

Projects in OmniFocus are about as well implemented as I could hope for. OmniFocus's ability to have unlimited sub-projects, sequential and parallel orderings, and project-level start and due dates have truly spoiled me, and have single-handedly allowed me to dismiss many other task management applications whose project structures are not so fully-featured. There are, however, three areas I think the concept of projects could be improved and expanded:

  1. Templates. I know firsthand that people like the idea of templates in OmniFocus. Even simple implementations (say, with only variables and default folders) would be enough to satisfy a lot of people and, most importantly, reduce friction in creating common types of projects. Please, Omni Group: obviate the need for my Template script.

  2. Reference Material: I talked about this above but I'll say it again: there needs to be a better way to link OmniFocus tasks and projects to reference material. I created a gross AppleScript to link a folder in the file system to a project, but a native implementation would be far better. I think there is enough overlap in OmniFocus and Dropbox users that a feature that would link a Dropbox folder or file to a project/ task (and that could open the Dropbox app to that location when using OmniFocus on iOS) would be a huge improvement in integrating OmniFocus with a digital workflow.

  3. Cross-Listed Tasks: some tasks deny the general rule of having a one-to-one relationship with a project. For example, buying food for a picnic is an obvious action in the project of preparing for the picnic, but you may also have a shopping list project in which the task also belongs. Right now, you have two choices: leave it off one list (which may interfere with creating a sequential project for the picnic) or put it on both and remember to check it off twice. Being able to put that same task in both places at once would create a more honest system. This one could be made less necessary with multiple contexts, as you could effectively replicate multiple projects using tags.

Grab Bag

I have a few more ideas/ complaints that don't fit into the above, but I still see as important feature additions that would reduce friction in OmniFocus:

  • Better ways of handling “waiting for” items that require follow up. If you have an “on hold” context for tasks you are waiting on it can quickly turn into a black hole; tasks go in, never surface in any view, and are forgotten about. It would be great if there were a built-in reminder to follow up on such tasks that didn't require creating some strange, complex project structure just to make sure the right notifications surface at the right times.

  • Some way of delegating tasks or collaborating with others. I don't think I'd use this much, but I am not so ignorant to fail to see that, for many people, this is an incredibly important feature. Even something simple like being able to generate a nicely-formatted HTML email showing what tasks you'd like to send to someone would be a great start. Watching my email for a reply to that email and automatically marking those tasks as complete would be even better.

Interaction

Surfacing Actions

If you are a seasoned OmniFocus user, try remembering your first experience with the application. In my (faint) recollection, it was not the most enjoyable experience; I entered some tasks in the system, and then expected some nice list of what I had to do to spring forth from the bowels of this behemoth. Instead... nothing. The same complexity and flexibility that make OmniFocus so useful for power users makes it nigh-impenetrable for novices.

In trying to turn friends on to OmniFocus, the biggest stumbling block happens extremely early on: so many times, I heard something along the lines of, “I put tasks in, but where do I go to see what I have to do?”. “Well,” I would say, “you can either look through your projects, or press Command-V and — no, command is the one with the splat-looking symbol on it — change these view options around to create filters on what's shown and... let's just get you Things”. It is such a challenge to get over that initial hump because OmniFocus does not do a good job of surfacing your tasks.

Thankfully, the Omni Group is moving in the right direction. Forecast view gives you a place to go to look at things you've told the application you want to do. Combining this with a target date would really cement the idea of “scheduling” tasks that, I think, would sufficiently lower the barrier to entry for novice users. A better review mode will also help, as users can more easily go through their projects and, using their new scheduling tools, make sure that projects don't become stale and forgotten. If it's going to work, though, OmniFocus has to put Forecast and Review front-and-center if every version of the app, and deemphasize the generic list views where novice users can easily get overwhelmed and lost.

Another option for surfacing tasks to users is to provide a guided tool custom-built for that purpose. It would have to be a tool that could answer, “What should I do now?”. It's tough to imagine such a tool with enough flexibility to be useful to any meaningful proportion of the OmniFocus user base, but I think the Omni Group is up to it. I imagine a little form that would ask what contexts you have available to you, how much time you have (which would limit the number of tasks actually shown to you) and whether you'd like to prioritize newer projects, older projects, or projects in a particular folder. You'd then get a list of things to do, taking the guesswork and friction of doing it yourself.

Functional Disparities Between Platforms

I've already touched on some of these inconsistencies; if it wasn't clear, they drive me a little batty. I assume that many OmniFocus users share my obsessive nature, so I feel comfortable in assuming also that these nagging disparities drive many other OmniFocus users batty, too. Here's a few differences between OmniFocus versions that jump to the top of my mind:

  • Rich text notes and embedded files (see also: rich text is gross) on the Mac, but not on iOS

  • The ability to set a project not to complete automatically when completing the last action on the Mac, but no such option on iOS (I can't describe how much I hate this, and how embarrassed I am at hating such petty, unimportant things)

  • Forecast view on iPhone and iPad, but not on the Mac (thankfully, it's coming)

  • Ability to review projects on the iPad and the Mac (though it's much nicer to do so on the iPad), but not the iPhone

  • Ability to create perspectives on the Mac, but only to view them on the iPhone and iPad

  • Project-based views on the Mac, but no such luck on iOS

  • Ability to focus on a set of projects, folders, or contexts only on the Mac version

Now, I know that you have to make hard design choices, particularly when you move from a platform with as much as 27 inches to stretch out in to one with less than ten. However, some of these exclusions are so frustrating, so limiting, so friction-inducing, that a reasonable case could made that these features need to be consistent across every version. If that means the feature needs to be removed from every version, so be it (please, please, take the rich text away. I beg you!).

Editing on iOS

Implementing features that let users edit data on iOS as efficiently as they can on a Mac is no small task. iOS has been around for years and few apps have managed to choose the right set of features, interfaces, and affordances to make editing on a screen the size of an iPhone even bearable. One thing is for certain: the “Edit” button currently in iOS does not cut it. I like the idea of an edit button that lets you select any set of items currently in view and perform one of the following actions on them:

  • Group them into a project/ sub-project. If you want to make a sub-project with just two tasks in OmniFocus for iPhone, you're looking at a 13-tap process: 1) create the two tasks, plus another one that will become the sub-project, 2) tap on the first task, then tap on the folder icon in the bottom-right corner, then tap on the sub-project task, and, finally, tap the back button (twice), and 3) repeat (2) with the second task. It would be great to select the tasks you want to make a group and tap a single “grouping” button, or to be able to drag tasks on top of one another similarly to how you create folders of app icons.

  • Duplicating tasks. It's good to here that the ability to cut, copy, and paste tasks is coming in a soon-to-be-released version of OmniFocus for iPhone; that should make it much easier to manage project creation on the iPhone.

  • Batch editing items. This would particularly come in handy for setting dates; if you want to set the start/ due dates of multiple tasks right now, you need to tap through to the date on each task and set it separately each time. It would also help if you had a limited number of frequently-used contexts that you'd like to assign quickly, or to add multiple inbox items to a single project.

Another Grab Bag, This Time With Unimportant Interface Changes That I Would Really Appreciate, If It's Not Too Much To Ask (It's Not Like You're Busy, Right?)

I couldn't find a smart way to categorize some of my thoughts. Instead, I'll just let the complaints fly as they may!

  • When you complete a task it can be a challenge to remember what the next task for that project is, particularly when you are in a context view. There should be some sort of visual cue to let you know what's next for that project to help in preventing stalled projects.

  • It would be great if, on the iPhone, task names were edited in a separate view, as notes are. Long task names can be very difficult to edit as you have to scroll through an unwrapped string of text just to get to the part you'd like to edit.

  • Setting task dates is much nicer on the iPhone/ iPad than on the Mac, primarily as a result of the buttons that allow you to quickly increase the dates by set intervals. I'd love to see this ability brought back to the Mac, and even to have it expanded: being able to set custom intervals or to have buttons for commonly-used times would be fantastic.

  • I've often wanted temporary contexts tied to a particular project or folder. For example, I'm' a teaching assistant for a number of university courses, and would appreciate if contexts related to those courses disappeared when the term is over.

  • Change the way due date counts are calculated. How many items would you say are due if you have a project with four tasks that's due today? I would say four, but OmniFocus counts the project and shows five. It's maddening, maddening I tell you!

  • I often long for an easier way to switch the project I'm looking at between parallel and sequential ordering; a menu item on the Mac would be much appreciated.


So, that's where we stand. When you come to rely so completely on a system like OmniFocus, when you use it day in and day out, those rough edges, near unnoticeable to most people, start to feel like sandpaper. That's what everything above has been about; not fundamental faults in the software, but nips and tucks that would smooth the way for those of us pushing the limits of the system.

In Part II, I'm going to tackle the tougher side of design changes: actually showing how the Omni Group could implement some of these ideas. I'm well aware that, absent concrete ways of integrating these ideas into the application, they really aren't worth the bits they're painted on. These complaints are just empty words without some sort of action, so go check Part II out now!


  1. For what it's worth, I think very few projects have a start date, and instead are available as soon as their preceding tasks are available. Sequential projects are really the foundation of GTD, and learning to use them appropriately is the key to using the system well.

OmniFocus Sync Speeds

Recently, I've noticed that the syncing of my OmniFocus database has been painfully slow. I've resorted to other ways of tossing items in OmniFocus, particularly on iOS where I can't let OmniFocus sync in the background. I tweeted out my frustration and Ken Case, CEO of the Omni Group, kindly got back to me:

@pxldots Unless you have big attachments, archiving doesn’t affect sync times nearly as much as stale devices do. /cc @dirckxd @ediventurin (link).

and:

@pxldots If you have more than 150 zip files (check the bottom of settings in the iPhone app), that’s probably the problem. (link)

As Ken mentioned in his tweets, you can check whether you have an excess of zip files (the result of some syncing voodoo to manage the eventual sync of "stale" devices, those that haven't been synced in awhile) in the settings of the iPhone and iPad apps. My iPad, which hadn't been synced in ages, looked like this:

iPad Sync Settings

1,100 files! On my final sync before resolving the issue, the iPhone sync took over a minute and the iPad, which had gone much longer since its last use, took over 9 minutes.

You can get a sense for which devices are registered (and which may be clogging the pipes) in the Sync preferences of the Mac version (OmniFocus > Preferences > Sync) by clicking on the Show Clients button.

Mac Sync Settings

To resolve the slow sync, just sync each of the clients, unregister each on the preference pane of the Mac client, and then re-sync each again. Subsequently, the zip file count should drop, as should the sync time. I can confirm that the times were much improved on my end, so give this a shot if you are having similar troubles!

iPhone Sync Settings Before and After

Song Control: An Alfred Workflow for iTunes

I've been trying to go through my entire iTunes library and clean up the ratings/ playlists of each song. For the past few months I've been using a set of Keyboard Maestro actions to manage all of this, but that solution has been fragile and far from ideal. I decided to take it up a notch with a custom Alfred Workflow.

Song Control.alfredworkflow allows you to manage playlist membership (list) and rating (rate) of the current song, as well as do some common iTunes actions like play, pause, next, previous, and random. You can also get the current song's information by typing sinfo.

All of the details are available on the project's Github page. Enjoy!