My Own Needs

As with all ATPOs, this month’s column comes from my own experiences with outlining. But this will be on an area we haven’t yet examined. We’ll look at business models.

I believe that we are due for a whole new generation of software—radical stuff—and that outlining will be a part of it. I really believe this, in part based on what I’ve seen professionally in terms of notions that are just becoming marketable. In part it has to do with being steeped in the Mac outliner community. Outliner users (and developers) are generally the cream of Mac users in terms of creative folk, and Mac folk are the cream of creative users of computers.

In some prior columns, we’ve mentioned some ideas that sound exciting to me. We’ve started to actually design a system here on a research project that uses some of those advanced ideas: outlines of video components (not outlines with videos in them, but videos decomposed and composed like documents); outlines that use columns to link all sorts of different worlds (like ontologies, features, facts, and video components as well as the ordinary lists and narratives); and linking between two logics or set of relationships by dragging from one outline column into another. Also word-level metadata.

It’s cool stuff, and we may describe it here.

Or not.

You see, there’s the problem of business models. If the software is going to be radical, might not the way it is developed, disseminated, and used be radical as well? The standard business model is that someone makes the software as a product that is sold. Well, not really. What is sold is a “license to use” in pretty much every case, and that carries all sorts of restrictions.

The only significant alternative so far is open source. I think we’ve had enough experience with open source software to know that the first era produced truly awesome stuff (BSD Unix, Emacs, Apache) and the second era which we are now in is producing tons and tons of “me-too” software that might be better in some cases. But except in very few instances it is not reinventing how we use computers. (I cannot think of any good examples.)

So. Here I am beginning to put some real energy into a new outliner-inspired user interface. And the question I am dealing with at the moment is what to do with it. Turn it into a sellable product that incidentally services our existing projects? Give the code away so that some open source community can enhance it, sort of the Eclipse strategy? Patent it? Write a killer ATPO column on it?

Some combination?

There’s some ATPO history in this area. In one column I proposed that as a community we establish a community project to create a better OPML. It’s an outline exchange standard based on XML. It’s widely used and pretty useless if you care about power outlining. At the time, I had some money to spend to seed such a thing. Essentially no one responded.

In another column I proposed a community Web site for the outliner community and got ATPM to set up a server and wiki. Though several readers expressed interest, nothing has appeared.

I’m sure there is a sweet spot for ATPO that’s more than columns on existing products that somehow provides value for engagement, but we haven’t found it yet.

That’s why this month, my mind is on novel business strategies and outliners. Hog Bay Software, who publishes Mori, is the example. It’s an interesting business model that I am supposing will prompt lots of discussion.

Mori, a New Approach

Hog Bay Software did an odd thing. They sold a darn good outliner product, Hog Bay Notebook, that had features no other product had, and still doesn’t. But they discontinued it for Mori, a wholly new product with a different design. At the same time, they introduced a novel business model.

What makes the business model unique is how open Hog Bay Software is. I mentioned last column that for my purposes it is more open than the conventional open source. It’s neither free as in free beer nor is it completely open in terms of all code being accessible to anyone. But I as a user can actually influence the direction of development, and see that influence. If I am a licensed user at $28, I can receive the complete source code if I ask. And if I am curious, I can even go to the Web site and track site statistics and even sales!

If you go to the page that describes the product, or read the documentation, you will find an honest evaluation of what it will not do and which competing products might be better if you are looking for something outside its design parameters. Refreshing.

I’m not exactly sure this model can work. Mori is placed in a context where so many people use it for so many different things. Outliner users are remarkably clever and highly individualistic. So if the “community” is going to depend on a centered consensus, maybe it won’t happen.

On the positive side, the forums so far seem to be characterized by good sense. Jesse, the head (actually the only) developer imposes a sense of coherence, and there are after all sorts of constraints that are imposed by the Mac technologies and interface conventions Mori leverages.

The Feature Request Forum

So, we’ll see. Mori is $28. In prior columns we’ve mentioned the features it has that no other power outliner has in the numbers Mori does. It’s worth a spin.

Some history that will be old for ATPO readers. Hog Bay Software sold Hog Bay Notebook, an excellent product that itself was at the head of the pack in many respects. It was like nearly all the pre-Tiger outliners in using a document-centered model. Mori is based on new Tiger underpinnings, primarily the built-in database, and a disciplined programming approach called Model-View-Controller. That means that each note is an entry in that database. Each note uses Cocoa’s built in-text services, which gives you a lot for free.

A “Factored” Development Approach

But it also means that some things that Notebook could do, Mori finds harder. Handling of links and attachments is less graceful in my view. Notebook had a great capability to swap between outlines in the left pane and outline-like lists in notes. That’s gone in Mori, at least for now. (I misreported this in an earlier column).

