THE OMNI SHOW

Andrew J. Mason:
You're listening to The Omni Show, where we connect with the amazing communities surrounding The Omni Group's award-winning products. My name's Andrew J. Mason, and today we hang out with Ken Case talking about the 2023 roadmap for The Omni Group. Well, welcome everybody to this episode of The Omni Show. My name's Andrew J. Mason, and today we have the legend Ken Case with us in the house. Thank you, Ken, so much for joining us.

Ken Case:
Thank you, Andrew. I'm excited to be here.

Andrew J. Mason:
Man, I can't wait to dive into this good stuff. 2023 is looking so exciting. But even before I go there, I want to talk about 2022. It was a big year. We celebrated Omni Group's 30th anniversary. So cool. Talk to me a little bit about the way that Omni Group has interacted with its community and how that's changed over the last 30 years. What does that look like and how does it look like today?

Ken Case:
Sure. As I was thinking back on doing this for 30 years, I was thinking about how we used to talk with our community 30 years ago before we had the worldwide web on most people's desks or even in their pockets. Well, most people were not yet on the internet. We would maybe see each other at a conference once a year or mostly we would interact over mailing lists, sometimes over the Usenet newsgroups, things like that. There were, of course, some chat systems around back then, the Internet Relay Chat. I was involved in some of the predecessors to that, like the BITNET Relay Chat and so on.

Quite a lot of change over the decades. Seeing, of course, the rise of various big central sites for people to gather, whether that was AOL, which I was never on personally, but I saw this happening over in the side. Well, the community that we were interacting with wasn't so much on there. We were this alternate community of federated email sites and so on, instead of a big central place where all this stuff is hosted. We've seen these things rise and fall over the decades, often the last for a good 10 years or something, but then sometimes it's time for a shift and something else comes along. It's been fun over this past year I think to see.

We've certainly enjoyed Twitter over the last 15 years of using it, but it's been fun to see some alternatives. Over the past year, we've had this rise of the "fediverse" with Mastodon and other services linking together. Instead of it being just a single centralized communication place, it's a bit more like the web itself or like email where you can have different software running in different places with sort of a different flavor to it, but they can still all communicate with each other. I think that's a really good basis for building system like this.

Andrew J. Mason:
What I love is that it almost doesn't even matter what the method, the vehicle is. That there is this common bond that unites us. We all want to see ourselves be as productive as possible. We all want to make the software as good as possible, whether that's using that 30 years ago to more recently co-creating with this really rapid feedback loop in a place like Slack. Talk to me about why that's important for people.

Ken Case:
Well, I don't know whether the listeners think it's important, but it's certainly important to us. Otherwise, we can get lost not knowing what other people need from us. If we're not listening to the community around us, how do we know what is important to the people we're trying to build this for? It's really important, I think, to be able to listen, to hear those stories. On that note, I should congratulate you for The Omni Show's 100th episode that came out a few months ago.

Andrew J. Mason:
Thank you, Ken.

Ken Case:
Of course, this podcast is one of the ways that we try to connect with our community and hear some of those stories.

Andrew J. Mason:
Thank you, Ken. I appreciate that. I'm honored, of course. One of the reasons I love this team and this community is that we really take seriously listening to people, like actually listening to them. I think in society sometimes we glorify the Steve Jobs figure, not him himself, but just this figure of like I know what the customer needs. It's an iPod. It has one button. And the customer doesn't even know what they need until they see it, and then there's this aha moment where they understand, "Oh, this is how it should have been all along."

I think for every one of those, there's thousands of use cases where no, you really should be listening to the customer or the person that's using the software because they know better than anybody. I think people can tell. A community of people knows when somebody listens. I remember last time we talked, Ken, you mentioned opening up the test flight for OmniFocus 4 and over 7,000 people jumped in and just wanted to kick the tires and see what it was all about and provide feedback on that process and how useful that is that we're able to in real time with tighter iterations be able to see what's working, what isn't working, and develop in the right direction.

Can you speak a little bit about what's happened since those 7,000 people have signed up and where that process has gone?

Ken Case:
Sure. Well, of course, we've continued on with plenty of TestFlight builds since then. I don't remember exactly when we last talked. I think we had not yet done the Mac test bite. Matt brought in a bunch of new folks, of course. When it's available in more places, then more people are interested in checking it out. We filled up. We hit the 10,000 limit the test flight has for how many users there are, and then we went back. Okay, who hasn't been active necessarily for the last few months? Some people check it out and they decide, okay, I'm going to wait now for the final release. I don't need to be in the process the whole time.

