By William Van Hecke and Curt Clifton

Version 2.3 of OmniFocus for Mac brings two new options for how to view your tasks and projects.

• Custom Columns is a new layout that puts data in a familiar grid, showing only the fields you choose — fields like project, due date, or estimated duration. This gives you the flexibility to show exactly as much information as you want.
• Title Folding is an option that reduces item titles to a single line, showing the full title when the item is selected. You can turn on folding to see more items at once and to preserve a regular vertical rhythm even when your titles are of varying lengths.

These options, which provide a scannable and information-dense layout that always shows precisely what you choose, join and complement the existing Fluid layout, which intelligently chooses which fields to display and prioritizes breathing room.

In this post we’d like to describe a bit of the design thinking behind the Custom Columns layout. We’ll follow up with a post that discusses how we added the feature to our existing code.

Before jumping into the design of Custom Columns layout, let’s revisit the key design goals of OmniFocus 2. OmniFocus 1 was a terrific app, but could sometimes feel more like a system construction kit than a system. One of the design goals for OmniFocus 2 was to make OmniFocus more approachable, which we addressed in several ways.

Simplified Perspectives

OmniFocus 1 had two view modes: Project mode showed your projects hierarchically and Context mode showed your tasks and projects in a flat list. Each of these modes had a variety of view options for what items to show and how to order them. A perspective, then, was just a way to save a set of choices for one or both view modes. This was a challenging mental model, since the view options felt very transient. The connection between a perspective and the displayed information was tenuous, and choosing a perspective could even change the options for the mode that you weren’t looking at.

For OmniFocus 2, we introduced a tabbed interface where each perspective corresponds to a single tab. A tab either shows project hierarchy or doesn’t, eliminating view modes as a separate concept. The view options for each perspective are available in a popover from within the tab. This provides a concrete connection between the options and what is displayed.

Built-in Perspectives

OmniFocus 1 came with a variety of pre-configured perspectives. But because you could configure them in all the same ways as custom perspectives, all the complexity of the OmniFocus 1 perspective system was exposed. You could edit the standard “Inbox” perspective until it had absolutely nothing to do with the Inbox at all. This opened up even more ways that people could get into confusing situations, with no escape hatch.

For OmniFocus 2, we gave our built-in perspectives a drastically simplified set of options. Each perspective offers only the options that really make sense for its intended purpose, and the options are labeled with explanatory text to set expectations properly. This approach let us introduce special perspectives like Forecast and Review, each designed for a specific use case and offering a unique handful of view options.

Standard and Pro Versions

OmniFocus 1 for Mac came in a single edition that included all the customization options.

In version 2, we offer OmniFocus as a standard edition plus a Pro upgrade. This lets us provide a cleaner, less complex, more affordable product for new users or those who don’t need advanced customization. The standard edition includes our built-in perspectives with the simplified options; these are meant to cover the majority of needs for the majority of people. If you choose to upgrade to Pro, you get (among other things) fully customizable perspectives. These provide custom sorting, filtering, grouping, and saved focus and selection, so you can build your own views to cover any specialized patterns of use beyond the standard perspectives.

Fluid Layout

OmniFocus 1 laid out everything in a rigid grid of rows and columns. This had the benefit of being predictable and scannable in two dimensions, but it also felt severely constrained on the horizontal axis, often causing text to wrap in awkward ways and putting the burden on you to manually fight the battle of column widths versus window width. It also made for a layout with lots of “holes” in it, where there didn’t happen to be a value set for a given column but we needed to reserve a place for it anyway.

When you have to manage column widths yourself, you can end up with awkward wrapping and ugly holes in your layout.

For version 2, we switched to a fluid layout that places more emphasis on titles. Long titles can span the entire width of a row, followed by a deemphasized second line of metadata much like in a standard iOS table view. OmniFocus saves space by intelligently choosing which fields to show based on which fields are relevant for each item and how much space is available. At rest, the metadata fields stay as quiet as possible. But when you put the mouse pointer over a row or start editing it, they become more apparent so you can interact with them. For containers (like projects and contexts), we use the metadata row to show a summary of the items inside and how many of them are due.

This all means that there’s much less pressure on you to figure out a good window layout — the app does that work, offering a much larger range of window geometries that result in something reasonable without any extra setup. It also uses vertical space more aggressively than horizontal space, since scrolling vertically is a cheap interaction and scrolling horizontally is awkward and best avoided.

OmniFocus 2 Fluid is more space-efficient than OmniFocus 1 if you use a narrow window.

With wide windows, the Fluid layout is less dense. The new Custom Columns layout makes more efficient use of the width, with plenty of room for any extra columns you may care to add.

Adding Custom Columns to OmniFocus 2

