Just what is an outliner?

Posted by Paul Korm
May 5, 2017 at 01:18 PM

Someone in another thread suggested the way to know if something was a “dedicated outliner” was to apply the Potter Stewart test: “I know it when I see it”.

The problem is, we’re dealing with user interfaces and user experience design that is very difficult to objectively define from a software engineering perspective. I suggest it’s best not to mix a description of the software interface experience with data structure.

Define how you want to work with data—how it is chunked, how data elements are typed, what relationships among chunks are valid, how are are they validated.

Step two, survey the market decide what software satisfies that definition.

Step three (optional) would be a decision on how “well” that software does what you want to do with data.

Step three is necessary because attributes like “dedicated” and “outliner” are very flabby from a software engineering perspective—if you mix design attributes and UX with strict functional description you get lost.

(Is a sedan a “dedicated” passenger vehicle but a pickup is not? Well, the pickup sure is from the viewpoint of the suburbanite who thinks pickups are cool family vehicles. But, they both fulfill the data definitions for a transport container.)

Another example, someone else wrote this in a review

“Most two-pane outliners have nice editing windows for writing your notes, but usually have rudimentary outline functions in the tree-pane. Dedicated outliners have strong outlining capabilities, but crude note-taking features at best. Tinderbox combines a powerful dedicated outliner with a good note-taking editor AND throws in database features. “

If Tinderbox combines a “dedicated” + “outliner” with other features (albeit, features that all have something to do with relationships between and among data chunks) is it no longer an outliner?

I think it is very much an “outliner”—one of the best because it breaks the bounds of tradition and enables us to explore our data in multiple way.

The point: in this forum I suggest we are talking about working with chunks of data that are bigger than letters and smaller than pages—words, phrases, sentences, paragraphs.

We are also talking about software that enables us to group, and, at a higher level, define and manipulate relationships between and among these chunks. At an even higher level, software that adds features to specify and manipulate attributes of those chunks.

I purposefully eliminated “hierarchy” from this scope for two reasons. “Hierarchy” is merely a relationship, just as links (visual and hyperlinks), attribute groupings, are all mere relatiionships. Hierarchy might be important for many readers, but it is also very limiting.