The two most basic pieces in information structures
Every painting or drawing needs a way to mark in order to form communication. In two dimensional art, the medium can be charcoal, ink, paint, graphite…and the list goes on. When it comes to information, the things that you build (models, diagrams, etc.) form communication through node and connection.
Nodes
In a tech network, a node is an endpoint for data transmissions or redistribution. If you think about it in terms of hardware, it can be your laptop or cell phone. Think about it in terms of a database table, and it’s the cell where data is being pulled from, written to, edited, or deleted.
If you are thinking about a node in terms of the process of capturing data to be able to ship out an item, a node can be as granular as the zip code or as abstract as the person who is applying the shipping label to a box. That person is nowhere near the form, the input, and potentially never sees a computer. But they are still very much a part of the process that will see an item delivered according to the stated wishes of a person who spent money on it.
Nodes can be noun or verb, as detailed and precise as a single number or as abstract and huge as a universe. They can be a data point, a data row or set, an entire database, a process point, a nuggetized idea, or even the encapsulation of another whole information structure.
There is an accepted lexicon in diagram symbols that can be leveraged, replete with meaning. I rarely use it. I often curtail use to circles or boxes as a symbol for a node, and decide it usually for something as arbitrary as the length of the label that needs to be accommodated.
The reason why is simple, really: if the audience doesn’t already know the lexicon, it’s distracting and off-putting. It’s starting an already complex discussion with a tacit statement of hierarchy: I know more, you don’t, submit to my authority/superiority.
That is not a beneficial way of starting any discussion, and especially problematic when you are trying to glean information and existing understanding. As someone doing an information architecture project, your audience is probably also, at least in part, the subject matter expert.
The discussion isn’t about impressing others with the glory of your expertise in navigating information and helping others navigate it, but in uncovering the information that needs to be navigated and the wiggle points of priority. Information architecture projects are not single-meeting endeavors. If the larger diagram lexicon becomes useful, introduce it as needed, over time, and share the meaning of the different symbols proactively — don’t wait for someone to ask if there’s meaning to the different object.
So, circles. Quadrangles. These are the simplest representations of a node. Circles are a particular favorite because, for those people that do know that diagrammatic lexicon, a circle is the beginning or end of a process. It implies, for those who have the reference, that there can be deeper details that are simply being bubbled up into this one node.
A circle is also nice in that it implies an infinite orientation. The next step in the diagram doesn’t have to be to the right, or that information is coming in from the left (if they are Romance language speakers!). Information can be coming in from any direction, and moving out in any direction. Information isn’t curtailed to one entry/exit per side (as defined in many diagram softwares), but can be more easily considered as part of a multitude.
A circle implies that if someone gets to the playground first, sets up the rules, and starts a game, everyone isn’t automatically expected to follow that lead. You can be a latecomer, see a new entry or exit point, and shoehorn it in; and, it will still be an entirely viable option per geometry. This narrative, by the way, is a nod to the playground interactions noted and built on by Kat Holmes in Mismatch: How Inclusion Shapes Design. If you haven’t read it yet, it’s amazing and highly recommended.
No model can be built without nodes. They are absolutely necessary.
Connections
Where a node is an endpoint for data transmissions or redistribution in a tech network, how it is interacted with — data sent over the internet, a button (physical or digital) pushed — is the connection.
If you think about it in terms of hardware, it’s the mechanics of how a keystroke becomes a letter on the screen. Think about it in terms of a database table, and it’s that a cell can be leveraged or manipulated.
If you are thinking about a connection in terms of the process of capturing data to be able to ship out an item, it can be as simple as the tab keystroke, mouseover, click, or tap to move to another form UI. It can also be as abstract as zipping up all the data entered and sending it to a warehouse. It is, in its most simple form, the action of moving from point A to point B.
When considered in the real world, it can be as magical as a transmutation, such as a seed growing in time or chaff rotting in a field.
Connections are most often an action, because action is generally what we consider working on a thing in order to move it to the next use. In diagrams, especially those detailing processes, each node can be an action. In that instance, the connection is usually the handoff point. People have chunked a string of actions into more recognizable interim steps, and the connection lets them know that we’re moving to the next chunk.
Connections are always represented as lines. They can simply form an attachment (a line from one object to another), provide directionality, mutual impact/bidirectionality, or even show a feedback system. A connection can be part of the data set, the flow of information or process, be a change state, incorporate an idea or show data dependency. It can even connect metadata, or imply a change in focus.
There is an accepted lexicon of line endings that can be leveraged, replete with meaning. I rarely use it, for the same audience behavior reasons of why I rarely use the full set of diagram symbols. But they are a tad bit more intuitive, so I’m more likely to pick up a different line ending than I am to leverage the diagram symbols.
All together, the connections form a connectome. Diagrams can survive without connections being incorporated. Information structure is entirely dependent on and defined by connectome or the lack of it.
This is one pieces of Why learn the fundamentals of information architecture structures?
