This is the first post in a series that looks at the modelling of User Interface (UI) related software using UML.
The main purpose of the post is to explore how we effectively model the navigation of a tree-like hierarchy, especially when considering the premise “In a tree structure there is one and only one path from any point to any other point”.
The tl;dr is that UML does not necessarily have the ability to represent UI concepts of hierarchy and navigation effectively.
Introduction
In the design stages of UI, whether it be be a Desktop application, Mobile app or Web site a useful tool for understanding and modelling the interaction is to define a logical hierarchy.
The details of such hierarchies is domain dependent and much has been written on the topic, which I shall not attempt to retread. Broadly speaking, we would attempt to create categories and align “Pages” or “Views” to these categories, usually resulting in a tree structure. There are a few approaches to describing hierarchies but the more commonly used examples are
- Text-based “Outline”- e.g. a list using indentation and/or bullets to represent the hierarchy
- Graphical “Node linked” – e.g a graph of connected nodes with a single path from one node to another
In narrow-scope or simple applications the scope of the hierarchy will be small, however as complexity increases the breadth and depth will increase also. A typical problem encountered here will be deciding the most appropriate place for placing a node – this has a large effect on the User Experience (UX) as the location should match the user expectation; a task made harder when catering for multiple personas, cultures or languages. This part of the process will often result in compromises such as bending rules (categorisation rules) or duplication.
The UI design process must consider User tasks or workflows and an easy trap to fall into is to concentrate these within a single “Page” or “View”, indeed this may be the most appropriate approach. However, once the complexity begins to increase there comes an overload of information and a degradation of the UX, often leading to a separation of concerns and a build out of the hierarchy.
However as a hierarchy begins to grow, the interaction sequences may get more complicated and it can become more difficult to model user tasks or the overall UX of the application. The sequences must consider the navigation of the hierarchy and herein we explore that problem