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?”
