The Omni Group

Oh, you guys. I am so glad I don't have to start this post with anything other than this news:

OmniFocus for iPad is now available on the App Store.

It took longer than we anticipated to get here, and we're sorry for the frustration. Reminder note to selves: it's definitely hard to predict exactly how long it will take to design and build something no one has designed and built before. 

Our development and UI team deserve a huge amount of praise for the long hours they put into getting this release together. Thanks to the documentation folks and the video team for chasing a moving target in order to provide some how-to info on day one. Shout-out to Ken Case, who tried his best to keep you all in the loop on our progress, even when it became increasingly difficult to do so.

I hope you enjoy this app as much as we do. With the new task Forecasts, Map, built-in reviewing, and an entirely redesigned interface, I think there's a lot to love. But don't take my word for it: visit the OmniFocus for iPad website to learn about the features. Watch the overview video to see it in action.  And, of course, grab your own copy at the App Store. 

Thanks for hanging in there, folks. We're eagerly awaiting your feedback. 

[Last update: 7/29]

Hello, everyone!  Remember back in iPad or Bust when I said that our natural inclination is to be open about what we're doing, but that there were several problems with talking about future plans?

Well, I'm running smack into one of those problems right now:  we were hoping that we'd be ready to submit OmniFocus for iPad to Apple on June 30, and we shared that date last week. It's wonderful that everyone is so excited about that date, but I need to remind everyone that June 30 was never intended as a promise—it was simply our best estimate at that moment.

The team has been working around the clock on this for quite a while, and we made a very big push over the weekend. We're in that part of the development cycle where it's hard to predict exactly how soon we'll be done. The app feels very close—but tomorrow is closer.

Just in case you're still wondering "So when will OmniFocus for iPad be ready?"—I'm afraid I don't have anything else to suggest beyond what I just said:  we're working around the clock, and at this stage it's hard to predict exactly how soon it will be done. We're still testing the app and we don't know what issues we'll uncover or how long those issues will take to fix.  So, again: it feels close, but tomorrow is closer.

Sorry, I know this will be disappointing news for many of you—it's certainly disappointing for us. But we think the time put into the final product will be worth it: thank you for your patience. If you have any questions or concerns, please feel free to contact me directly at kc@omnigroup.com.

7/12 UPDATE: Sorry, I know the wait has been hard for everyone. (It's been hard for me, too!) This weekend I invited several people to help us beta test OmniFocus, and their feedback has been overwhelmingly positive. I have to keep reminding myself that Le mieux est l'ennemi du bien, "the perfect is the enemy of the good," and that "not shipping" might be a worse flaw than a missing feature that we'd really like to implement. (After all, there's always 1.1!) To that end… I've been sorting through a few hundred bits of feedback to decide which issues and suggestions are important to address for 1.0 and which ones can wait. I'm about half-way through the list, and will post another update soon.

7/16 UPDATE: We've reached a big milestone: we've declared feature and UI freeze. The documentation is written, we have an intro video and welcome document, and so on. But we're not quite done yet: we're still tuning performance and memory usage, fixing glitchy animations, and eliminating crashes. Our test pilots are busy finding problems so you won't have to.

7/20 UPDATE: Code freeze! Release candidate tagged and built, it just needs to be put through a (hopefully final) round of testing.

7/21 UPDATE: Submitted to the App Store!  (I know they're very busy, but according to Apple's latest stats they review 85% of new apps within 7 days.)

7/28 UPDATE: The clock is definitely ticking, but there are still about 12 hours for OmniFocus to remain part of the 85%.  If you'd like to be notified by email the moment OmniFocus is available on the App Store, subscribe to our low-traffic OmniNews mailing list.

7/29 UPDATE: Expecting App Store approval at any moment. If we receive it between now and 6am tomorrow (Pacific Time), that's when we plan to release.

Hello, esteemed Omni blog readers! We have two bits of news for you today, both OmniFocus-focused. 

BIT O' NEWS THE FIRST

OmniFocus 1.7 for iPhone is now available! The big changes are related to iOS 4: the app is now multi-tasking aware, so it's compatible with the fast app switching in iOS 4; database optimizations can now be completed in the background on iOS 4, and OmniFocus 1.7 now uses local notifications to display due alerts when running on iOS 4 (giving you the option to receive alerts for due tasks, even when you're not syncing with a server). 

Also, all the artwork has been refreshed in preparation for that fancy new high-resolution Retina display on iPhone 4. Plus, the app now periodically releases the magical and revolutionary scent of mango. (One of these statements is not true.)