On the other hand, this new architecture means things can be added fast. Mori is highly AppleScriptable so any user can extend it that way. The database is open, so you can get at it that way. (The database literally is open source in the ordinary way.) But more important is that the framework used is designed for plug-ins. Some very impressive plug-ins have already appeared. Many things that Apple adds come along for free, so if Apple makes a service or user interface improvement, Mori will be among the first to exploit it.

User Access to Layers

Here’s what it looks like. It’s a standard three-paned layout with an outline view on the left and the contents of a note on the bottom. Above the note is a mini-outline of the selected header on the left with user-definable columns. Alternatively, that pane shows search results if you have just performed a search.

Mori’s Three-Paned Layout

Superficially, it looks like many other three-pane outliners you can get. Though it has features the others do not at the moment, some of the others have some things Mori doesn’t. Will this radical business model allow Mori to grow and improve quickly?

Here are screenshots of others that at least look similar, use Cocoa, and have a three-pane layout.

Dossier

Journler

Mindburn

Process

Because this column is an exploration of Mori’s “community” business model, I’ll turn it over to the community. You’ll hear from a few folks, starting with Jesse, the developer:

The Developer Speaks—Jesse Grosjean

Hog Bay Software is different because we have a user-powered development process. This process allows motivated users to take part so that our software can better server them. Our user-powered process is built upon three principles: an online user community, open technology, and transparent operation of our company.

Our online community of users tells us what they want by making feature requests and then voting on those requests. The voting process gives the community a clear way to communicate its priorities and helps me decide what to work on next.

Our open technology strategy has three parts. First, we provide strong AppleScript support in our applications. Second, our applications are all built on Blocks, our open source plug-in framework that allows expert users to write and extend our applications with plug-ins. Third, upon request we provide full application source code access to registered users.

We are lucky to have a bunch of really smart and dedicated users who help make our software and company better. In fact our logo was donated by a user, users help write and edit copy on our Web site, and users are also involved in naming and pricing products. In return for this help we try to run Hog Bay software as transparently as possible, and among other things we provide real-time sales and Web statistics for everyone to see on our Web site.

That’s the unique way that Hog Bay Software does business, but does it work? Of course the answer is complicated: a strong yes, a no, and a strong still needs work.

First, yes. If the goal is to make my job more fun and make our software better, I think user-powered software is doing a great job. We’ve got a core of smart dedicated users who help spec out features, write scripts, and even extend our applications with plug-ins. It’s a fun process for me to be part of, and they get better applications as a result.

Second, no it doesn’t solve everything. Software is still hard to do, and the user-powered process doesn’t solve that. It might even slow down application development sometimes because of the extra time needed to keep the process running. The big problem is the imbalance between users wanting things and users and me doing things. This leads to situations where a user spends lots of time writing up an excellent feature request that unfortunately has no chance of being implemented because I don’t have time to do it.

Third, we can do better. The next long-term goal is to find a way to get more people contributing to the community. I think the way to do this is to setup a system that rewards users for their participation, but the details of how to do that are still a bit fuzzy. Right now we are doing an initial experiment where a user has taken over much of the development of our WriteRoom product in return for a percentage of the profits. This seems to be working well, but eventually I’d like a more fine grained rewards system that will notice non-technical people who spend lots of time helping out in the user forums.

Please check out our site to see how user-powered software works in practice.

Jeff Fisher

Ted’s note: Jeff is a user who has been an early extender of Mori. The most widely used instance of his work is the “getting things done” plug-in, shown below.

The Mori “Getting Things Done” Plug-in

When I was looking at different outliners, Mori (actually its predecessor Hog Bay Notebook) seemed at first glance a lot less flashy than others. However, once I started using outliners for my work, I found that many of the outliners with decidedly attractive interfaces didn’t always provide the means to add adequate structure to the content I was creating or organizing. I kept returning to Mori: it had the clones and links of HBN and had been rebuilt on top of Tiger’s Core Data technologies to allow for better searching and smart folders. At the time, Jesse was also working to add user-definable columns (a feature that took longer than he expected but was worth it in the end). Furthermore, it is important to consider not just how well an application functions in the present but how well it will grow into the future.

Very few programs that were in use ten years ago are still being used today—what happened to the data developed with them. Successfully migrated? Abandoned? Lost? I wouldn’t commit my work to anything that didn’t have a open, easily accessible format, with multiple options for additional export formats. Also the rich export allows one to integrate the tool into a workflow that might include various tools. However, it’s somewhat morbid (though necessary) to focus on how best to discard an application and move on to the next, before you’ve even started to use it.

More intriguing is to consider how that application might grow as technologies develop and as your requirements change. The two factors that will most determine the direction of this growth: the path that the developer has laid out and the facility with which one can mold the application oneself. The first is the subject of a portion of this article, so I won’t repeat much of it here, other that to say that the transparency of the development process at Hog Bay is a refreshing contrast to many other companies.

