Structures in information architecture

Information structure is understood by the connectome — the pattern of connections that form between nodes.

There comes a point in two-dimensional art where, if you want a form to read as three-dimensional, shade and light need to be added. These qualities are superimposed on form to help it feel like it has dimensionality, even if it’s a simple object on an otherwise-untouched white ground.

Information has many dimensions. And by ‘dimensions’ I’m using the dimensions that I learned as an artist: two dimensional formats of drawing, painting, etc., that through use of shade and light can take on the legibility of three dimensions, and expand from there to provide context, narrative, and distance. When I’m talking structure, I’m considering the structure on one particular dimension. I will get into the concept of dimensions more in encapsulated rich data, levels, and strata. But the structure, on one dimension, generally coalesces to form — like a ball now floating in a sea of white; ungrounded, only contextualized to itself, but still identifiable as a circular three dimensional object.

There are, to my eyes, five basic data structures. There is a wealth of possibility between the forth (matrix) and fifth (network) types that might, in the future, resolve to have distinct qualities based on connection count. The complexity and freedom of which nodes can be connected that makes me fairly confident that the jump is rational, and it’s definitely good enough for working practice. Networks can cap at two connections and still look very much like a network.

While the type is identifiable, it’s not unheard of for several types to be used. There is a reason I use art as a metaphor for the fundamentals, and not the dependability of math. One plus one will always equal two. Yellow and blue make green, but there is a broad range of greens available even before you start swapping out the yellow and/or blue hue, let alone adding black and white or even red to the possibilities. Often a model will take on one information structure more dominantly, but to express the complexity might take layers of structures.

For each type, I’ll note the name, a simple representation, and the data flow. In other words, enough to register what kind of information structure is being discussed.

The structures

Node

Node structure (left) and data movement (right, static)

This is as cruel as I get with the fundamentals, I promise. When a model is only using juxtaposition and placement of nodes I tend to call them node structures. I have tried to use variations of “juxtaposition” and/or “placement”, but while the words work to describe what’s happening they have not been intuitive during discussions — and remember, as information architects we are dealing with a broad range of people with their own expertise. Node structure, no matter how many individual nodes are involved, resonates. Not 100%, but with enough traction that confusion doesn’t stick, where the juxtaposition/placement discussions have had sticky confusion. I stick to where the discussions tend to be the most fruitful. I sincerely hope that a more unique word will find traction, and will very happily update it when I see it working in discussions with new audiences.

Node structures basically don’t have a connectome. They are whole of themselves. They are also finite, with limited meaning and no data movement compared to what it could have. The concept that a node is also a structure can become useful if multiple dimensions become involved.

Hierarchy

Hierarchy structure (left) and data movement (right, one way)

Hierarchical structures have clear parent-child relationships, with connections that move in a single direction. Each parent can have multiple children, and each child can become an ersatz parent of its own. The key to understanding that an information structure is hierarchical is that you have to back out to reframe and drill into a different data set. Note that hierarchy structures can be built from the bottom up or top down; bottom up will always be truer because it is more nimble to changing data.

Process

Process structure (left) and data movement (right, one way with internal fungibility)

Process structures have clear parent-child relationships, but with the option to internally switch between parents at key moments. The internal switch might even be input from an adjacent data set! The key to understanding that an information structure is a process is that there is some internal multi-directionality, but a single direction from the initial parent to the final child(ren).

Matrix

Matrix structure (left) and data movement (right, bidirectional)

A matrix structure dissociates from a strict parent-child relationship, allowing a bi-directional movement of data. A true matrix allows any datapoint to become a ‘parent’ to the ‘children’ of it’s associated data, either in column or row. The key to understanding that an information structure is a matrix is that it is easy to envision as a table, hard to succinctly envision and resolve as a single bullet list, and doesn’t resolve to one ID as the only entry point to the column or row of associated data.

Network

Matrix structure (left) and data movement (right, omnidirectional)

A network structure is multidirectional, without a cap to how many ways data is connected and with variable numbers of connections between nodes. The parent/child relationship not only becomes potentially transitory, as in a matrix structure, but outright fuzzy, nimble, and a product of attention and point of view. The key to understanding that an information structure is a network is the changeable nature of data priority (aka the “parent”, removed of authority) depending on who, what, when, where, how, and/or why.

Just as with the tendency to use circles and spectrum nodes, network structures help to keep minds open to the possibility that we don’t know everything. Because, really, we don’t.

All together now:

Synopsis of the five basic data structures with their data movements.

Transitioning between node and connectome structures

Tying it back to juxtaposition and placement, if a model is transitioning from a node structure to one with connections, it’s important to remember that the restructured model might not scan as similar to the original. This is the case with every restructured model, it just tends to surprise people more when a node structure is restated to a connectome structure.

From experience, the near/far factor usually becomes moot. The connectors will move the objects into a new formation to balance legibility, and usually the objects that aren’t connected are removed.

Nested diagrams usually turn into hierarchies. Restating models has a tendency to alter thinking, and altered thinking adds and subtracts information. Once that happens, all information structures are potentially viable.

Venn diagrams are quite nimble. They might become a hierarchy; it’s common for Venn diagrams to be used to abstractly explain how SQL selects data, and SQL is implicitly hierarchical. They could also become a process, to help make sense of how or why the overlapped pieces form. If the data has transitory parents or variable child axis, it might be modeled as a matrix. If fungibility turns out to be the key to understanding inclusion, it might even be represented by a network structure. In any of these instances the original Venn diagram might lose or gain granularity to make sense for particular audiences. This, too, can implicate the structures the restatement will form, and the more/less granularity might make the most sense as dimensions.

Spectrum nodes will often become a category, and to many people the inclusion of a category automatically means hierarchy. Spectrum nodes often more truly transition into network structures, depending on how they are balanced with data they are connecting to. The uncapped nature of the spectrum aspect lends itself to making sense as a network structure.

This is one pieces of Why learn the fundamentals of information architecture structures?