If you're like me and haven't updated your phone yet because you like to wait until everyone else has already done it and you can confirm there are no reports of people saying things like "ARGH MY RINGTONE GOT REPLACED WITH A VUVUZELA", you should grab this latest version of OmniFocus anyway, because it also includes some handy fixes and overall improvements. 

OmniFocus 1.7 for iPhone can be found at your friendly neighborhood App Store.

BIT O' NEWS THE SECOND

Some of you have expressed interest in an update on the projected release date for OmniFocus for iPad. Interest has been communicated in a variety of ways: gentle email queries, polite forum discussions, and of course there was that brick that got tossed through our lobby window wrapped in a note reading YOU SAID JUNE YOU DILL-WEEDS WHAT GIVES.

Here's our current plan: we are hoping to submit OmniFocus for iPad to Apple next week, on June 30. I emphasize hoping because it's not a certainty and this date was extracted with great reluctance. Many Bothans died to bring you this information.

We wish you could get your hands on it right now, but as tempting as it is to rush it out the door for all the folks who are waiting for it, there's still work that needs to be done. I've been using the development builds and it's really exciting to see how things are coming together. It's very close to being ready, at this point it's all about fixing the rough edges and working on the UI.

When I say that, I don't want you to get a mental picture of engineers arguing over the pixel placement of one button. I mean, I'm sure that happens—ha ha ha, ENGINEERS—but I'm talking about a giant effort to influence how you feel when you use OmniFocus. This app needs to be more than a place to store your to-dos, you know? It needs to be a pleasure to interact with. It needs to be a place you want to go on a regular basis. It needs to be satisfying. 

I believe there are some features in OmniFocus for iPad that have the potential to change the way some of us feel about task management. Specifically, for people like me who are lazy about committing to a task manager and repeatedly fall off the wagon, I think this could be the perfect combination of app and device that keeps us engaged.

But we have to do it right. If I don't enjoy opening the app and interacting with it, I won't stick with it. Simple as that.

So, all that's to say: we're close. We're really, really close. This part is mission-critical, though, and we hope you're okay with waiting just a bit longer. We're pretty sure it's going to be worth it. 

After a beta testing period that got somewhat interrupted by WWDC and submitting OmniGraffle 1.2 for iPad to the App Store, we're happy to announce that the final versions of OmniGraffle and OmniGraffle Professional 5.2.3 are ready and available for download.

For those not following the beta releases, version 5.2.3 fixes some important bugs with respect to Bézier lines and how they connect to shapes, fixes some important issues when exporting to other formats, and adds file management options when exporting to various OmniGraffle formats to better get your files working on the iPad.

Find the disk images at our download page, and read up on the lengthy history of OmniGraffle at our historical release notes page.

Testing of OmniGraffle 5.2.3 beta 2 went well over the last two weeks, so we're ready to go for a release candidate. As is usual policy around here, we'll let the RC bake for a couple of weeks and then go final if nothing bad happens.

Disk images and release notes covering the history of version 5.2.3 can be found at the bottom of the OmniGraffle download page.

Say, have you ever found yourself trying to mock up a website with only a wet piece of toilet paper and a broken crayon and it's not fun at ALL because because the crayon is that cruddy "atomic tangerine" color and the toilet paper is one-ply and you are, like, totally building the worst website ever?

Well, have we ever got a handy video for you, then! We just posted our latest video overview, which is a mere 2:32 of your time but nicely covers the basics for using OmniGraffle for iPad to create website wireframes. This video is not only handy and informative, it also features the smooth vocal stylings of our wonderful Support Ninja and Talented Video-Maker, Kris. 

Take a look at the video here, and if there are other topics you'd like to see us cover—for OmniGraffle for iPad or any other app—please let us know!

Update: I've added some comments about the -[CALayer shadowPath] approach that I missed before.

I've just pushed a new sample to the OmniGroup? source on github which shows several drop shadow approaches, with an eye towards performance, particularly while the shadow casting object's frame is being animated. One of these is a pair of functions vended by OmniUI, OUIViewAddShadowEdges?() and OUIViewLayoutShadowEdges?(), which originate from writing our document picker. In this case we want to be able to smoothly animate between two apparent view sizes as you open and close documents.

Opening up OmniGroup/Frameworks/OmniUI/iPad/Examples/DropShadowOptions? and building, you'll see a set of options that control the testing:

Animation Type

• Resize: The size of the object changes, possibly leading to it being redrawn.

• Slide: The object simply move, which may allow optimized screen rendering by compositing a previously cached backing store.

Animation Driver

• One-time change: Some one-time programatic change is being made to the object that has a starting and ending state. These are driven by UIView animation.

