A thread on the Tinderbox backstage forum has touched on export and its difficulties. I’ve written here that export is surprisingly easy, and I still think, in practice, that it is. Yet there are real conceptual difficulties that can also make it feel mysterious and intimidating.
I’ve been thinking about export a bit these past weeks because I was so dissatisfied with my explanation of how my grading rubric worked. Rereading what I’d written, I saw that I had never managed to figure out a way to explain how I thought about export. So what I wrote wound up assuming that the person reading already knew much of what I hoped to explain. I’ve been trying figure out what I would have needed to say in the weeks since.
What follows is my tentative list of what I see as my conceptual challenges as I started dealing with export. They are not shortcomings in the export process itself.
I mentioned this difficulty in the backstage thread, and it’s pretty straightforward: I know how to organize a word document because the arrangement of info on my screen is synonymous with its arrangement on the printed page. My output is organized by my workspace even in programs as flexible as Scrivener: ultimately, the sequence I impose in my binder determines the arrangement of my output document. If I want a different output, I rearrange my workspace.
TBX notes and output don’t march in lock step in the same way. They can (and do in the built-in templates) but the in-doc organization of notes and attributes will often be largely independent of export results. That makes TBX stand out: I can’t think of another program on my computer that divorces workspace from output organization in this way. The separation is powerful but uncommon enough that, when I start a new export, I lack personal examples or comparable experience to draw on and feel adrift (at precisely the moment—“Print!”—when I usually feel done).
I should say right off the bat, that this problem may actually be simply a misunderstanding resulting from my lack of comp sci training. It’s persistent enough that it feels real though. I’ll explain with an analogy to a stamp action.
Assume I have a note with two Attributes $A and $B with respective values of 1 and 2. I make a stamp with the action $A=$B and apply that stamp to the note. The two Attribute values will now be the same. But will the values both be 1 or will they both be 2? The action’s behaviour is stable and unchanging. So there is a correct answer. (I think it’s 2?) But my point is this: the direction of the equals sign is neither implicit nor obvious. It’s arbitrary, and ultimately, you just have to learn it. Which is fine because I have no natural sense of the direction of the equals sign.
I do, however, have a sense of the natural direction of export. In my experience and in the common understanding of the word, export moves from me (and my data) and toward something (or someone) else. I send a document to my printer, not the other way around. As a picture, my daily experience of printing is:
[ME with my organized info] ::push:: ==> [printer]
TBX export feels to me like it works in the opposite direction. I start the process by creating a template, the symbolic image of the output I want. This image is built up by pulling information piece by piece from my notes and then rearranging it for export. As a result, TBX feels like:
[my organized info] ==>::pull:: [ME organizing a template of desired output]
The shift in direction from pushing to a printer to pulling from notes seems like nothing, but I think it’s at the root of a lot of my uneasiness when I start a new export. Things are flipped over onto their head.*
Tinderbox hides a very unusual, very peculiar thing under the familiar and innocuous word, “template.”
In most common applications, templates are where you turn for an easy solution. Need some colors that match in a document? Pick a template. Have to write a report and don’t know how to format it? Pick a template. And when you go to choose the templates, you are presented with a preview image. WYSIWYG!
TBX templates are nothing like this. Most obviously, they aren’t pre-fab except in very basic forms included for import. Instead, you make the template you need in order to produce the output you want. This is great and powerful (Oz-level great and powerful even), but different from the common experience.
Less obviously and less trivially, templates:
- are usually a system of notes (rather than a single object) structured hierarchically using path names;
- produce output as a collage of your data using instructions that are distributed across the system of notes: your output is a product of interactions across the system as a whole;
- represent the desired output symbolically rather than mimetically. This shift from image to symbol is extremely powerful but it makes greater cognitive demands on the person confronted with the symbol. It can be challenging, for example, to understand the connection between the distributed instructions I’ve placed in a template and the output preview visible on the “preview” tab. (I teach literature and see this difficulty “reading through” symbols play out every day in class.)
Taken together, I think all of this highlights that an uneasiness with export may express a pedagogical need rather than a technical failing.
Translating Computer Science
I wouldn’t want any of this to seem to suggest there is anything wrong with TBX export. I don’t believe what I’m describing here arises from technical or interface difficulties (or at least none I could imagine or suggest a solution to). They seem to me to be conceptual.
TBX takes what this layman considers to be high-order computer science concepts and translates them into a tool I can use to great benefit. But translation will only get me so far. Ultimately, I have to wrap my head around how the tool works, and the information I need to do so (HTML, CSS, page-layout concepts, etc.) may be out of scope for a TBX tutorial.
Export is powerful tool and, when I’m done it with, feels like it was technically easy to manage. But an important aspect of that power is completely (and refreshingly) unfamiliar: TBX asks me what I want it to produce and stands ready to make anything and everything that I have so far asked it for. But answering that initial question—what do I want?—positively and for myself (rather than simply selecting from a range of choices) is disorienting because I’m so seldom asked it elsewhere. And so I’m often still wrapping my head around what my answer might be when I sit down to make a template.
*–rereading this it occurs to me that it might be useful to think of TBX as operating a bit like an old newspaper. There’s my workspace which is the newsroom with all the action that entails. But then off to the side, out back maybe, there is layout and the printshop, which together compile, label and produce the day’s paper.
In terms of the analogy, I never actually “export” anything. I’m really just sending the work I’ve got at a particular moment over to the printshop for inclusion in the most recent edition. And that edition will, obviously, be organized according to constraints and goals (page count, ad space, etc.) that have little to do with how work is organized in the newsroom.