All that worked great for a majority of OmniFocus use cases, which was a relief. When software takes configuration control away from the user and makes the computer do it, the result can be either liberating (“Yay, I don’t have to worry about this anymore!”) or irritating (“Ugh, now instead of letting me make smart decisions, the computer is making dumb decisions on my behalf”). Happily, the feedback on OmniFocus 2 has been overwhelmingly positive; we seem to have made it smart enough to handle most people’s needs gracefully!

But just because we’d made the app more approachable and more sensible without too much setup, we still wanted to do well by our customers who want more control. We identified some common themes in what else our customers wanted to be possible in the layout.

• More vertical compactness, so that short windows can show more items without scrolling.
• A better use of the very wide space afforded when you take OmniFocus full-screen on a big display.
• The ability to choose which metadata fields appear.
• More stable positions for metadata fields between rows, to improve “scannability” when comparing different rows’ contexts, duration, or other values.

On the surface, the solution might seem to be to just bring back OmniFocus 1’s spreadsheetesque layout. But we believed we could design for these needs while holding on to OmniFocus 2’s hard-earned improvements in approachability. The result of this quest for balance is the new Custom Columns layout. Superficially, it looks a bit like OmniFocus 1, but Custom Columns have a lot more intelligence behind the scenes.

• OmniFocus automatically chooses the width for each column. (This sounds trivial but it took quite a lot of thinking and tuning to arrive at a scheme that works.) Some columns are fixed width; date columns for instance are set to be as wide as the widest possible date given your OS X date format, always resulting in a reasonable size with no wrapping. Other columns, like Project and Context, resize proportionally with the width of your window while obeying sensible minimum and maximum widths. All this means we can omit the visual noise and the invitation to fidget that come with column headers.
• Indentation of grouped items borrows space from the title column until the titles reach a minimum width. Beyond that, we start omitting columns from left to right so that the remaining columns stay aligned.
• In Custom Columns layout the selected columns appear in a fixed order. This is one of the more obvious tradeoffs in the design. It would certainly be possible to allow rearranging them, but we thought that the benefits were outweighed by the cognitive burden of multiplying everything in the Custom Columns interface by another dimension of complexity.
• The existing Text Size setting in OmniFocus preferences is even smarter with Custom Columns, employing carefully-tuned reductions in negative space and smaller status circles when you choose smaller text sizes. This allows for maximal information density without spawning another setting.
• For the standard edition, your layout is a single app-wide choice made in OmniFocus Preferences: use our recommended Fluid layout everywhere, or use the Custom Columns of your choice everywhere. The main interface of the app doesn’t force you to choose a layout or encourage you to flip back and forth.
• If you have the Pro upgrade, the same app-wide preference applies by default, but you gain the ability to customize the layout on a per-perspective basis. As for other perspective settings, it all happens in the the view options popover. Using an app-wide default makes layout a “set it and forget it” choice for most perspectives. On the other hand, being able to choose different metadata for different perspectives opens up tons of possibilities. For example, in Quick Entry, Curt chooses to show just the item title and due date to encourage him to capture items as quickly as possible.

Custom Columns Layout in OmniFocus for Mac is our approach to introducing more flexible layouts and preserving the friendliness of the interface. The technology behind it is sophisticated (as you’ll see in the next post) but ideally, the user should be able to ignore it and get to work. Based on feedback from people in our public test phase and since our launch, we think we’ve struck a useful balance.

In our next post, we’ll discuss how we implemented this design in our existing app.

Software design is pretty much dead-center between being an art and a science. Or as Jobs said, at the “intersection of technology and liberal arts”. This means that while some decisions we have to make are logical and can be satisfyingly backed up with evidence, other decisions are thrillingly, maddeningly subjective matters of taste.

So… App icons! They’re way over on the subjective side, and are at least as much marketing as they are user interface. Over the years, we have taken a few different stabs at developing a distinctive style for our app icons, but the realities of shipping software made it so that we were never really poised to release a major upgrade to everything all at once. So instead we made staggered incremental changes across our suite of apps, making for this diverse crowd.

But during the course of pursuing our iPad or Bust initiative, we decided that we would never have a better time to make our app icons more consistent. Better to change all the icons at once than to wait for each of our five huge productivity apps (spread across three platforms) to reach major versions, updating the icons one by one. So we got to work on coming up with a consistent style. Here’s the final result:

This new suite of icons emerged from an extensive list of demands:

Each product should have a distinctive emblem with a strong contour. The emblems are simple figure/ground shapes. They don’t depend on colors, gradients, shadows, or other effects, so we can use them in a variety of treatments: flat logos, outlines, cut-outs, and so on. Joel forged these emblems in OmniGraffle as purely positive/negative-space shapes.

