Blog

Five-Minute Workshop Videos

Posted by Bill Van Hecke on 02.07.12 | 3 Comments

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.
Enjoy!
Design Report: OmniOutliner for iPad Styles

Posted by Bill Van Hecke on 08.16.11 | 3 Comments

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?”
Slay the Leviathan Context

Posted by Bill Van Hecke on 06.24.11 | 10 Comments

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.
OmniFocus 1.8 Design Report

Posted by Bill Van Hecke on 09.15.10 | 28 Comments

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!
Helpify 1.5: Help Us Help You Help Users

Posted by Bill Van Hecke on 12.21.09 | Comment

Hello! It's kind of strange to think that it's been over a year since I first posted Helpify. If you haven't met it, Helpify is a tool for Mac developers to generate Apple Help Books for their software. We use it here, of course, and it has seen a bit of popularity outside of Omni too.

Version 1.5 incorporates a lot of improvements that were suggested (or written!) by kind folks in the Mac community. This time around, Daniel Jalkut of Red Sweater Software was especially helpful in making sure our indexing process works equally well on Snow Leopard and earlier versions of Mac OS X.

And thanks to Automator, Helpify is now an applet, not just a command-line script. You can drop your source outline right on it. Other new niceties include variables stored inside the source outline instead of inside the script, and better handling of anchors that appear at the top of a page.

I hope you find this new version of Helpify useful. Please let us know what you think!

Update: Version 1.5.1 fixes a problem parsing the special Variables section. Thanks to John Alexander for pointing it out.

Update: Version 1.5.2 fixes a problem with setting up the Box style and with a bogus link to a Variables page on the last page. Thanks to Nicholas Riley.

Download Helpify 1.5.2
OmniGraffle and Photoshop: One Great Taste and One Acceptable Taste that Taste Great Together

Posted by Bill Van Hecke on 12.15.09 | Comment

Did you know that Photoshop files can be dragged straight into OmniGraffle documents? It's super true! I've been taking this for granted, but it was a lovely surprise when I tried it on a whim and it, yeah, "just worked".

That one discovery pretty drastically improved my interface design workflow. Before that, having to export to PNG for every change to any graphic in a mockup meant that I didn't go into Photoshop very often, and I used OmniGraffle to create graphics whenever I could get away with it. Well, OmniGraffle is a superb diagramming app, and it can even hold its own for a lot of graphics work, but it's not Photoshop. Sometimes you just need those layer styles, shape layers, and masks.

Here's how I've been doing it:
- Working on a mockup in OmniGraffle, realize I need a graphic.
- Switch to Photoshop, create the graphic, and save the file.
- Click and hold on the document icon in the Photoshop window's title bar, then drag it to the OmniGraffle canvas.
- Take advantage of OmniGraffle's guides, alignment controls, grouping, tables, and other conveniences to arrange things just right.
- If the graphic needs to change, make the adjustments in Photoshop and save again.
- Just drag the new version right on top of the existing object on the OmniGraffle canvas to replace it.
The screenshot is an actual in-development inspector design for a future Omni product! (With all of its text replaced by neologisms from Finnegans Wake, of course.)
Helpify, the Omni Help Emitter

Posted by Bill Van Hecke on 10.02.08 | 7 Comments

Hello, friends. One of my jobs here at Omni is creating our documentation, including onscreen help in the Apple Help Book format. Over the years I have been building a Python tool that turns specially-formatted OmniOutliner 3 files into proper help books, which can then be dropped into an app. This is pretty useful for “single-sourcing” our help and manuals. If you, too, would like to author your help in OmniOutliner, with automatic formatting, indexing, and navigation, you may want to try it out.

Download Helpify.zip

The included outline acts as documentation and as a starting template. If you have any feedback, or you’d like to help improve my decidedly un-engineer-like code, please let me know at helpify at omni group dot com.

Update: Version 1.1, uploaded October 31, 2008, includes code cleanup, a company web site variable, and the ability to use Helpify as a module for other Python scripts. Many thanks go to Matteo Rattotti of Shiny Frog for his feedback and patience.

Update: Version 1.2, uploaded November 18, 2008, includes a bit more cleanup and much better handling of Unicode throughout the source outline. Thanks to Markus Müller of MindNode for his feedback and patience.

Update: Version 1.5 was uploaded December 21, 2009. See the new blog post for details!
OmniGraffle for Bureaucracy

Posted by Bill Van Hecke on 03.09.07 | Comment

Good day.

It took me a while to realize this, but almost every time I need to put some kind of stuff on a page, and it makes a difference where on the page that stuff is, OmniGraffle ends up being the best tool for the job.

Let me 'splain: OmniGraffle might not be the first thing that comes to mind when you need to fill out some official forms for the U.S. Government. Or, say, some character sheets for your weekend Dungeons & Dragons session. But it should be. Check this out:
- Grab an electronic version of the form you need to fill out. Scan it if you have to, but most official forms are available as PDFs these days. Some of them even claim to be fillable, but I've never gotten them to work properly in Preview or Acrobat.
- Copy each page from the document (in Preview) and paste it onto a fresh OmniGraffle canvas.
- For each canvas, lock the layer that has the form on it, and create a new layer for your information.
- Make text objects all over the canvas to fill in each blank. Once you have a text object you like, you can Option-drag it or paste it all over and just replace the text.
Why this is so much handier than filling out forms by hand:
- You can use the alignment inspector and smart guides to make sure everything is lined up just right and perfectly legible.
- If some of the boxes are really tiny, you can play around with the font to get everything to fit in there just right.
- Filling out the same info over and over is easy: just copy and paste the existing text objects with the info you need.
- Once you've saved the file, you automatically have a backup copy for reference or revision.
- You can make an OmniGraffle template that has the right paper size, two layers per canvas, and a nice grid for keeping things orderly.
When I was going through the process to get someone a visa to live in the USA, this technique saved me heaps of time and stress. And now I have backups of every form (there are lots of forms involved).

Have you found any weird or unexpected uses for Omni apps? Maybe next time I'll tell you about how I'm using OmniGraffle as a level editor for a video game I'm working on...
OmniPlan 1.1 beta 4

Posted by Bill Van Hecke on 03.08.07 | Comment

This beta release contains plenty of stability, import/export, printing, and AppleScript support improvements. We have completed the AppleScript changes that were planned for 1.1, so if you run into any problems there, be sure to let us know.

Please keep in mind that this release is still under development. Your feedback will help us improve the software, and we apologize if it crashes, corrupts your files, steps on the piano keys at night, or otherwise misbehaves. A more stable release is also available.

As always, please let us know if you have any questions or comments. You can contact us directly via our support page or by using the Send Feedback command in OmniPlan's Help menu.

Download and enjoy.
Pillow Dock

Posted by Bill Van Hecke on 12.06.06 | Comment

Our newest support ninja Michaela brought in some pillows that her friend Roberto spent the last several months crafting for her. Mac nerds can't be content with a row of regular pillows on the couch, no, no way. Our decor needs to resemble graphical user interfaces whenever possible! Behold, Michaela's dock in cushiony fabric form!

More (more better) photos are available at Roberto's site.