Some Thoughts on an Outliner

Posted on April 28, 2005 02:01 AM

I listened to Dave's latest Morning Coffee Notes yesterday and in it he asked for feedback about the new outliner that he's building, particularly as it relates to productivity applications and ideation. So here goes...

I've been using ActionOutline for a few months now, and I have to say that I'm pretty happy with it. It's the first time I've used an outliner, so I don't have a lot to compare against, but it certainly does as advertised and mostly satisfies my current needs. Having said that though, the longer I use it the more things I find it useful for. Initially it was just for managing todo lists, but since then I've started doing a whole lot more, like outlining documents that I have to write, planning out software development, even creating presentations. In fact, I outlined this post on the subway this morning:

So all of a sudden, outliners are an interesting tool for me. Definitely worth of some discussion.

Before I start though, a bit of a disclaimer: I really don't know the world of outliners. I played with a few for several days before I settled on ActionOutline, and that's really the extent of my experience. Chances are good that what I am saying has already been implemented or thought about in one form or another or is just a crappy idea to begin with. This is really just a bunch of loosely connected thoughts on outliners.

Basic Requirements

Like I mentioned before, when I bought Action, I bought it to manage todo items which I had previously managed using tasks within Outlook. Despite the excellent integration to the rest of the application, Outlook tasks just didn't work for me. It always felt heavy and more often than not I seemed to fall back to bullet lists in plain text files. Action works really well in this space. It's lightweight, and it sits quietly in the tray waiting to jump out at the touch of a keystroke. Once it appears, you can do most of the things that you want to do with the keyboard alone, right up to the point where it saves your changes and creeps back into the tray. Perfect for jotting something down while maintaining flow. So, here is the initial requirement for the outliner:

Requirement 1: The outliner must be lightweight, agile and keyboard friendly.

Now, I find that it's quite common for people to be looking over my shoulder to discuss something that I have in the outliner. This falls more on the ideation side of things. Action is a little weak here as it's awkward to temporarily magnify the display. When the same thing happens with a web page (using Firefox) I can simply bash Ctrl-+ a few times to jack up the font size. But that leads me to a more general point about the user interface, which is that I think with an outliner there is the opportunity to be a lot more fluid, and so:

Requirement 2: The user interface of the outliner must be adaptable to a range of different use cases.

At it's core, Action is built around the Win32 tree control (or something very close to it), which is good - I always prefer to use native controls where possible - but it ends up feeling a little finicky and gets bogged down with bullet and expander icons. The text to graphic ratio just seems a little off to me.

So I think a lot of thought needs to go into the compositing engine. It probably boils down to two different types of editing interfaces: a quick and lean jotting interface for when your attention is focused on another application, and a more cruisy and collaboration friendly interface for when your attention is focused on the outliner itself. If only we could rig some sort of 37signals and OS X Interaction Engineer mashup...

Changing gears for a bit, I always get the feeling, and it's a little unfair in the case of Action, that stuff in the outliner lives in its own world. I almost never paste stuff into it or copy stuff out of it. Action actually does a reasonable job of this. You can select a node, hit Ctrl-C, paste it into a text document and the result is a tab-indented plain text list. Plus you can take the same format and go in the other direction. It also supports export to RDF and a basic HTML format. I think it needs to go further though. Integration with mainstream productivity apps is in an outliner's best interest.

Requirement 3: The outliner must do it's best to speak the language of other applications.

This basically means that it is able to parse a wide range of inputs (like HTML, Word and PowerPoint) into a sensible native outline, and also turn native outlines into the sensible equivalent for a wide range of outputs (like HTML, Word and PowerPoint). And this, more than anything else in the application, lends itself to requirement four:

Requirement 4: The outliner must be extensible.

This is a no-brainer. The OPML based core of Dave's outliner probably means that a lot of the format translation that goes on could be XSLT based. Below that, I'd imagine, would be some sort of scripting interface. I don't know whether this would be UserTalk powered or whether you'd throw a Python runtime in there, but either way you'd end up with extensions to the outliner that are easily created and cross-platform (assuming that one day the outliner itself will be ported). And then at an even deeper level there would likely be an API (native to the language/runtime that the outliner is built with) that exposes some interesting core pieces, like the interface and utilities for compositing engine widgets. This would allow somebody to put together, for example, a specialized node for podcasters that keeps time directly within their show notes as they are recording. So they could jot down their outline beforehand, then hit start on the root node, and hit a little button on each subsequent node to pass the timing down through the outline. A cruddy example maybe, but you get the idea.

At the end of the day, the outliner is a platform that provides hierarchy and structure plumbing, plus a nifty compositing engine, plus a bunch of file system and network services.

Random Features and Open Questions

I have a bunch of other stuff that isn't nearly as well thought out as the four requirements above but is probably good fodder for discussion:

• Hyperlinks seem like a good idea, either for linking between nodes in the same document or separate documents altogether.
• Views of other outlineable things within an outline might be interesting. So if I could point the outliner (or just a node within an outline) at a directory on the file system, or at a del.icio.us tag, or a mailbox, then I could browse that thing inline. This would be neat for a Getting Things Done tool where you could aggregate the tasks that you have from several different locations.
• How does the hierarchy in an outline relate to del.icio.us/Flickr style tags? Can the concepts live together? Does one fall out of the other? Could the outliner become a part of the tagging ecosystem?
• While we're at it, how does an outliner stack up against something like OneNote?
• Annotations would be nice. Which lends to...
• Sharing and Persistence. I would kill to have my outlines persisted into the cloud. And once there sharing is the obvious next step.
• Is persistence a possible business model? Could you give away the software and make a quid by selling premium services?

And that's pretty much all I have right now. I think this could be an interesting discussion. It's always fun to see what Dave has up his sleeve.

Tags: outliner, davewiner

Comments

Posted by: Rahul Dave at April 28, 2005 10:24 AM

Posted by: ambimb at April 28, 2005 12:40 PM

Posted by: ml at April 28, 2005 01:52 PM

Posted by: ron jeffries at April 28, 2005 11:05 PM

Posted by: ron jeffries at April 28, 2005 11:08 PM

Posted by: bernard at April 29, 2005 02:24 AM

Posted by: VeerChand Bothra at May 9, 2005 06:05 AM

Posted by: Olas at May 18, 2005 02:49 PM