A SpringModel (Wikipedia: Spring system) is a common visualization technique in note-keeping systems.
- Easy to implement. Scalable.
- Represent a large collection of assembled information without human hand editing.
I’m often frustrated by the use of spring models in notekeeping systems.
They’re very attractive to developers, because they allow for eye-catching visuals, but I find that their utility is, and generally applied, highly limited.
I can imagine that they could be useful, but their customary use needs several changes.
Aspects of the customary use that are challenging:
- They often move and dance around.
- You can drag nodes around, but… why?
- Unexploited Drawing Factors
- Connections are generally equal in tension. There’s meaning to be found in varying the tension of the nodes, but this capacity is usually unexploited.
- Sizes are generally equal. There’s meaning to be found in varying the sizes of nodes, but this capacity is usually unexploited.
- Line widths are generally equal in size. Lines are generally just straight lines, without dotting or other indicators of meaning.
- The arrangement is typically less enlightening than a tree presentation.
- It is often very hard to tell what the connected nodes of a given node are, just by looking. (Contrast with most tree implementations, where it is easy to vertically scan down the list, and see what’s connected.)
- Even if you can hover your mouse over a node, you still have to jump your eyes all over the place.
- There’s no persistence of the map. The map is created in first use, and then discarded just as quickly. A new map will be created in future uses, each time.
- That means that any kind of MemoryPalace? effect that would exist, is gone.
- SemanticRegions? have no persistence, if they are there at all – most commonly, there is no concept of a semantic region.
- Human infusion of meaning is discouraged, because everything will just wiped away. Why spend time structuring the arrangement, if everything is just going to disappear?
Here are some things that I would do, instead, with spring model arrangements:
- First, make the arrangement (A) still, and (B) persistent. Find the rest state of a graph, and then freeze it in that location. Allow turning on and on dynamic motion, but give the preference to persistent storage. The query that produced the arrangement becomes the filename.
- Make it so that the linkages between nodes, regardless of the process that suggested them in the first place, are human editable and configurable. Allow users to specify severance of ties and establish ties.
- Allow nodes to appear in multiple places, with some kind of aliasing between them.
- Allow the user to draw SchematicStructures? – lines, text, icons, – around the elements that are like a spring model.
Basically, I am of the opinion that what we really need is a creative process around working with AssembledInformation.
I’m going to explore that thought in AccumulatingStructure.
- WikiMeet 2021-04-03 – the inspiration for this commentary; The Obsidian system uses a Spring model for visualization