October 23, 2006
MarkBernstein.org
 

Refactoring and Incremental Formalization

Tinderbox users gradually discover and express structure in the documents they use most.

For example, lots of people keep ToDo lists in Tinderbox. It's a natural idea, and it's easy to get started. Tinderbox is a tool for notes, so just start making notes about the things you want to do. You don't have to set up or decide anything. No worries about procrastination, no concerns that you'll do it wrong.

The old way to do this would have been to figure out everything you wanted to do and have someone build a database application that does what you want. This led to lots of meetings and, often, gnashing of teeth, because you don't know what you need until you need it.

Over time, you're bound to notice structure that you'd like to represent -- if only to save typing. For example, you might have some urgent tasks that need to be done right away and that you've been painting red with a broad border. What could be more natural than to make a Tinderbox prototype for UrgentTask? At minimum, this saves you steps: you choose "UrgentTask" from the popup menu and all the coloring and border-setting gets done for you.

Plus, it's neater to flag all the urgent tasks this way -- it keeps related things tied together. You might even go back and assign the prototype to existing Urgent Tasks.

This is what object-oriented programmers call refactoring. We call it "extract prototype", they call is "extract class".

As it happens, quite a few of the classic refactorings have obvious equivalents in Tinderbox as well as in research tools like VIKI/VKB and ART. When you move information from the text to an explicit attribute, that's pretty close to extract method. Or, when you split a big note into focused bits, perhaps putting all the pieces together in a container, that's a lot like push down method. When we move some commonly-used chunk of writing -- a footer, perhaps, or a configuration note as in Flint -- to a separate note that we ^include in a template, that's essentially sprout method. And then when we move the data to a server and AutoFetch it in order to facilitate sharing among lots of Tinderbox users, that's our old friend proxy object.

Refactoring and Incremental Formalization

This is one of the things I'm hoping to talk about this weekend at IVICA, a symposium at College Station, Texas on spatial hypertext and visualization of information collections. It's hosted by Frank Shipman, whose work is one of the biggest influences on Tinderbox. Kumiyo Nakakoji and team are coming from Tokyo. Cathy Marshall's giving the keynote. I can't wait!