Understanding hierarchical relationships within data, such as those between individuals and organisations, can be key to gaining a complete picture of your contacts, but enabling users to view and explore these relationships in a user-friendly way is not easy. Here we list some of the main challenges in creating and representing customer hierarchies:
1. Categorisation. It may seem obvious, but when displaying a customer hierarchy it is vital to be able to show what each member of the hierarchy ‘is’: i.e. a person, an organisation, or a consortium (group of organisations). In practice, this may not be straightforward if a single, reliable ‘Customer Type’ field is not available within the underlying data. If a record within the hierarchy includes both a name (e.g. “John Smith”), and an organisation (e.g. “University of Oxford”), should this be seen to represent the entire university (where John Smith is the key contact) or only John Smith personally (who happens to be affiliated to that university)? In such cases a rule based approach may be needed in order to make a ‘best guess’.
2. Size and complexity. Hierarchies can often be large, with universities including separate faculties, colleges and libraries, and large healthcare authorities containing several subsidiary hospitals with their own internal departments. In addition, relationships within them may be complex, meaning that each person or organisation may not fit neatly into a single place within the hierarchy. For example, an individual may be affiliated to more than one organisation (having completed a degree at Oxford University and a PhD at Cambridge), organisations may belong to more than one consortium, and even the make-up of any given consortium may vary over time.
3. Terminology. When referring to hierarchical data, programmers commonly describe members of a hierarchy as ‘nodes’ and use family tree terminology to define the relationships between them, such as ‘parents’, ‘children’, ‘siblings’, ‘ancestors’, and ‘descendents’. This convention may not always be familiar to non-technical users, and is often used inconsistently – for example, does ‘children’ refer just to the level below the current point in the hierarchy, or to all of the levels below that too? It may therefore be preferable to avoid displaying these terms to users wherever possible in order to prevent confusion.
4. Inheritance. Extending the family tree concept, the idea of ‘inheritance’ can be applied to define which properties should be passed downwards from higher to lower levels in the hierarchy. For example, it is likely that an individual will have access rights to content if the university they belong to has purchased a relevant subscription, and this should be reflected when representing their data. To create an accurate picture of each contact, it is therefore essential to understand which properties within the data can be inherited downwards and in which contexts e.g. from consortia to organisations, from organisations to subsidiary organisations, and onward to individuals.
5. Visualisation. Large and complex hierarchies are unlikely to fit into a single screen, and a successful visualisation should accommodate this. In contrast to a simple chart or graph for representing two dimensional data, a hierarchy is likely to require interactive elements such as scrolling, expanding and collapsing, and/or zooming in order to be viewed in its entirety. The most common representation is a Tree View which can either be vertical, as seen in Windows when browsing files and folders, or horizontal, such as in a family tree diagram or organisational chart. Other visualisation techniques include Tree Maps which show a hierarchy as a series of nested rectangles, and Hyperbolic Trees which display the hierarchy through a ‘fish eye’ view, although these are likely to be less familiar to users, and therefore harder to understand and use.
The DataSalon Blog 