After many months of development and countless blog posts providing you with murky updates on our progress, what else is left to say . . . except SWEET FAT HOT HAM, OmniFocus 1.0 is here!
Yes, OmniFocus has finally shed its beta-ness and it's all ready for prime time. Uh, we hope. I mean, ha ha, we're pretty sure it won't eat your hard drive or anything! We totally fixed THAT bug.
To those who boldly test-drove OmniFocus throughout the beta process, we owe you a huge thanks for all your helpful feedback. Thanks, too, to those of you who sent us feature requests and ideas for how to make OmniFocus the best darned OmniFocus it could be.
It's just going to get better from here: we have big plans for OmniFocus 1.1 - 2.0 in the works. In the meantime, though, we're pretty pleased with how 1.0 has turned out, and we sure hope you like it too.
On licensing:
OmniFocus is now selling for $79.95. OmniOutliner Professional license owners are currently eligible for a 25% discount off the OmniFocus license fee. Quantity discounts, educational, and family pricing are available at our online store.
You can download OmniFocus and use it in unlicensed mode (with no feature restrictions) for 14 days.
Other useful stuff:
• Watch the 15-minute OmniFocus Quick Start Video (180MB, 50MB iPhone version here)
• View our “At-a-Glance” handy-dandy Reference Chart
One more thing:
If you're going to be at Macworld next week, please come by our booth (#602) and say howdy! We'd love to meet you in person and answer any questions you might have. Well, unless they're along the lines of, “Why do you guys have such a lame blog?”, of course.
Got another question from a customer which I thought other folks might be interested in, so up on the blog it goes!
Q: Has there been any progress on index card printing? I've been checking through the New Features lists with each releases, but I haven't seen anything relevant. Have I missed something? It would be really great if I could print to index cards nicely.
A: You can do this, but it's not something that we mentioned in the feature list. What you want to do is set up a custom paper size, then tell OmniFocus to use that paper size when printing.
(This assumes your printer supports printing to 3x5 cards, of course.)
To set up a custom paper size, do the following:
- Open OmniFocus
- Select File -> Page Setup
- In the Paper Size pop-up menu, select “Manage Custom Sizes”.
- In the window that appears, press the plus-sign button in the lower left.
- Double-click the new item that appears in the left column, and rename it to “3x5 Notecard”.
- On the right side of the page, set the page width to 5 inches, and the page height to 3 inches.
- Adjust the printer margins to taste, or leave them on the default values.
- Press the Okay button to close the window and save your custom paper size.
You'll now be taken back to the page setup sheet in OmniFocus. Again, assuming your printer supports printing to 3x5 cards, you can now select your custom paper size in the “Paper Size” pop-up. Press the Okay button.
Do a test print (or preview), adjust to taste, and you're all set to take your OmniFocus info with you all pocket-sized.
Last week, your humble support ninja got this in an email from a customer:
It would be nice to select which tasks/projects I want to have printed out and get some more information on my piece of paper (e.g. dates).
This is pretty easy to do, and I figured other folks might want to do this as well, so up on the blog it goes!
OmniFocus has a feature called “Perspectives” which allows you to set up different views of your information that you'd like to access quickly and easily. For example, I have one perspective saved that focuses on my Support Ninja tasks and another that shows all my completed actions, which flip over to during those “when did i do that task again?” moments I occasionally have.
More importantly, I also have a “To-Go” perspective that shows the contexts for going out and running errands, but not the ones like 'desk', 'office', or 'home'. Whenever I need a new task list, I just switch to that perspective, print my task list, and off I go.
To set this up, do the following:
Switch to context view, then set the window up as you'd like your to-go task list to look. Command-click the relevant contexts to select them, change up the view bar settings, and so forth. Get everything looking how you'd like it to look on paper.
Next, select Perspectives -> Show Perspectives Window from the menu bar. Press the “Plus” button in the lower left. Name the new perspective “To-Go”, or “Printed Task List”, or whatever you'd like.
When you set the perspective up, we add an item for it under the Perspectives menu. From now on, anytime you want to print your task list, just select that menu item and print. We'll apply the settings you specified for you, saving you the effort of twiddling everything yourself.
Pro tip: if the Perspectives window is showing on screen, you can just select the perspective in the window, then hit the quick print button at the bottom. We'll print your list without switching your window to that perspective.
And if you ever want to change how the printout looks, just activate the perspective, adjust how the window is set up, and press the button with the camera icon. We'll save the new settings into your perspective for you.
(One neat trick I used this for - to use less paper, use File -> Page Setup to set the scale to something less than 100%, so you get more tasks on less paper. We'll save that setting into the perspective, too.)
Enjoy!
I just wanted to write a quick note to thank you all for your support! In less than five days, we've already received over $100,000 in preorders for OmniFocus, making this one of our strongest product launches of all time.
We're still hard at work (as you can see if you've been following along with the multiple beta updates we're pushing out each day)—but it's inspiring to see that the time and resources our team has invested into this over the last 16 months has earned your vote of confidence.
Thank you!
BIG NEWS OVER HERE PEOPLE. After over 500 sneaky peek releases, which so many of you have been kind enough to give us feedback on, we are finally drawing the OmniFocus early release cycle to a close, with a bright and shiny final release date in mind: January 8, 2008.
As Ken wrote in his message to the OmniFocus mailing list, “We could probably go on indefinitely in this state: you continue to give us lots of great ideas for ways in which we could improve the software further, and it's hard to resist implementing a good idea when we hear it.”
For REAL. This whole process has taken a lot longer than we had initially guessed, partially because of all the amazing feedback we received along the way. Oh, the spirited conversations that OmniFocus has sparked as we've tweaked the way the application works, and that's just here in the office. I won't get into details, but take it from me: you do not want to use the term “bucket” around here for a while—lest you trigger a frothy-mouthed debate, liberal use of the Caps Lock key, and eventual frantic emailing back-and-forth of walrus images.
Anyway, we've decided not only to commit to a final ship date, but also offer you a special deal. From today until January 8, you can pre-purchase OmniFocus at its introductory rate of $39.95. Once the final version ships, OmniFocus will sell for $79.95—so buy now, and save 50%.
But Omni, you might be thinking. What will I actually get if I buy it now? This sounds like one of those BS marketing schemes where if I buy in the next hour I'll also get a set of steak knives.
Ha ha! Come on, you know us better than that! We would never give you steak knives, because then you might use them to stab us.
If you buy now, you'll get a license that will work in the final version of the software. We'll send you an email when the final version ships, so you'll know exactly when it becomes available.
In the meantime, you can continue to use the beta version, which we're opening up to the general public today. While the betas will still be expiring (so you're encouraged to download more recent versions and not be stuck with bugs we may have fixed), you can easily set your OmniFocus preferences to automatically grab the most recent builds.
Also, if you are an OmniOutliner Professional license owner, you get an additional 25% discount on top of the current introductory pricing. Quantity discounts, educational, and family pricing are all available on our online store.
Thank you for helping us make OmniFocus such a great piece of software, and thank you for your patience during our development cycle.
And now, the relevant links:
Linda asked lil' ol' me to provide the second post in our ongoing OmniFocus: What We've Learned So Far series. Whether she will come to regret this, only time can tell. Without further ado, the post beginneth thusly:Okay, I'm long-winded; sue me. Before I can really tell you how well the OmniFocus test process is going, though, I feel like I have to supply a bit of background on how we've handled this process for previous projects. It went a little something like this:
- Development team produces build of application OmniFoo they're mostly happy with.
- Marketing Weasel writes press release, webmaster nee Web Editor updates site with brand-new OmniFoo Beta page. We push new version of website.
- VersionTracker, etc. pick up on new build.
- Support Ninjas are crushed under a big pile of electronic mail for the next three months. All that is heard from them is a soft but desperate honking noise. Think baby penguin at the bottom of a deep ice-crevasse.
This has a couple of negative effects: first of all, when you're buried in raw oscillating electrons up to your neck, it's really hard on the skin; not at all like that 'drink from the glowy pool of water' scene in Tron would have you believe.More seriously: we get plenty of eyeballs on the new application, which is a good thing. Unfortunately we also got all those eyeballs on the new app at the exact same time. So that thing that's forehead-smackingly obviously broken (which, of course, we failed to catch in the gajillions of hours we spent staring at the app before we pushed it out) gets reported 200 times.Now, the first report of an issue? Good. The tenth? Gold - then we know that this isn't random gremlin activity; there is something here we need to figure out. This holds up till, oh, somewhere between 30 and 50 reports. Beyond that, it's a problem we know about, that we know we need to fix, but from there on out the additional utility of the reports drops off fast. The time it takes the Ninjas to process them doesn't, however.Result: stressed-out ninjas, frustrated engineers (because they're not getting reports of the problems in the newest builds; we're still looking at launch day reports), and the folks with the test builds are having to wade through issues that we haven't fixed because we're still sorting and writing up reports.In short, it works, but it's painful for everyone involved. So this time, we did something better. Process this time:
- A couple months before we're ready to start testing, let folks know we'll be ready to start testing in a couple months. Set up an email list to join if they'd like to participate.
- Produce build of application we're ready to start testing.
- Make build available to some of the folks on said list.
- Fix the problems they find, including forehead-smackers.
- Return to step 3, above.
Advantages: Many. We get feedback in manageable quantities. Testers get fixes that bear some resemblance to their reports. Support ninjas get fewer ulcers. World shares cola beverage, sings in perfect harmony.What do we need to do differently next time? To begin with, we need to give customers the ability to help us prioritize their mail, by at the very least sorting it into “bug report”, “feature request”, and “oh god, where is my download login” buckets. The other thing? If we choose to implement any more apps based on the current 800-pound gorilla of personal productivity methodologies, I'm just going to start hiring and never, ever stop. ;-)Which, of course, provides me with a perfect opportunity to link point interested parties over to our
Want Work? page, newly updated as of yesterday.
Just a quick reminder to let you know that the OmniFocus evening event at Tekserve on the 27th has a few spots still open, so if you're interested in coming by (there will be food! And beverages! And possibly an interpretive dance performance!*) please make sure to sign up ahead of time.*Well, probably not. Hopefully not.
Today's post is the first in an ongoing series I'm calling OmniFocus: What We've Learned So Far (or OF: WWLSF, if you prefer acronyms). As we move slowly but steadily towards a feature freeze and public beta, I thought it would be interesting to get some input from various people here at Omni on things that have gone well, as well as things that have sucked challenges we didn't anticipate—basically, the ups and downs behind building a piece of commercial software.
We're going to start out in the technical arena, so I apologize if code-talk makes you yawn so hard you accidentally drool a little. Here is Omni's engineering perspective on an important lesson learned during OmniFocus's development process, which can be boiled down to: we ♥ CoreData, but not as a primary file format.
With more on this subject, here is Tim Wood, hater of Aeron chairs, terror of the Unreal Tournament battlefield, and OmniFocus team lead:
There are many things that are great about CoreData, but using CoreData as a user-visible file format was really painful. Since inception, our xcdatamodel file has had 92 revisions, with most of those exposed to several thousand people via our automated builds. Most of these changes aren't things that users would notice; we often add or remove precalculated summaries, denormalize data or generally change the underlying CoreData representation to make our app easier to implement and tune. Yet, with CoreData, the SQLite mapping would be busted beyond hope by adding or removing a column.
Manually building code to migrate between model versions is really not an option. If CoreData had a Rails-like migration facility where columns could be added and removed trivially via SQL ALTER statements, it might be feasible, but it still wouldn't be good. CoreData explicitly disclaims any support for direct access to the various stores, so it isn't a public file format and hinders our users from easy access to their data. In practical terms, we all know that a liberal application of the letter 'Z' will get you most of the way to accessing your data. Still, this isn't ideal.
What CoreData is great for is building an optimized cache of your data, fetching against it and then binding it to your interface.
A couple of other key observations are that we already needed a public file format for Export (we chose a custom XML grammar, but that's merely a detail). And, using a variant of the public file format for the pasteboard format is a great way avoid writing and testing more code (as is using your pasteboard archive/unarchive code to implement your AppleScript 'duplicate' support…)
Given that, I tweaked our XML archiving to support writing a set of CoreData inserts, updates and deletes as a transaction. We can then write out a small fragment of our content in a new gzipped XML file inside our document wrapper. The structure of our XML transactions is very simple with a key feature being that we can trivially merge a big batch of transaction into a single XML document that contains only the final set of objects as inserts.
On startup of OmniFocus, it scans the transaction log in the user's document and builds a cache validation dictionary that contains:
• Version of Mac OS X
• CoreData's version
• SVN revision of the application
• The last transaction identifier
We then open up the CoreData SQLite persistent store and peek at its metadata. If it isn't an exact match, we close up the persistent store, and rebuild the entire thing by importing our coalesced transaction log in exactly the same way we would import one of our backup files.
There are many extra implementation details (locking, catching the insert/update/delete notification, undo/redo vs. AppleScript, two-phase commit between the XML and SQLite, ...), but we are really happy with the central approach.
Some of the fun things this gives us:
• You can run the same build of the application on 10.4 and 10.5, switching regularly and not worry if CoreData is going to ignite your SQLite store.
• You can run multiple builds of OmniFocus on the same data and not lose anything (more work may be needed for major file format upgrades if there ever is one).
• If we do screw up one of our automated builds and mess up cache updating code, the user's data doesn't get touched and it's just fine on the next build.
• Until the transaction log is compacted, we actually have the full record of edits and we could hypothetically implement persistent undo, allowing the user to rollback to yesterday's version…
• ... or calculate the changes they've made since some point in time.
The last point is really interesting and I'm hoping to make good use of that in the future for things like computer-to-computer synchronization (no, I'm not promising anything)!
If you live in the New York area, I hope you'll come by the uber-popular independent Mac shop Tekserve on September 27 around 8:30 PM for what is shaping up to be a very cool event featuring OmniFocus. Merlin Mann will be there, schooling you on how to get all productive and organized and smelling minty-fresh, as well as our own Ken Case and moving-gods-willing, Ethan Schoonover.
Random Trivia: Tekserve was once featured on Sex in the City. And now I've used the word “sex” in the Omni blog, which is frankly something I never thought I'd find myself doing. Well, other than “sexy”, as in “boy howdy them Omni apps shore are sexy-lookin”.
ANYWAY, directions to Tekserve can be found here, and more information about the seminar is posted here. We hope you'll join us if you're able to do so, it should be both educational and fun. Funducational!
**Update** Please note you'll need to register for this event, here's the handy link for doing so.
You may have read this over at 43 Folders, but for anyone who missed it, we're super-thrilled to announce that Ethan Schoonover is going to be joining The Omni Group in the next few weeks. As some of you know, we've been working with him for quite a while during OmniFocus's development, and having him actually in the same building as us is going to be awesome.
Well, awesome for us, anyway. Ethan's probably going to run screaming after a day or two. Oh ha ha ha, I kid, we're not that bad.
(ETHAN: YOU MIGHT NEED A LOT OF BEER).
Ethan will officially be on board at the start of September, he just has to move his family and belongings from Hong Kong to Seattle first. Which should prep him nicely for the feat of helping us heave OmniFocus towards a final ship date.
And speaking of OmniFocus, we have another good bit of news: we're all caught up with issuing sneaky peek invitations, and we've configured the mailing list to automatically send invitations within 24 hours of signup.
It almost sounds like this is now a public beta, doesn't it? Not quite yet. As I understand it, the reason we're not just making everything instantly available—without the added process of joining the list—is that first we want the app to be stable enough so that people can download it once and not worry about updating the build. Currently, the sneaky peek page has the last 5 builds available at all times, and we're encouraging everyone to continually get new updates.
If you'd like to give OmniFocus a try, you can certainly do so—just keep in mind that it's still a work in progress and you'll probably need to stay on top of the new versions we keep posting. That way you have access to the latest bug fixes, new features, improved UI, and occasionally, things that are horribly horribly broken in a number of mysterious and painful ways. O, the joys of building software!
On the other hand, if you'd like to wait until we release a version that you can use for more than a few days at a time, hang in there for the public beta. The timing remains uncertain, but we are certainly working our butts off on reaching that milestone.
I should clarify that by “we” I mean “everyone except the office cat” because her main job lately seems to involve producing repulsive horked-up hairballs in various, easily-stepped on places throughout our offices. And with that:
Welcome, Ethan! We're so excited to have you. Watch out for cat barf.