Skip to main content

Invisible Links

An invisible link occurs when there is an unseen, yet critical, connection between two components within a system. This lack of visibility can significantly increase the cognitive load on a user, as they may not be aware of how changes in one area can unexpectedly influence another, and thus, if one abstraction in your software is altered by, or dependent on another. However, hidden dependencies are not inherently bad, and some software would become an unusable clutter were all dependencies to be visualised - indeed, for ease of use it might be desirable to only make dependencies visible on request, if ever; as with many of the aspects related to software design, a balance needs to be struck.

A classic example of a possible invisible link is adding a photograph to two photo albums in some image editing software, let’s say that one album is for Instagram, and one is for 7x5 prints. If you then go into the Instagram album and crop photo to fit the Instagram aspect ratio, will the photograph in the print album change too? That is to say, are the photos copies or aliases? If they are aliases, this means the photo album you’re not working in, has a dependency on the one you currently are working in. In this situation, one solution (of many) would be for the user to be made aware of this dependency at the point of editing - with the user given the option of removing said dependency (i.e turning the alias into a copy).

The presence of hidden dependencies can lead to a high frequency of errors, let’s consider a spreadsheet application for a moment. If a user has set up a formula to sum some values in a column from A1 to A12, with the sum of this being stored in B1, a user may leave the application, and come back some time later, and add another value to A13, perhaps reasonably assuming that this value would be added to the total in B1, however, it would not be. Spreadsheets are in fact a quagmire of hidden dependencies in general, and dealing with each of these hidden dependencies requires recall and thus a higher cognitive load. That said, spreadsheets can be built up of hundreds of such hidden dependencies and visualising them all at all times would be impractical, but steps should be taken to allow users to easily view dependencies when they need to (hovering over cells or clicking in them, for example, could reveal a cell’s dependencies).

In general, the risk of hidden dependencies causing errors increases with the size of the information structure and the complexity of its interconnections.

Another example of hidden dependencies regularly occurs in 3d software when one object is constrained to another, this is often not obvious in the viewport, or the layer stack.

Testing​

For the first part of testing we're back on the concept bandwagon.

  1. For each concept that you're testing, note the related concepts.
  2. Go over this list. Is it obvious to a user, at all times, that these concepts are related? Whatever the answer, note why this is.
    1. e.g These concepts are always seen together, or in a hierarchy, meaning users can easily infer a link.
  3. And next, does your app include any instancing abilities, if so, is it clear to a user that this is an instance, and that changing one instance will affect all of them.

The next step​

Next up you need to consider user initiated links, and thus consider the following if you app allows users to link concepts (for example connecting two nodes in a graph, or two attributes in some way).

  1. Is it obvious that the link exists and is information about it easy to find?
  2. Is the link shown only on one side, or on both sides?
  3. Is the link visible in all required contexts?
    1. The link may only be available in a dependency graph of some sort, but is not obvious elsewhere, even though it's wanted.
    2. The link may only be noted by the 'unlink' function, is that obvious or hidden away in a context menu?

Conclusion

The goal is to minimise the 'search cost' the effort needed to uncover these dependencies, which can be a function of the complexity and branching of the apps design. Once again, invisible links aren’t always bad, especially for novices using your software where seeing dependencies could be overwhelming, but more experienced users will need to know what affects what.

It can also be useful to consider:

Check After Improvement​

When iterating on the aspects discussed here, it is important to be aware that increasing, or decreasing the number of concepts in a system can notably affect:

  • Conceptual Burden
  • Brain Strain