As for the second point, Mori has a lot going for it. In addition to a very comprehensive AppleScript dictionary, it is built from the ground up on a plug-in architecture that makes it possible to extend the program functionality in core ways. While AppleScript is great for inter-application operations, it is not as well suited to complex and continuous intra-application action. Mori plug-ins can add menus, toolbar items, windows, preference panes, inspectors, and background monitoring of entries and their values. I didn’t have much experience with AppleScript or Cocoa programming but feel that I have made satisfying progress customizing Mori to fit my work.

My Plug-ins

Note-chan

I originally wrote Note-chan (Japanese for little Mister Note) to help integrate Mori into my workflow for research notes. I read all my articles using Preview for PDFs, and it was becoming cumbersome to continually switch back to Mori to add my notes. What I wanted was a small, unobtrusive, always-available input chute to my Mori notebook. Note-chan started as an AppleScript Studio application (for those that don’t know, AppleScript Studio allows you to build quite sophisticated interfaces to AppleScripts using Interface Builder. Some of the things that can be accomplished with the two are quite impressive.) I was able to get quite far (through three versions) using this combination of AppleScript and Interface Builder; however, there exist some fundamental limitations in AppleScript concerning the transfer of RFTD text, and that was hampering the clipping of rich text and images from Web and PDF. Consequently, I felt that to get the functionality I desired, the only viable option was to convert it to Blocks.

Note-chan

mori-GTD (mGTD)

mGTD began life as an AppleScript a little over a year ago, when Mori was still Hog Bay Notebook. However, it suffered from two major limitations: lag when dealing with a large number of data read/writes from the host application, and the requirement that it be run manually to update the entries. When taken together, these two limitations make it difficult to incorporate the tool into a workflow. The slow I/O might not be noticed for a single entry (e.g. a 0.2 sec delay when you finish editing an entry), but when all the entries must be processed at once, my 1,200-entry notebook was taking 200–300 seconds to update. So after getting a little experience with Blocks and Cocoa from Note-chan, I decided to transition mGTD over to a full Mori plug-in.

Fortunately, the most difficult parts, like synchronizing items between separate projects and contexts lists, are all handled by the core features of Mori (clones and smart folders). mGTD just sits in the background and watches for certain types of edits to entry values, such as adding a due date or marking an item with an action tag. When it observes such an edit, it will process the item: giving it a tag, checking to see how “urgent” it is, or, if it’s complete, archiving or recurring it.

dateTime

Another advantage of Blocks is the ability to incorporate user interface elements seamlessly into Mori. You can add menu items, toolbar buttons, preference panes, inspectors, etc., and they will appear right next to the built-in ones. Thinking that some people would want add a feature that needed some user interface, I put together an example plug-in that does nothing more than insert the date and time into the note field. Anyone who might want to try their hand at writing a plug-in can download the Xcode project and alter it to implement their code.

dateTime Plug-in

Gordon Worley

Ted: Gordon is another extender of Mori. He supplies the ability to insert complex mathematical equations, something I use frequently.

From my experience writing a plug-in in Blocks, I have to say that it is both easy and fun. I’ve written some plug-ins for other software, but Blocks made it easy to do things beyond what the original developer may have had in mind for plug-ins. Typically the plug-in architectures I’ve seen on Mac OS X provided limited access for plug-in writers because the architecture of the original program can’t easily be modified, but Mori is designed from the group up to be easy to extend with plug-ins.

When I wrote Mori Math, it was based originally on code I had written for a note taking application I was working on in my spare time. I scrapped that when I found Mori, and moved my code into a plug-in pretty quickly. Mori provides a great platform in which to work as a plug-in writer. I was able to easily access all of the relevant data structures, and Jesse was always around to provide support when needed. I spent relatively little time making the plug-in fit into Mori and most of my time tweaking Mori Math’s user experience.

Of course, it wasn’t all roses. Blocks still has some places that could use improvement, especially the menu system (adding menu items is far more complicated than it should be, but no one in the Mori community has yet thought of a better way to do it while maintaining localizability). But, overall, Blocks is a nice architecture to work on top of. Much easier than dealing with the typical plug-in interfaces of Mac OS X programs.

WriteRoom

We weren’t able to get Jeff Alexander’s contribution in time for this column. It would have concerned WriteRoom. WriteRoom is a small stand-alone, free application that gives you a “distraction-free” screen. Wes Meltzer reviews WriteRoom elsewhere in this issue.

It’s of interest to us because it is built on the Blocks framework and was supposedly easy to create. It is being passed off to Jeff for future work. Also, a tight binding with Mori is planned in the near future; currently it works with everything.

Ted’s Wrap-up

It made sense to me to open the column this month to users and to start with Mori. That’s because such a novel business model is attempted. But wherever I go on the outliner landscape, I find intelligent enthusiasts of outliners, every one. These folks—many of them—are worth listening to. Should we do more ATPOs along these lines? What outliner next?

Copyright © 2006 Ted Goranson, tgoranson@atpm.com. Ted Goranson is senior scientist of Sirius-Beta.