Floating Taxonomies

The documentation system tenet of floating taxonomies states that a documentation system should support multiple taxonomies that are independent from file locations. This tenet complements the tenet of emergent structure—given that taxonomies are a common mechanism to classify documentation—and therefore supports all of the four DocOps principles as well.

A taxonomy is a hierarchy or a tree—or an acyclic directed graph for the mathematician. Because file systems are based on this structure—which, after all, represents how objects are organized in the real world, like the location of a pair of socks in a chest of drawers—it is perceived as a ‘natural’ way to organize information. Some documentation platforms are either mapped to file systems, or organize documentation using a similar top-down hierarchical structure. The problem is that mono taxonomies do not scale to the enterprise level, and may actually lead to the misclassification of documentation given that documents can only belong in one place under such an arrangement. 

Even in the absence of technical limitations, documentation ‘maintainers’ may insist on a mono taxonomy based on ideas such as McKenzie’s Mutually Exclusive, Collectively Exhaustive (MECE) dogma. When applied to documentation, MECE would suggest that all documents that describe a given object should be present—collectively exhaustive—and that they should not overlap, let alone be duplicated in different categories—mutually exclusive. This tenet defies MECE. Let’s see why.

In the context of documentation, there isn’t one single ‘natural’ taxonomy. A taxonomy may be spatial—it gives content a sense of place so that items can be located similarly to a file in a cabinet—or it may be semantic—it gives content a sense of meaning, like when we say that Salesforce is in the CRM category, which is in turn in the Internal Applications category. Trying to conceive a single taxonomy that plays both semantic and spatial roles simultaneously is often the challenge. As Rosenfeld et al. (2015), noted “you should be aware of, but not bound by, the idea that hierarchical categories should be mutually exclusive. Within a single organization scheme, you will need to balance the tension between exclusivity and inclusivity”. 

A single taxonomy that is both spatial and semantic has its place in public-facing digital information systems whereby users expect unambiguous and well-labeled navigation bars and menus. However, single spatial-semantic taxonomies don’t work well with enterprise documentation systems because of the wide variety of personas, mental models, and use cases at play. Being forced to categorize enterprise documentation using a single, folder-like taxonomy results in author-specific models that rarely work for the majority of users, as Nelson explained:

“Nearly everything has to be fitted into oppressive and inane hierarchical structure and coded into other people’s conceptual frameworks, often seeming rigid and highly inappropriate to the user’s own concerns. The files in which we must keep things on conventional computer systems are detached from their relationships and history, and (for many if not all users) entwine like wire coathangers [sic] in a tangle of unknown relationships and increasing disorder.”

Take the case of a Customer document view illustrated in the figure presented earlier. We may place Customer in a domain-based taxonomy as follows—note that Customer appears both under CRM and Billing.

• Domains
  • CRM
  • Customer
• Billing
  • Customer
• ERP

But, we may also place Customer in an application-based taxonomy:

• Applications
  • Internal Applications
    • Salesforce
      • Customer
  • Workable
  • SAP
    • Customer
• Customer-Facing Applications
  • Mobile App

The ability to organize and classify documentation using multiple taxonomies, unconstrained by the legacy of file systems, is a foundational feature of a contemporary documentation user experience. 

The way in which taxonomies ought to work is not as a global monolithic hierarchy, but as a floating grouping of labels in which the labels have a relationship among themselves. Let’s unpack this concept by building on the example we are currently elaborating.

Say that in the beginning we start with a flat list of labels:

• #crm
• #billing
• #erp
• #salesforce 
• #workable 
• #sap 
• #mobile_app

When we decide to define a taxonomy, what we do is group related labels, and give the grouping a name—i.e., the name of the taxonomy.

Domains Taxonomy

• #domain 
  • #crm
  • #billing
  • #erp

Application Taxonomy

• #application
  • #internal-app
    • #salesforce
    • #workable
    • #sap
• #customer-facing-app
  • #mobile-app

The online documentation system is expected to render the relevant taxonomy navigation box or widget whenever a content instance is associated with a label that is a member of a taxonomy. We also assume that we can change the display name for labels. For example, #domain would be shown as ‘Domain’, and #internal-app as ‘Internal Application’ or ‘Apps’.

Floating taxonomies are called as such in three senses. First, because of their flexibility given that a document view may easily join or leave a taxonomy by simply tagging/untagging it with a label that is a member of a taxonomy.  Second, because they are ‘visually independent’ in the sense each taxonomy may be rendered in a different way. Some may become extensions of the navigation bar, others may be boxes wrapped around text, while others may extend the footer. Third and last, because they are loosely coupled in terms of the whatever folder structure documents may be located, and global navigation systems.

The proposed system based on a relationship between labels and taxonomy categories is easy to apply to existing documentation platforms but other alternative approaches—perhaps natively supported by the main documentation platform—are equally valid.