Reuse

When we first started talking to Sam about Sakai 3 we used the word “template” a lot. It had worked its way into our conceptual lexicon rather early on, as the answer to how a free-form editing environment could still be helpfully scaffolded, and not force everyone to start each time with a blank canvas. At times it even started to take on a semi-magical aura: someone in the back of a room during a presentation would call out a question about how we were going to do X. “That’s what templates are for,” I’d glibly respond. Well, not glibly. The idea fit. But the truth is that we hadn’t yet really designed for this apparently pivotal thing, and it was putting a lot of faith in something not yet realized.

If I can be forgiven for putting words in Sam’s mouth, I think his attitude when confronted with this was (tactfully expressed), “OK, it’s great that you guys already have a mechanism in mind. You’ve obviously given it a lot of thought. But if you don’t mind, can we please trace that back to what the user problems are that we’re trying to solve? Because that’s what I really need to be designing around, and maybe templates will cover it and maybe they won’t.”

OK, fine.

1. People need to be able to create new things quickly and easily, despite a great deal of freedom and variability of options. They can’t be paralyzed by possibilities, but then neither should we put them in straitjackets. They need something to build on, even if they end up wanting to knock out a wall or redo the kitchen.
2. When people find something that works for them – maybe it’s something they did themselves, or maybe they see something a friend or colleague did that they like – they want to be able to capture, coopt, or store it for the future.
3. There often needs to be some consistent structure or pattern to individual workspaces or activities such that at a bird’s eye view there can still be coherence for discoverability or hooks for new lines of organization.

Of course I’m leaving a lot out of those three points, there are other concrete elements and variations, but to save space I think those are the abstracted problems that need an answer.

Sam came back with “OK, so if we had to pin it down to a single idea or activity, it sounds like we’re talking about ‘reuse.’ Reuse that includes an idea of sharing, in the form of reuse by others. Reuse that necessarily involves structure, to the extent that it’s often the structure itself that you want to reuse.  And one of the fringe benefits of this reuse is consistent patterns that can be worked with at a macro level. So how about going with that word rather than ‘template,’ which might be getting ahead of itself in implementation assumptions?”

At first it left me a little cold, I suppose because I’m so familiar with ‘reuse’ in the context of ‘code reuse,’ and it’s a rather sterile and uninspiring notion in such contexts. But it’s growing on me as an expression of a user problem or goal.