Each product should have a consistent look across platforms. The emblems and theme colors identify the products from Mac to iPad to iPhone. (Relying primarily on color would cause problems for folks who perceive color differently!)

Each platform should have a consistent look across products. iOS apps get a colored slab with the emblem cut out, showing the black slab beneath (or white, for our iPhone app). The Mac variants are the same, but with the slabs rotated and tilted slightly away from the viewer. We go way back on Mac OS; that composition is a bit of a callback to the classic angled-document app icon style.

The icons should have a sense of being part of a unified set. This was a big one, and it took a while to get right. We didn’t just want them to look unified, we wanted them to look unquestionably Omni — we don’t have it as bad as Panic, but our icons have been stolen from time to time. It was hard to think of how to do this other than slapping a huge Omni logo on each icon. So instead, Joel had the idea of slapping hundreds of tiny Omni logos on each one. In doing so, we were even able to evoke our old brushed-metal motif.

The colored front slabs bear a carbon-fiberesque pattern of Omni logos, and the back slabs bear a prime-number-based marble pattern of Omni logos:

Lots of people here at Omni put a ton of work into this project, but Joel was the main dude. Many cheers for Joel! I did the final art for the iOS variants in Photoshop, and for the Mac variants in Modo. I’ll leave you with a shot of the OmniGraphSketcher icon from when I was zoomed in to scrutinize some tiny detail; Joel looked over my shoulder and immediately declared, “Oooh, I wanna play an FPS in there!”

Thanks to all who came out to our booth at Macworld | iWorld 2012, tried out our apps, participated in the workshops, and picked up some classy embossed iPad sleeves. We always love getting to meet people face-to-face and talk about software!

Each of the workshops this year was designed to be a quick, interactive run-through of just a few of the things you can do with one of our iPad apps. We’ve just posted videos of the workshops for anyone who didn’t get to see them on the show floor. If you want a five-minute intro to what a particular Omni product is all about, these are a pretty excellent way to get it.

[These videos are no longer available. —Ed.]

• OmniGraffle: Wireframe Basics
• OmniGraffle: Space Planning
• OmniFocus: Basics
• OmniFocus: Daily To-Do
• OmniFocus: Weekly Review
• OmniOutliner: Crafting Classy Documents
• OmniOutliner: Building Budgets
• OmniGraphSketcher: Visualize Data

Enjoy!

Hallo. The styles system in OmniOutliner for Mac is a good example of an interface that, if you take the time to master it, provides pretty bewildering amounts of power. If you don’t take the time to master it, well, it mostly does its job whilst hovering somewhere between nifty and wacky. When creating OmniOutliner for iPad, we wanted to take a fresh stab at styles, and see if we could give the same underlying system a more sensible interface.

Respecting Row Boundaries

OmniOutliner for Mac behaves like a word processor: once you turn on a style attribute, that style is in effect until you decide to turn it off:

But part of what makes an outline an outline is that rows are distinct, discrete objects. You can select them individually, shuffle them around, and keep them more organized than a simple stream of text. So on iPad, we stopped propagating styles across row boundaries:

This one small change made a big difference in how the app feels. Rather than trying to be smart and guessing what you might want for each row, we erred on the side of containment and predictability.

Emphasizing Named Styles

OmniOutliner for Mac makes it easy to set up one-time custom styles on text. Just select something and start messing with the inspectors. That’s great, except that it can pretty quickly lead to myriad slightly-different one-off styles. Maybe some of your headings are 16-point size, while others are 15. Some highlights are one shade of yellow, while others are a slightly different one. And if you ever want to change any of those styles, you’ll need to go back and edit them one by one.

The better way, of course, is named styles. Set up a style once, and then use it over and over. If you edit the style, all instances of it change too. To encourage the use of named styles on iPad, we did two things.

First, we included several document templates, each with its own suite of carefully-constructed named styles. This is in line with our observance of sensible defaults — offering good initial settings with an app is even more important than, and can often preclude the need for, customization. In other words, it’s not good enough to let people make cool stuff as long as they are willing to do the setup — they should be able to make cool stuff without any setup at all.

Second, we put the ad-hoc styling controls one panel deeper than the named styles. You need to go past the existing named styles before you can get at the fiddly stuff. Hopefully, if there is a named style that does what you want, you’ll notice it before going and doing the work yourself.

Replacing the Styles Palette, the Style Attributes Inspector, and the Style Matrix

The Mac version makes it easy to set up complex automatic style hierarchies; in fact, it’s too easy. If you want to make good use of that power, you have to get comfortable with the Styles Palette, the Style Attributes Inspector, and the Styles View matrix. Each of these appears in a different place and is used for a slightly different purpose.

