OmniOutliner 4
February 3, 2014 at 10:37 PM by Dr. Drang
I’ve never been much for mind mapping, but I do like a good outline. When I returned to the Mac in 2005, my iBook G4 came with OmniOutliner preinstalled and that’s what I’ve used ever since. It wasn’t the ideal outliner, but it was good enough, especially after I updated to the Pro version. After a very long wait, the Omni Group recently released OmniOutliner 4 in both Standard and Pro versions.
The world of outlining on the Mac has changed a lot in the last 8-10 years, and I wouldn’t be surprised to find that many of OO3’s users abandoned it for apps like TaskPaper, FoldingText, or Opal; web apps like Fargo; or one of the outlining modes of text editors like TextMate or Sublime Text. Before I decided to update to OO4, I spent a week or two looking over the competition.
The others
Jesse Grosjean’s TaskPaper is very good for organizing tasks, and while it can be used as a general-purpose outliner, I’ve always run into limitations when trying to do so. It was more appealing when the iOS version was still available.
Folding Text is the (relatively) new hotness from Jesse, and many people I think highly of are using it. Like TaskPaper, it saves files in a Markdownish plain text format and uses clues in the text to distinguish things like section headers, paragraphs, and lists from each other. It sounds like something right up my alley, but it seems incomplete at the moment and isn’t getting official updates on a regular basis. I don’t want to kick a man when he’s down, but I’d like to see Jesse pay more attention to Folding Text before I invest my time in learning it and altering my workflows to incorporate it.
Opal is a capable little app from David Dunham, whom many of you old-timers will remember for the pre-OS X outliner, Acta, and the great desk accessory, miniWRITER. He’s also the inventor of the smart quotes algorithm, which most of us who care about typography use in one form or another. David understands outlining very well, and I’d be happy to use Opal if it was a little more flexible in how it formats outlines for print or PDF output.
Fargo is Dave Winer’s entry into outlining, and you won’t be surprised to hear that Fargo saves your outlines in OPML format. It’s an interesting demonstration of web interactivity, but I find Fargo’s user interface too clunky.
I don’t use the current version of TextMate and have never used Sublime Text, so I can’t say how well their outlining modes work. BBEdit can fold Markdown, which you might think would work for outlining, but it isn’t smart enough to work the way it should. If, for example, you click on the folding triangle next to an H1 heading, it doesn’t fold up all the text to the next H1. Instead, it folds only to the next heading of any type. I can understand how that folding logic would be easier to code, but it doesn’t match the structure of the document and is pretty much worthless for outlining.
The uses
I write outlines for two purposes:
- The traditional purpose of organizing another piece of writing. My writing consists of blog posts and reports. You can probably guess that I don’t bother outlining my posts. I seldom outline short reports (less than five pages), but I usually do outline reports longer than that, especially when there isn’t an obvious order in which to present the information. It’s the ability to grab chunks of the outline and move them around that’s the most important to me.
- To communicate directly with clients and coworkers. In these cases, the outline is the end product, not merely a means to an end, and the format of the output, especially when sent to a client, is important.
It’s the combination of these two, along with the improvements Omni’s made in version 4, that convinced me to stay with OmniOutliner.
The improvements
To my mind, OmniOutliner’s functionality was never a concern; it was its user interface that needed work. And that’s where Omni’s made the most progress.
The biggest improvement is the addition of a zoom control. You can see it here near the left end of the toolbar.
For years, the lack of this simple control was what I hated most about OmniOutliner. It always displayed the outline with one pixel equaling one point, a poor choice when monitors commonly run at 120 dpi or greater. Font sizes that were comfortably readable on screen came out childishly huge on paper or PDF; sizes that looked good in print were unreadable on screen. The zoom control allows the best of both worlds.
The style inspectors are now much easier to work with. In OmniOutliner 3, settings were hidden behind subtabs whose purpose was hard to remember. I hated the gear—all it meant was “we don’t know how to categorize this stuff.”
I find OmniOutliner 4’s inspectors much easier to use. Not only is everything properly labeled, the Microsoftian subtabs are gone.
It’s true that the icons along the top of the inspector panel could be misinterpreted on their own, but their names appear at the top of the panel as soon as you mouse over them. This teaches you their function pretty quickly and is much better than the delayed tooltips you usually see.
The regressions
Michael Tsai pointed out one annoyance that’s crept in:
I miss the drawer, which was easy to toggle with the toolbar button. In version 4, the window resizes (on the left) when you hide or show the sidebar, so the toolbar button moves out from under the cursor. This is so maddening that I’ve removed the button from the toolbar and switched to using the keyboard shortcut.
Drawers are no longer in style, so I’m not surprised Omni removed it, but click targets shouldn’t move out from under your mouse pointer. You could, I suppose, move the sidebar toggle to the right side of the toolbar so it wouldn’t move, but a sidebar on the left side shouldn’t be controlled by a button on the right side. I’m not sure what the solution to this is.
What bothers me is the loss of a very useful checkbox in the Print sheet. I like having the row handles (the dots and triangles) visible at all times on the screen, but I don’t want them in printed or PDF output. OmniOutliner 3 had a check box in the Print sheet that would let you hide the handles. It was a great piece of user interface design, because it was when you were about to print that you were most likely to notice that the handles were visible.
In OmniOutliner 4, that checkbox is gone, and there’s no one-step way to hide the handles before printing. As best I can tell, you have to select the entire document (which isn’t as simple as ⌘A because that selects only the current item) and then click the “hide the handles” button in the style inspector. And you have to remember to do this before you press ⌘P.
I’ve heard from Omni support that the handle visibility checkbox is being reconsidered. It can’t return fast enough for me.
Update 2/4/14
Via Twitter, rolian tells me that ⌘A works if the cursor isn’t actively blinking in one of the rows. This happens when you click outside the content area, either to select an entire item or to hide/show a section. I just tried it; he’s right. You can also type ⇧⌘A (for ) and then ⌘A if you don’t want to move your hand away from the keyboard.
Even better, I just made a Keyboard Maestro macro to run and when I type ⌥⌘A.
The coincidence
As I was writing this post earlier today, this appeared in my Twitter stream:
@DaveStachowiak This is a bit older, but covers all the options: leancrew.com/all-this/2009/… /cc @MacSparky @OmniOutliner
— The Omni Group (@OmniGroup) Feb 3 2014 11:12 AM
The post the Omni folks linked to includes a TextMate macro that I’ve rewritten for BBEdit and was planning to present here. The macro helps me move from an outline to a report.
As I said in that older post, my outlines aren’t strictly a set of section headings and subheadings. They’re a mishmash of section and subsection headings (which I denote using Markdown hashes), full and partial paragraphs, and sentence fragments. After I’ve arranged them into their proper order, they form the skeleton of the report I’ll write in BBEdit, but exporting them as a text file from OmniOutliner doesn’t give a result that’s easy to work with.
For example, exporting the nonsense outline in the first screenshot as a Plain Text file (with tabs) generates a file that looks like this:
Ick. What I want is something that looks like this:
With all the markers and indentation removed and the paragraphs and headings separated by blank lines, I now have a proper Markdown file that I can finish writing. The transformation from Ick to Markdown is accomplished through this Text Factory:
The steps are simple:
- Regular expression search for
^Topic\t\n, replacing with nothing. OmniOutliner 4 no longer shows a column title when there’s only one column, but that title sometimes shows up (with a default value of “Topic”) when the outline is exported as a test file. This step deletes that unwanted text if it’s present. - Regular expression search for
^\s*[-+*](\s\[.\])?\s, replacing with nothing. This deletes all the leading markers, checkboxes, and indentation. It assumes that markers are either a hyphen, a plus, or an asterisk. - Regular expression search for
\t$, replacing with nothing. For reasons I cannot fathom, OmniOutliner 4 puts a tab character at the end of each item in the exported text file. This step deletes it. I suspect this trailing tab is a bug that Omni will squash in due time. When that happens, this step can be removed, and the tab in Step 1 will have to be taken out. - Regular expression search for
\n, replacing with\n\n. This separates the paragraphs and headings with blank lines. - Regular expression search for
^(#+)([^#\n]+)$, replacing with\1\2 \1. This normalizes the headings with an equal number of hashes at the end. This is thoroughly unnecessary, but I like having the hashes at the end. If I happen to include trailing hashes in my original outline, they aren’t repeated.
I suppose I should write a script that goes in the other direction. It would help if I need to reorganize a report I’ve already started writing in BBEdit.
The end
Of our elaborate plans, the end.