Maybe they gave some early feedback and then they're gone for a while, but they're still taking up a spot there in that thousand. We cleared it out, went through several rounds of that, and we keep bumping back up to that limit. It's nice to see that people seem to really be engaging with it. We're hearing good feedback from customers about how frequently in the past they have gone from OmniFocus to another tool. And then the other tool doesn't quite do what they need, so they come back to OmniFocus. But something ends up being a little frustrating for them and doesn't feel right. They feel like, well, maybe if I switch tools again, I'll find what I'm looking for.

This back and forth. But more recently, we've started seeing feedback like... Ainsley just shared one from Reddit where somebody said, "I was doing that for years, but now with version four, I've been on it the last year plus and it's great. I don't need to keep looking because I think Omni Group has finally hit all the right notes," or whatever.

Andrew J. Mason:
Gosh, that's really satisfying feedback to hear because if there's a software that's better going to serve your needs, I want you to use that, whatever's going to help you be the most productive. But for somebody to say, "Hey, I've looked everywhere. I've tried everything, and I've come back to home base, and this is just it for me now that these changes have been made," and that we've been listening. That's that's really cool to hear. I'd love to throw the question your way. I always tell people, when you're doing an interview, you get one free selfish question no matter what or who the guest is. I'm going to ask a question purely for my own benefit.

Ken Case:
Sure, yeah.

Andrew J. Mason:
More than one question, that's not good. That's kind of selfish, but just one question. Anybody can do that. I was thinking earlier this week about the 30 year anniversary and just over time the staying power that The Omni Group has had. There's a temptation in our culture, I feel like, to go for the shiny thing, the instant gratification, the alert system. Something pops up, I got to look at it. The attention switching. Just there's so much that leans in that direction in our culture or just in our world at large, I guess.

I feel like some of what's made Omni successful is this willingness to push all of that at bay and say, "We're going to intentionally work on, focus on the things that are high value. Maybe not as urgent, but definitely as important." There's a tension there, because it's never really done, but it is just finished. I so appreciate that our team is willing to do the marathon and not the sprint. I realize I'm rambling a little bit.

There is a question hidden here somewhere, and I'm not even honestly sure how to frame it, but just this idea that speak to that slice where it's as a team, we're intentionally developing software and not just looking at the thing that's happening the second. Does that play into why The Omni Group has had so much staying power that it's had?

Ken Case:
Sure. Well, I think we have several advantages over... I guess part of it is longevity of experience. It's kind of seeing fads come and go and knowing that what we're trying to do is something that's a bit more lasting than that. And that our goal is not simply to grow our audience as fast as we can or to make as much money as we can. We want, of course, to make enough money to be a sustainable business, but all of that is in service of trying to make the best products we can. By products in this case, what I really mean are tools that magnify our potential as humans with brains.

Steve Jobs had this concept that he talked about, which I referenced as one of our inspirational touchpoints that we think back on quite a bit, the computer being a bicycle for the mind. I think we probably talked about this actually in that previous podcast episode, so I won't go back over all of that again. But that notion that we're building tools that help people be more productive, accomplish more with less energy. That can be mental energy, it can be time investment, all of those things. If you can accomplish more with less work being done by your brain, then that's what we find to be useful.

Those are the things that we're looking for. We're not looking for what is the latest fad of something. We're looking for, okay, does this actually let me do more with less attention? I mean, sometimes those stats have good reasons for coming into existence. Maybe you want to clean up the interface a bit. It's gotten too busy. A fad with a cleaner design with these extra distractions out of the way does make sense. But sometimes those things will go overboard as well. I can't say that we're immune to that, right?

We will follow some of these things a bit and then we'll say, "Well, but did that really serve the goal of is it now easier for people to approach the software and do what they're trying to do and understand what they're doing? Or did we take away the guiding points that can help them navigate and now it's too easy to be lost because it got too clean as part of this design?" As we've been looking at, for example, OmniFocus 4 in particular, we've been taking this opportunity to step back and think about, what are we actually trying to do?

What is the user's core benefit that they're getting from the software, and how do we get them into that as quickly as possible without all of the distractions of how do I navigate from one place to another and so on and let them do that basic interaction while still providing mechanisms that let you get to all the power that we've had before? We don't want to take any of that power away because that deep power is part of what makes OmniFocus so useful for people, but we want it to be approachable for everyone. Even if you're an expert at OmniFocus, been doing it for years, it doesn't hurt to have something that is easier to use and cleaner to sit down at and so on.

