The category of tools for thought is a very broad one. I’m assuming we will be building more things to test different workflows and pin down our principles and concepts.
I see shared aesthetics and complicit mindsets around here, but I suspect we also enjoy the freedom of pursuing alternate rabbit holes, which will help explore the territory. And yet, we’d like to help build a collective alternate reality where “copy and paste” and “platform and app” are not the end of the trail.
For this reason I propose we attempt a common spec, minimal enough so that we can explore in parallel different approaches and still benefit from developing the basics together, leaving the door open for future convergence.
Here’s what my extremely rough sketch for such a spec looks like:
Structured like a graph. Content is a node. Edges are directed but can be traversed in both directions. You can think of a document like a series of content nodes laid out by traversing the graph.
Content is atomic addressable. I’m thinking unique ids with no collisions on creation into some sort of URL like thing. but @johannesmutter is there anything else you have in mind?
Content is self-contained, meaningful on its own, to ease reusability. Containerising the building blocks makes it easier to build with them. If I start a paragraph with “on the other hand…” that will make it harder for me to reuse that paragraph elsewhere. This does not mean that one shouldn’t be able to create such paragraph, but rather that there’s a native way of creating content that unlocks the benefits of this category of tools. Maybe affordances could to help users have that in mind.
Encourages mashup over edition. When you transclude content over time you assume the content will not suddenly disappear or change in meaning after an aggressive edition. Thus manipulation systems should at least try to encourage creation and linking over edition. Maybe we don’t need to go all the way to immutability (?) but one thing is to fix a typo and another to change the meaning of a shared building block.
As you see, there’s a big overlap with
What do you say?
Do you see any of them problematic?
Do you see ways of making these more clear?
Are these minimal, basic enough or have I polluted the list with ideas about the implementation that I have in mind?
Do you see any other basic element that absolutely needs to be here?
I’d love to hear your opinions.
Update: I’ve revisited this topic with a more concrete formulation following my own intuition. I’m not sure how much this model resonates with the broader community, though.