For iPad, we wanted to offer 90% of the functionality people want, with about 10% of the effort. Most importantly, we wanted to stop compromising the experience of casual users in order to offer esoteric functionality to power users. As the Alan Kay quotation goes, “simple things should be simple; complex things should be possible.”

Simple things should be simple

In reality, your relationship with styles is that you almost always just want to select a row and choose a style. On the Mac, this simple action is not as simple as it could be to perform. You open the Style Palette to see which styles are available (assuming you made some). Then you drag a style from the palette to the row in your outline. Then you can select the row and open the Style Attributes inspector to see which styles are applied.

On the iPad, we made it super simple: tap a row, tap the Inspector button, and tap a style; the style gets a checkmark to show that it’s applied. This uses the select-then-modify interaction people are familiar with, and combines the list of available styles with the indication of which styles are applied.

Complex things should be possible

In OmniOutliner for Mac, you can set up very precise automatic style hierarchies (like great-great-grandchildren of this particular row should be italic and blue and get the Citation style). But this means as you grow your document, you have a geometrically-increasing number of little style chits to keep under control. The Styles palette is constantly showing you all the level styles, encouraging you to customize them. Every row in your document has a style slot for every level of descendants! But, since you don’t actually often need to use such stuff, we wanted to stop putting it in front of you all the time.

Instead, on the iPad we’ve replaced that entire system with a single “children’s style” attribute on each named style. (For instance, you can say that children of Heading 1 rows get the Heading 2 style.) You can use it to chain together styles and get the same effects as before, but the interface for it is tucked away instead of in your face, and it takes quite a few taps to set up long chains.

Yep, we actually intentionally made automatic level-based styles a bit harder to do, because it let us drastically simplify the way we represent styles. And the difficulty is not that big of a deal because we could provide sensible default documents where the chain was already set up. That way, you can customize our chain when you need one, and forget about the feature altogether when you don’t.

The complexity-to-difficulty curve

Lots of desktop software starts out hard, and gets a little harder when you want to do something really demanding. But you can do pretty much everything you could realistically want to do. iPad software, though, starts out really easy, and then more steeply increases in difficulty as you try to do more complicated stuff. Eventually you hit a point where you can’t do certain elaborate tasks at all.

Why? Because it’s actually quite rare that you want to do something that complicated! Almost everything you want to do in your day-to-day life is way to the left of the intersection of these difficulty curves. Accommodating the elaborate cases would almost certainly compromise simplicity for the normal stuff. The whole iPad experience is more than happy to sacrifice the super power-user workflow in favor of the commonest cases.

So much of software design is deciding what you want your complexity-to-difficulty curve to look like: where it begins, how it ramps up, and where it cuts off entirely. In fact, while I was composing this post, Lukas Mathis made an excellent post exploring various apps’ graphs of experience versus depth: The Growing User and the Perennial Beginner.

However you visualize it, consider: “Who is this product for? What should their first-run experience be like? What about their one-hundredth-run experience? And can we stay useful enough for them to have a one-thousandth-run experience?”

If you're like us, nearly all of your OmniFocus actions seem to want to go in some leviathan-context called “Computer” or “Online” or something equally unhelpful. Here is one way to break that huge context down using hierarchical contexts in OmniFocus. Instead of organizing actions strictly by where the work needs to happen, this approach also considers the kind of work your brain needs to do in order to get them done. That way, when I'm sitting in front of the Mac or the iPad wondering what to work on, I can choose based on where my mind is, instead of paging past tons of stuff that seems too boring or too demanding.

• Work — This used to be called “Mac”, before the iPhone and iPad. Now this sort of work can happen pretty much anywhere. Nothing goes directly in here, only in the subcontexts. The subcontexts are arranged roughly by ascending cognitive expense.
  • Maintenance — Mindless stuff like shuffling files around, paying bills, and fixing little problems on sites.
  • Study — Research, Googlin’, finding out stuffs I need to find out.
  • Communication — Contacting people by email or chat.
  • Planning — Serious thinking, outlining, drafting ideas, and so on.
  • Design — Grafflin’ & Photochoppin’.
  • Writing — Production writing tasks for things that need to be written well.
  • Code — Coding tasks that are likely to require a warmed-up brain.
  • Translation — Making things that are in Japanese not be in Japanese anymore.
• Input — Videos; music; articles that won’t go in Instapaper.
• Output — Informal blog posts (“macrotweeting”) and such that don’t require intense thought.

This strategy is probably common knowledge among serious GTD theorists, but I still run into folks who are surprised by it. The inspiration for adopting it myself came from my DavidCo GTD coaching session a while back. This context arrangement (in addition to the standard Home, Errands, et cetera) pretty seriously improved the way I work. I hope it yields some usefulness for you too.