Andrew J. Mason:
No, I love that because you ask certain questions to get a certain result, and I feel like questions that The Omni Group were asking are a very specific, intentional set of questions in order to drive a specific type of result. It's awesome. Diving a little bit deeper from the 30,000 foot view of the development of OmniFocus, you mentioned that as you look back over the past, oh my gosh, there's something that showed up here and it's a little bit of a pattern that emerged. Speak to that pattern and how there's this kind of supercycle of software development.

Ken Case:
Well, people often ask us, of course, when is the next version coming out? They'll start asking that as soon as we ship the previous version, whenever that is. Our answer has always been, well, it'll be out when it's ready, when the software is done before it's time. We're sitting there waiting for... I mean, we're not just sitting back and waiting. We're not just sitting idle and waiting. We obviously want this to happen, and we're still polishing the previous versions. We didn't stop with 3.0. We went on and did 3.1, 3.2, what, up to 3.19 now or something. We keep continuing to do updates.

Even as recently as this week, we're still putting out updates to the old software, as well as building the new one in parallel. It's never something where the later versions, in some sense, ought to take less time because you've built this before to some degree and you know what you're building. But on the other hand, you're also still maintaining the old stuff at the same time with the same team and your time and attention are divided. Looking back at the patterns anyway, we started working on OmniFocus 1, goodness, what year was that? 2006 or so, and it ended up shipping in about 2008.

We started doing public tests in 2007 and a lot of people were using that. And then we finally shipped right around, well, in January at Macworld of 2008. If we look at that, of course, a lot happened through that 1.0 cycle as we introduced it for the iPhone and the iPad and everything else. Version 2 though came along about six years later, and then version 3 came along about four years after that within 2018.

What we're realizing is that, oh, it usually takes us about five years to go from one major release to another, and that's just how long it takes between all of the stuff we're trying to get done still in the old version and maintaining it and all of the new design work that we're doing on the new version, as we experiment with different approaches and try to figure out what is it that we really need to do to make this release as good as it can be.

Andrew J. Mason:
I love that. Because anytime that there's waiting involved, there's always that person that's like, "Oh my gosh, this is taking forever." You're like, "Well, actually, if you look at the data, kind of right on track here." That's cool. But do you mind speaking to where we are in that overall cycle? I know we've talked through the milestones before, but would you lay out those milestones and where we currently find ourself in that development process?

Ken Case:
Sure. When we start this process, of course, we're listening a lot, I guess. We're listening to feedback from our customers, what are people finding is working well for them and is not working? What are the points of friction that we want to improve in the next version? The initial phases are all just kind of collecting feedback as we maintain the release of the previous version. Then we start to put together, okay, well, here are high level goals, here are the features we're working toward, and let's get something out to a place where it's now testable and we can invite other people to start working with us through this process and figuring out as we introduce a feature, does this work or not?

Does this really help someone's workflow or not? We have the featured milestone where we're adding new features, deciding exactly what the feature set is, and then at some point we have to decide, okay, that is the feature set so we can get started on the documentation, so we can make sure our designs incorporate all those features and say, "Okay, well, that's mostly locked in." We call it a Feature Freeze. Sometimes we call it a feature slush, because we'll still introduce a few things later on, but here's our Feature Freeze.

And that process of building out the features and getting them to where we want them to be will often take a year or two even, because this is the bulk of the new functionality that is going into this new release. It's coming from this Feature Freeze milestone. Then there's the aspect of, okay, well, we have the features in the app, but are they presented in the best ways that is as easy to use as it can be?

This is our design phase where we're still optimizing the design so that the features are approachable, they're all exposed well, they all fit together and make sense, and that there's a mental model that you can use to understand the app, not just a jumble of features that, oh, well, here's yet another thing in a menu somewhere, and they don't necessarily have a clear rhyme or reason to it. If we just stopped at Feature Freeze, I mean, I'm sure if people looked at OmniFocus, the test flight, a year ago where we had finished Feature Freeze, but we hadn't done all of the design work we've done in this past year, you would see that there's still a lot of work to be done.

