Possible Future for OmniOutliner

I do like individual files, but I’m dropping that philosophy for OmniOutliner since it’s proprietary and the files are not plain text files. Since I need OmniOutliner to open these files, I’ll throw in the towel and let OmniOutliner organize the data for me like OmniFocus does. I would like it to handle the storing of attachments, etc. If I don’t have access to the guts that can be modified with a text editor, then I’ll let the app do it for me. Like Bear. Like Agenda. I’m not savvy with Agenda. I’m only bringing it up since it’s a database app.

Exporting data, modifying it, and bringing it back in is not a workflow of choice for me. It won’t come back the same with styles, etc. I would like to modify it while it lives where it is. We can’t do that with OmniFocus, OmniOutliner, Bear, or Agenda (I think). We can with iA Writer since it’s looking at plain text files. Omni Automation will solve our bulk changes since we don’t have access to data behind the software.

I picture a database since I’m relying on The Omni Group to stay in business and keep my documents alive. If OmniOutliner dies, the outlines are useless and a future database would be useless. That’s the week we all export our data and cry a little. I don’t want that day to happen.

Below are examples I think about when I read your scenarios and using OmniOutliner as a database.

I picture opening OmniOutliner and you focus on the outline that you want to use instead of seeing every outline that exists to avoid the clutter. Like a focusing on a Project in OmniFocus. Maybe Perspectives can come into play as well.

  • You could launch OmniOutliner, and focus on the outline manually to get rid of the clutter
  • You could launch OmniOutliner and click a Perspective to focus on your common outlines
  • You could have a Copy Item Link made with the focus already enabled during launch

You could make a Home folder and Work folder for your outlines like in OmniFocus. You could focus on these folders. Then you can export the outline when you’re ready to share.

Omni has been good with spotlighting the OmniFocus database, so I don’t picture this being a problem.

I tried this and stopped for the reason you explained. I don’t make one outline and treat the top level as separate outlines. I need different columns for different outlines. Different styles for different levels, etc. Each outline is not a consistent build.

I think the best solution to this would be what someone said earlier. Allow multiple independent outlines per OO database. Those who want all their outlines in one database can do so. Those who want compartmentalization can, as well.

In fact, that would be really cool. A rough draft outline bound to a chapterized outline, for example, in one database. There is precedent for that sort of thing.

Apple Photos is widely perceived to keep everything in one database, which it (sort of) does. But, there’s a little-documented way to open Photos that lets you specify a different database. I’d vote for that.

OmniFocus gets away, in my usage, with a single database for everything because it’s about my life in general. Things to do for work take away from my availability to do things for fun, for example. It is OK to have that all in one file.

Even considering that, though, I still use TaskPaper for to-do lists for writing projects. I don’t need to see my loose ends in an essay I’m writing, or in a short story. I like those things in their own containers. If OmniFocus had a means of storing tasks in different databases, I’d use it for every task in every project.

Just a few thoughts. Databases with multiple independent outlines would be great. Only one database, not so great in my use cases.