• User interaction: This simulates multiple successive small changes, as if the user were performing a sequence of dragging touches (like resizing a shape). These are driven by a timer, simulating events from the user.

Shadow Options

• CoreGraphics, resampled: This renders the shadow into the view's content area with normal CoreGraphics calls. When the view's size changes, the content is not redrawn, but the previously created backing store is just scaled. If the change you are making is temporary (like a small zoom in/out bounce animation), this could be imperceptible to the user. One problem with the CoreGraphics-based approaches is that some of your content area is taken up by the shadow and positioning elements within your view needs to take this into account.

• CoreGraphics, redrawn: The shadow is drawn into the backing store, as above. But, each time the view's bounds changes, a new backing store is generated. Note however, that UIView animations only generate a backing store image for the starting and ending frame and interpolate between them. There is not a new image generated for each frame of animation. This yields good performance for one-time, animations.

• CALayer Shadow: CALayer provides shadowing options with the shadows being cast outside your content. This makes performing other geometry calculations simpler (like positioning sublayers) since you can turn on the shadow and forget about it.

• CALayer Shadow, rasterized: Normally, CALayer shadows are built at the time that the layer is composited to screen. That means, each time you even move a layer, the full shadow needs to be recomputed. But, CALayer provides an option to request rasterization, which is enabled in this case.

• CALayer, shadow path:(not shown in screenshot above since this was added to the test later) This uses the shadowPath property on CALayer, which improves the performance of shadow rendering by allowing the layer to assume that the interior of the path is opaque (rather than having to convolve the alpha channel of the layer's contents). Sadly, UIView seems to disable implicit animations for this property, and you need to be careful to share or reuse CGPathRefs. With this extra bookkeeping, it is a bit of a pain to use, but nice and speedy.

• OmniUI Shadow Edge Views: Given a UIView, these OmniUI functions add four thin views along the edges of your view. Each has a three-part stretchable image that renders the shadow. This takes advantage of the CALayer contentsCenter property to avoid even needing to re-fill the shadow edge contents on a resize. Like the CALayer approach, these views lie outside the view itself, simplifying the positioning of the content within the view (or other geometry calculations, in our case, calculating the animation parameters when opening or closing documents).

Performance

Running this app under Instruments with the Core Animation tool, we can check out the relative advantages of each approach. Instruments doesn't give a precise frame rate over time, but really we don't care. In the real world, you'd have other work to do during a live-resize of an object, so anything here less than 60fps (for just the shadowing) is likely too slow.

I'll call out the one "Slowish" result; this timed at ~45fps on my iPad. CoreGraphics shadowing is amazingly fast — nice work. Still, depending on the rest of your workload during the resize, "pretty fast" may not be good enough.

Conclusions

The default behavior of UIView/CALayer is great for simple situations. If, however, a user is dynamically interacting with an object that casts shadows and you want that object to not get blurry as it resizes, CoreGraphics may not be as fast as you'd like (obviously the rasterization or relayout of the inner content matters too).

Don't turn on CALayer shadows unless either enable rasterization on and aren't going to be changing the view's size, or are willing to do the extra bookkeeping to maintain a shadowPath. Generic CALayer shadows are stunningly slow if all you need is a rectangle, but the shadowPath hint makes them very zippy.

Finally, what does the OmniUI shadow edges approach tell us? This particular hack may not be useful in your app, but the core idea is that you shouldn't do work you don't need to do. When resizing axially aligned, opaque objects, we don't need a fully general shadowing algorithm.

We can deceive the user into thinking a real shadowed object is floating in their view, but we don't have to implement it that way. On a "magical" device like an iPad, you need to act like a magician: as long as it looks like something visually complicated is really happening, then your job as illusionist is complete.

After a beta period that was a little longer than expected thanks to that pesky tablet, we're ready to go final with OmniGraphSketcher 1.1.1. If you participated in the beta, you already know that we've added Japanese and French localizations to OmniGraphSketcher. We've also improved support for international number formats (both for importing and display) and made lots of other tweaks and fixes.

OmniGraphSketcher 1.1.1 is available on our downloads page or via software update. Release notes are available in the usual spot (as well as the Help menu). As always, please don't hesitate to use the Send Feedback item in the Help menu, or email us with any questions or feedback.

We've added a couple of small fixes in this beta release, one that has to do with canvas names being incorrect on an export to HTML imagemap that was due to a different fix in beta 1, and Bézier lines should be back to normal, with the addtition of routing better according to their control handles when both endpoints are in the same location.

The beta's at the bottom of the download page, as are the release notes, short as they are.

Page 10 of 52 pages ‹ First  < 8 9 10 11 12 >  Last ›