That's the Design Freeze milestone and that's now coming to a close here. As we have gotten the app settled into a nice workflow on all of the platforms, that it's consistent, people can easily map from one device to another and they understand what's going on, I think that aspect of OmniFocus 4 in particular is stronger than any previous version of OmniFocus, where the iPhone version really had its own way of navigating, and the iPad had its own way, and the Mac had its own way. You could collapse and expand outlines on the Mac, but not on any of the other devices. You had rich text on the Mac, but not on the others.

You got Quick Open. But meanwhile on the iPhone, maybe you had the Nearby functionality and some of the time stuff and alerts on it. Over time, we've tried to get more and more of it to go back and forth, but here in version 4, I think we've really brought that full functionality to a place where it's all available on all your devices, at least if it makes sense. Obviously on a tiny iPhone screen, you don't want a three column wide view like you might want in your iPad or Mac. That's Design Freeze.

Even with all those design work finished off, that's now a point where we can start several other pieces of the downstream work to getting the shipping in parallel where you continue to work on the app itself with usability and accessibility, stability and performance. Some of that, of course, we've worked on all along. It's not very testable if you don't have it. It'll be somewhat usable, but some of the bugs, we said, this can wait until a later milestone. It's keyboard shortcuts or something and we know how to make that work. Right now the priority is just to make sure they're even in the right place.

But then meanwhile, in parallel, we can get started on the documentation work, taking screenshots of the app because the design is finished. We're still a company that likes to write documentation that takes you all the way through the app from start to finish. You read through the documentation, you know what's there. You don't have to go search some Q&A site and try to guess at what you should be looking for in order to find the functionality you need. You know that there's always this complete description from the company itself about how the software works. We do that for all of our apps.

Of course, localization is where we translate the app into other languages or localize it for other locales that still speak the same languages. We have that localization piece. And then as that all kind of comes together, we're ready to hit Code Freeze and ship the app. There's still months of work left, but it's not the years of work that we had in those earlier phases of Feature Freeze and Design Freeze.

Andrew J. Mason:
It's a really interesting process because it starts with those big rocks and they take longer to move, and then it gets smaller for the rocks and more nuanced. It's cool to see people who have maybe taken a look at the beta version said, "I don't know if this is necessarily for me," checked out or hit pause. "Maybe it is. I don't know." But then come back a year and a half later and say, "Oh my gosh, this is checking all the boxes. This is perfect." Just knowing that there are people that have hit pause and then come back to it and given such positive feedback, it really is satisfying and it makes us feel like we're on the right course.

Ken Case:
Absolutely.

Andrew J. Mason:
I really do feel like major release is the right terminology for it because of the ground up build in SwiftUI. You're way more versed in this than I am. Do you mind maybe just sharing a little bit about what that does when you're able to rework the entire thing from bottom to top in SwiftUI?

Ken Case:
Yeah, happy to. SwiftUI, for those who don't know, is a new technology from Apple. I say new. It was new when we started this process a few years ago. Completely new at that point. It has evolved and improved each year as Apple continues working on it. We have rebuilt the interface in the iPhone and iPad apps to be completely done in SwiftUI. What I should say about the SwiftUI technology is that cross-platform. It's not just for the iPhone and iPad or just for the Mac, the way the older UIkit and AppKit frameworks were where they were platform specific. It's a cross-platform technology from Apple that lets you do these implementations once.

You still have to tweak it for your platforms, but you can share a lot of that code now from one platform to another. I'm talking about interface code, not just the model code, which we've always shared, the syncing code, the database code, and so on. That was always cross-platform because all of Apple's platforms have this same underlying UNIX based around the old next technologies that we worked with 30 years ago. That has worked the same on all of the layers where you interact with the screen, with the keyboard if it exists, with the touch device panels, and so on. That has been different on all of these platforms until now with SwiftUI.

Some of the benefits that we've gotten out of doing this work now in SwiftUI is, for example, we rewrote the perspective editor in SwiftUI on iOS, and then we brought that exact same perspective logic to the Mac. And then as we were continuing on through our cycle and saying, "Oh, well let's make forecast a little bit more flexible. Let's make it so that you can reorder items and place them in whatever order you like, or let's let you collapse and expand projects that show up in forecast. When a project is due, you don't have to see all of its children right away. You can expand it to see the children if you want, but you can collapse it or not, just like you can do in the project outline all along."

When we brought that capability to the iPhone and iPad, we also brought it to the Mac at the same time, instead of having to build it twice. The exact same code now just worked everywhere. Again, with a little tweaking so that it looks nice because it's not the most mature framework yet, but it's so much nicer to be able to share that logic and than to be able to iterate more quickly on these features. Did it save us a lot of time so far?

