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.

Hallo, friends. To commemorate the big OmniFocus 1.8 update, with its bounty of interface improvements, I invite you to look back at the history of the OmniFocus interface.

The first publicly revealed image of the OmniFocus interface was this OmniGraffle mockup, from an event at the San Francisco Apple Store during Macworld 2007. I suppose I could post an actual screenshot, but I’ve always been proud to have something I worked on appear in a blurry photograph on a Mac rumors site, as if it was of some sort of top-secret Apple project.

Almost precisely one year later, OmniFocus 1.0 was released. I’ll be the first to admit that version 1.0 was a… utilitarian design. We maintained that all the first step needed to be was a proper Cocoa implementation of the AppleScript & OmniOutliner system, Kinkless GTD. Of course, we couldn’t help adding luxuries, but for the most part we were excited to get something useful out to people. Then, once it was out there, we wanted to hurry up and fix the flaws. So despite all their usefulness and charm, the early versions of OmniFocus did not have the benefit of comprehensive, contemplative design review.

Let’s look at OmniFocus 1.0 (actually 1.0.3, as that’s the earliest I could unearth) and see how it compares to version 1.8.

First Run

OmniFocus 1.0 had a rather unwelcoming first-run experience: an “unlicensed” message, a big white window that eventually loaded a waterfall of release notes, a disabled inspector of empty controls, and a sliver of the main window peeking through. Wh— why!? Well, after the public sneaky peek process, version 1.0 was, for almost everyone involved, just another build. Not paying enough attention to how it felt to use OmniFocus for the first time was our main oversight.

OmniFocus 1.8, though, starts out with nothing more than a normal window containing some sample projects, ready for you to get started. We're trying to recognize that you downloaded the app because you want to try it; there will be plenty of time for the rest of that stuff later. The trial notice sits politely in the upper corner of the window, ready to talk about licensing when you are. This lovely idea, now common in Mac software, originated in Coda.

General Typography and Layout

Your highfalutin literary quotation for today is Si latet, ars prodest — When the art is concealed, it succeeds. Ovid wrote that, around the year -1. And, uh, he was actually writing about how to impress a lady. But it’s just as true of typography and UI design: When someone has fretted over the tiny details of where and how your information is presented, the presentation becomes transparent and you see through it to the content. When the details are wrong, you get a sense that something is awry, even if you can’t pinpoint what; your stuff is there, but behind smudged glass in a crooked frame.

I’ll pick out a few of the improvements we’ve made since version 1.0 to give your data the presentation it deserves.

The most immediately refreshing change was switching the font from 12-point Helvetica to 13-point Lucida Grande. Apple’s Human Interface Guidelines recommend Lucida Grande as a default font for user content, because its wide apertures and distinct letterforms make for excellent readability on screens. Lots of applications, though (including Apple’s TextEdit and Mail) use Helvetica, presumably because it includes an oblique variant, which people expect when editing rich text. On iPhone, Helvetica seems to work well, possibly because of the higher DPI allowing for higher point sizes, and the tendency of the device to be closer to a reader’s eyes. For plain text on a Mac screen, though, Lucida Grande feels lighter and more spacious.

Giving each row more breathing space also made a big difference. It cost us a bit of information density, so your window needs to be bigger to accommodate the same stuff. But the way items feel more discrete and more individually substantial is worth it. Now each item is given plenty of space, making it a comfortable click target. But the space furnished to each item also acknowledges that it’s a thing that you have deemed meaningful enough to put in our application, not just another row crammed into a list.

We’ve nudged almost everything at least a pixel or two for better alignment. We cleaned up and encrispened all of the item icons, especially the little index cards that represent projects and contexts. What were once tiny boxes buzzing with high-contrast 1+1=3 effects have quieted down. No icons are rescaled from their original sizes into fuzzy mush anymore. (The new item icons are actually from when the nice folks at Bee Docs requested some graphics for their OmniFocus integration, and I was embarrassed to send the ones we had. So I went ahead and made the improvements I’d been meaning to make for a while.)

Filtering: Where Did My Data Go?

At first, one of our main goals was to facilitate personally customizable view settings, especially for hiding everything you don’t need to see right now. You know, so you can focus on your work. That quest for flexibility gave us the View Bar, Perspectives, Planning and Context modes, and a detailed item status system. You can demand Only show me items due today that are for this client and contain the word “web”, sorted by when I created them and grouped by context.

That was great. You could set up all sorts of precise searches, hiding unimportant items willy nilly. But the burden of governing all that power was on you. We neglected to include obvious, helpful built-in view settings with buttons you can mash to get back to a sensible state, and instead invited people to set up and manage their own Perspectives. Early-adopting power users were happy to take advantage of the view options, while casual or beginning users didn’t know where to begin or how to get back to seeing all of their stuff.

For version 1.5, part of clarifying what is going on with your view was simply increasing the visual substance of the View Bar, and labeling its many pop-up menus. For a while, we colored any setting that was different from the default. But it became unclear what “default” means, and whether we ought to be bothering people who preferred to keep slightly different settings from our recommended ones.

More importantly, we added several built-in perspectives to the default toolbar, for getting back to reliable view settings no matter where you are: Inbox, Projects, Contexts, Due, Flagged, and Review. These relieved the need for almost everyone to create the same basic perspectives. We knew that most people would want something like these views, so why not provide them in the first place? And if you want something slightly different, the rebuilt Perspectives interface makes it straightforward to adjust them or create your own.

Onward

Of course, all of these improvements, and the cornucopia of improvements I haven’t mentioned, have been tempered by needing to avoid changing the architecture or character of the app too drastically. So the really exciting new work is going into OmniFocus 2, the design of which is turning out to be a vanguard for the future of Omni Mac apps. I can't tell you anything about it yet, of course, but the designs we've come up with make me want to graduate from version 1 as soon as possible.

Meanwhile, the tremendously positive response to OmniFocus for iPad has made us revisit our assumptions about Mac software. The marriage of our existing OmniFocus 2 plans and the philosophy of OmniFocus for iPad gives this app a pretty dang bright future.

If you’ve been using OmniFocus all along, and especially if you’ve let us know what you think of it, thank you for your lasting support. If you’ve started using OmniFocus lately, thank you for checking us out. If you aren’t using OmniFocus, well… thanks for reading this super long blog post anyway!