UML: Modelling User Interfaces Part 1 - Hierarchy and Navigation

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

Documenting Hierarchy

If one wishes to design with hierarchy in mind, the tree must be documented. As stated earlier, the styles are generally textual or graphical and there are a range of documentation methodologies. Another consideration is how much of the hierarchy to expose to the User; while making the hierarchy explicit to the user may help their mental model of the application, the need for this may be a good indicator that the hierarchy is too complicated.

A documented hierarchy will help aid the communication with stakeholders in the design process but how much can it help in the software implementation process? Considering Model Driven Design, is there an appropriate UML diagram?

Of the available UML 2.x diagrams my opinion is that Activity or State Machine diagrams are the only appropriate and I would argue that they are not effective in this purpose.

Hierarchy Navigation

Continuing upon the earlier established notion that the hierarchy is tree based, navigation between nodes should be based upon a single path. However, practically this is an artificial constraint to place upon the user and would seemingly increase the number of steps required to achieve a goal, increasing workload and potentially reducing User satisfaction.

A method to overcome such issues is to loosen the navigation rules between nodes and allow the user to jump between them more easily, for example allowing a user to navigate to a different “Page” by presenting common shortcuts (identified through research, design or user trials) or simply by the nature of the underlying implementation i.e. access through a browser. The risks with this approach is that we may interrupt the sequence of a user task, something that is not desirable for an atomic task such as a shopping cart. However, this issue is inherent in web implementation and various mechanisms have been developed to overcome this, the scope of which fall outside this post.

In my experience, there is a “leap of faith” that must be made when transitioning from a logical hierarchy design to the implementation. The rules of navigation seemingly fall outside the documentation of the hierarchy itself into global rulesets, comments or worse are implicit knowledge in the engineer’s heads. In such a scenario, the hierarchy tree’s effectiveness as a documentation artifact becomes limited.

Apple’s Storyboard (https://developer.apple.com/library/ios/documentation/general/conceptual/Devpedia-CocoaApp/Storyboard.html) approach provides a convenient method to document both hierarchy and navigation. I have used this for a trivial application and found it offered a better approach than the UML one that I will discuss later on, however I do wonder if it wouldn’t be affected by the same issues once scaled to a larger application / hierarchy.

Android’s Activities (http://developer.android.com/guide/components/activities.html) and Fragments (http://developer.android.com/guide/components/fragments.html) offer another interesting approach to the problem. In my experience they offers a good method to manage User tasks and indeed the transitions between them, especially in terms of implementation. However, I do not think that they help document or expose the overall hierarchy of the application.

In a “leap of faith” scenario, we have the design and implementation disjointed and this limits our capability to engage stakeholder, prototype and iterate; core tenants of both the User Centered Design and Agile movements.

So, in a Model Driven approach can we model the hierarchy and navigation issues set out?

UML Hierarchy and Navigation

For the purposes of this article, consider that we have chosen to model the hierarchy as a UML 2.x State Machine diagram. The application initially has the following hierarchy

  • View 1
    • View 2
  • View 3

Assume that the User is allowed to visit any view and that there are no “dead ends” i.e. the user may always navigate to another view. The only restriction being that the user is not allowed to navigate from View 2 to View 3 or vice versa.

The initial instinct would be to model this State Machine similar to a graphical tree representation of the hierarchy, as in Figure 1. However the UML rules state that transitions must be uni-directional meaning that for complete traversal we will need two transitions, leading to Figure 2.

Now assume that after some user feedback, the restriction on navigation between View 2 and View 3 was found to be problematic and we are required to have a direct transition between the two; leading to Figure 3. The State Machine diagram at this point is still fairly simple and adequately documents the hierarchy and navigation. Indeed the transitions allow for unique behavior when navigating between View pairs, which is something that we may require.

Now apply the methodology described in the previous paragraph to a web site, where the user has the possibility to access a page directly by URL and has freedom to use the back button (we shall ignore transactional behavior in this scenario) . The reality of this approach is that every state must contain two transitions to every other state, for N states there will be N*(N-1) transitions; for a simple 6 page site we would need to explicitly specify 30 transitions, which from a modelling and implementation perspective is costly to create and maintain. The diagram starts to become more akin to a circuit design and its comprehensibility suffers, although it captures the required information it is difficult to digest. For example, compare Figures 4 and 5, what is your opinion, are they both correct? (Hint: no)

Figure 4 was my initial attempt at a 6 state machine and I only realised it was incorrect by manually counting the transitions!

Now I fully admit there is an element of style to factor in, and it could be possible to lay this diagram out more clearly, use a different tool etc. However I would argue the diagram fails to clearly articulate the navigation rules established earlier, and is brittle to change going forward. The addition of 1 more page would increase the transition count to 42 and probably require the diagram to be laid out differently - a costly effort.

Alternative State Machines

Considering alternatives to avoid the transition explosion above, we could attempt to use a choice object. This would yield a reduction in transitions to be 2*N (for N states) at the cost of losing the ability to have explicit actions for certain transition between Views. The implementation would also need a method to base the choice on and to pass this as a parameter alongside the transition trigger. As the diagram scales up, this diagram offers little visual advantage over the previous diagram because the choice object will become cluttered with transitions.

There are a multitude of other layout possibilities, each with their own compromises and each requiring an understanding of the UML syntax that may stretch a stakeholders knowledge. I repeat an earlier point, if the diagrams cannot clearly articulate the solution then their value becomes diminished.

Conclusion

My opinion is that UML is not the correct mechanism to model UI hierarchy and navigation. The permutations of State Machine diagram are both terse, error prone and brittle to change. As a counter argument the complexity of the navigation is fully captured and exposed in the state machine, this is a good thing from one perspective (quality: all paths have been considered). Unfortunately the model is not simply for the implementers but all stakeholders and I feel it fails at the effective communication task. If a stakeholder cannot understand the documentation then their ability to provide critical feedback is affected and there begins an implicit trust upon the model progenitor. There can be value, I do not feel the cost/benefit ratio is high enough.

Generally speaking, a logical hierarchy can be expressed in quite simple terms but we seem to struggle to translate this into a explicit terms; I would offer that the current state of the industry with various approaches to this problem highlights this.