Well, to some degree. Of course, we were rebuilding stuff that we'd already built, so maybe not. I felt like we might now be at the breakeven point where going forward now I can see how this propels us into the future.

Andrew J. Mason:
Just to make sure I fully understand, because of the way that this has been coded in SwiftUI, there are potentially future chunks of code that can be used, double used, triple used, depending on what the device is, for a feature such as let's say collaboration. I'm not really saying anything specific or not, but something that's a future possibility can be more quickly coded in theory.

Ken Case:
Yeah, absolutely. Collaboration, to be clear, yes, that is very much on our roadmap. It's something we've been thinking about through this whole 4.0 process. Not that we were trying to deliver it for the initial 4.0 release, but that we wanted this to be a foundation that then propel us towards being able to implement that.

Andrew J. Mason:
I'm sorry, I had to. I just love the concept of collaboration so much, especially with OmniFocus. It just is mind-blowing for me. But that wasn't the only place that the focus, pardon the pun, bad joke, was in this roadmap post. You also gave some attention to another bit of software. Talk a little bit about that.

Ken Case:
Yeah, absolutely. Of course, OmniGraffle has long been one of our most popular apps. It's now approaching 20 years old as well. No, sorry, it is 20 years old. We shipped it with OS10, which, of course, shipped in 2001. Now it's like 22 years old later this year. How time flies. It is in version 7 at the moment. Obviously it's been around longer than an OmniFocus, so it's gotten to a much higher version number.

Well, looking back at the feature request from some of those early years, what were people looking for right then and there, and then also thinking about how the app has developed over time as we've added features, which things might have gotten too cluttered as we did the iPad or bust and bringing all of our apps to the iPad, OmniGraffle was one of those first apps that was there on the launch day for the iPad. Again, because of this split between the Mac's AppKit and the iPad and iPhones UIkit, that kind of slowed us down a bit. We suddenly had to be building two apps and maintaining two apps and doing all of this extra work.

Much like we are doing now with OmniFocus 4, for OmniGraffle 8, we are rebuilding that interface code with shared SwiftUI logic, so that as we work on improvements to the inspectors, for example, or the way you interact with pallets and so on, all that work is shared and can be done more easily across all of the platforms. As we're now redesigning and rebuilding the whole app, just as we did with OmniFocus, we're thinking about, well, what is it that is essential to the app? What are people trying to do when they first sit down with it? How can we make that easier for everybody?

Whether you've been using every version of OmniGraffle since 22 years ago, version 1.0, all the way to now, or whether it's brand new to you and you're just sitting down with it for the first time and you want to do something, we would like for that to be as easy as possible, as approachable as possible. And not that we want to get rid of the deep features, we want that to still be easy to access and approachable, but we don't want it to be overwhelming, which I think it often can be with a mature product.

Andrew J. Mason:
Oh my gosh, it's another jam-packed year. I feel exhausted for you about the roadmap ahead, but it's exciting stuff. I mean, it's definitely an energizing prospect to hear all of this coming down the pipeline. That's really cool. Is there anything else that you would want to share with our listeners or let people know?

Ken Case:
I guess I want to note that we have certainly also been thinking about where we're going with OmniPlan next, or we're going with OmniOutliner next. They have had their big releases more recently than OmniFocus and OmniGraffle, so it's not their turn this year, but we're in those earlier stages now of thinking about, okay, well, what happens as we approach their Feature Freeze milestones later on?

What will we be trying to get done for them? I can't wait to look at those, right? In some ways, choosing your favorite software app that you've produced is a bit like choosing your favorite child. There isn't a favorite. There's things you're proud of about each one that are different, and I enjoy working on each of them in turn.

Andrew J. Mason:
That's awesome, Ken. Thank you so much for spending time with us. I always enjoy the opportunity to get to hang out for a little bit.

Ken Case:
Thank you to you and to the listeners who are taking the time to listen to this. There's no reason to do this if there isn't an audience out there who's interested in knowing that. I hope that this has been valuable.

Andrew J. Mason:
Definitely. Thank you, Ken.

Ken Case:
Thank you.

Andrew J. Mason:
Hey, and thank all of you for listening today too. You can drop us a line on Twitter @TheOmniShow. You can also find out everything that's happening with The Omni Group at omnigroup.com/blog.