Application Navigation Design
1. Abstract
Navigation is "the act of moving between screens of an application to complete tasks".
It is about managing the path that the users can follow when using an application and therefore it involves defining the different navigation steps (based on the level of flexibility required) and eventually combining them with the requested workflow logics.
This should be an easy topic, however the experience teaches that it can often become a source of complexity in projects.
Especially in projects with a large user base and many different access rights.
2. Context
The purpose of this document would be to explain the main best practices to apply and common pitfalls to avoid when defining Navigation for a project.
This ultimately will allow BOARD developers to deliver a better User experience and more simple applications.
3. Content
3.1 Navigation in Reporting applications
The best approach to Navigation is to exploit the native functionalities of Board which are "Screen list" and "Menu". These two Board objects allow to give to the users the maximum flexibility and easily jump from one screen to the other without any processing.
These objects work very well in combination with the "DB/Role Security" and "Cube visibility" functionality and allow to keep to the bear-minimum the developments required around Navigation.
In this kind of design, the user is allowed to access every screen of the application and the restrictions are only data-related.
In practice, the "Menu object" and "Screen list" will show all the available screens and the DB Security/Cube visibility will be set up in such a way that each user can access only data to which he/she has been granted access.
Of course, this design is most suited for Reporting applications where it is not required to follow a strict navigation path and users can freely "jump" from one screen to another.
In these contexts, we suggest avoiding re-developing functionalities already native in Board by creating complex custom menus with Labels/Buttons and go-to procedures.
A data model is very often used for reporting and Planning purposes. To facilitate the application of the best practice above, it is always suggested to design the Capsules/Capsule Folders' structure to separate as much as possible the two purposes. Of course, every planning application will always include several screens dedicated to reporting but these are part of the planning process and therefore fit into the pre-defined planning workflow logic (see the following paragraph).
3.2 Navigation in Corporate performance management (CPM) applications
In CPM applications the navigation concept is more complex because it is often mixed with the required workflow logic.
In practice, this means that these applications require pre-defined workflow paths, screen sequences and workflow checks.
The use of the "screen list" or "menu object" can be cumbersome in CPM applications and we will likely be required to create a custom menu using the Label/Button objects.
The best practice in these cases is to make sure to create a home page that allows the users to see the sequencing of screens visually and, if necessary, jump directly to the screen of interest. Practically, this can be created with Label/Button objects.
The key goal is to make sure that the users are not forced to go through many different screens if not necessary. The use of labels and the creation of a custom menu do not imply the creation of a complex navigation. Regardless of the technical objects used we should always aim to create a clear menu that allows users to go straight to the relevant screen without many nested levels. This means that we should avoid designing a navigation path that forces users to tedious extra steps/clicks which are not always applicable (eg. "Home page>sub-home page>process specific screen > perimeter selection > Overview > Target screen" is probably an example of a navigation path that is to complex).
One additional best practice, which is very much connected to the one just mentioned, is to always structure the Navigation to minimize the number of times a user is forced to exit/re-open a screen. This means that we can develop a very well-structured navigation path, however if we force the users to re-open the same screens too many times, we will end up with poor navigation and user experience. Most of the time this can be avoided by analyzing the common perimeter of work of the user-base and introducing dedicated objects (pagers, selectors, procedures) which allow the users to complete their tasks in that area of the application without re-opening the same screen many times.
Another best practice, since the workflow and screen sequencing are very relevant in these applications, is to display where applicable the workflow status and overall progress of the planning process directly on the home page. Again, this will give the end users visibility of the overall process and allow them to jump directly to the target screen. In these cases, features like the "Visibility" of labels and buttons can be used to guide the users and show the screens and process steps that are active/available at that moment. This setup works very well in combination with the new feature "Cube visibility" which is automatically applied to all the layouts built using the visibility cubes.
The usage of labels and buttons to improve the UX and application Navigation does not imply the creation Go-To Procedures which are then attached to the buttons/labels of the menu. We can see that this is a common practice in several projects, however the best approach is to avoid this kind of setup to reduce development effort and improve the application's maintainability/usability. This point is explored in more details in the following paragraph.
In general, a good practice to simplify navigation is to exploit the feature “Folder profiles”. This is a feature that allows to set up for each capsule folder a series of access rights. This does not replace the best practices above but can remove complexity from the overall navigation design and implementation. In order to use this at its full potential this feature however it is required to apply also another best practice which is to use the “multi-capsules” approach.
3.3 How to use the Cube Visibility to Simplify Navigation
Whether we are developing a reporting or a CPM application the best practice is always to try to avoid the procedures developed only for navigation purposes. The cube visibility feature helps us to simplify Navigation in this sense.
The cube visibility should be used as follows:
- Define visibility cubes: we need to bring into the Board data model the information necessary to manage data visibility; these are usually cubes by User/Role and other Entities of the data model (i.e. Product, Customer, Scenario , etc);
- Configure the "Cube visibility" setup for all the cubes necessary: this is done in the Database Security area (please refer to the manual for details on the configuration);
- Design the Navigation without embedding access definition steps which are already covered by the cube visibility
The best way to describe is probably through an example. Let's suppose to have the following requirement:
Users can have different Roles. For each Role, they can visualize data differently. "Planner" role can see a certain combination of Company-Cost Center, "Reviewer" role can see different combinations.
Using the pre-Summer 2022 versions, this requirement would have been addressed often with the following setup:
- DB security: this would have been defined on each security axe/entity , plus the @User security would be applied; so, in our example for User1 we would have had
- User = “USER1” (through @User),
- Role = "Planner, Reviewer"
- Company = “Acme A, Acme B” and
- CC = “1001, 1002, 1003”;
This allows a selection of all the possible combinations of the 4 axes;
- Navigation:
- Home page: here an initial navigation step is mandatory, to choose the "Role"
- A "log-in" screen which shows the combinations of Company-CC based on the role is necessary before landing in the final screen
- User will select one of the allowed combinations and finally get to the screen of interest
- Go-to Procedures: each step of the Navigation above is done with a procedure which contains "select based on" steps, which narrow down the selection based on the visibility cubes and Navigation (i.e. in the end USER1 will open the final screen only with one valid combination of Company-CC);
Of course, there are countless examples however the one just described is one of the most common. In any case, what is really relevant is the fact that to answer the requirement we had to use/develop ad-hoc procedures and make more cumbersome the user navigation.
With Cube visibility we can simplify the above example as follows:
- DB security: same as above
- Navigation:
- Home page: choosing the "Role" is NOT anymore mandatory: the user can choose it directly on the final screen since the "cube visibility" differently from the procedure approach is immediately applied on refresh (i.e., procedure execution is not required);
- A "log-in" screen that shows the combinations of Company-CC based on the role is NOT necessary before getting to the final screen; since it is now possible to visualize only the relevant combinations in the final screen, the intermediate navigation step can be avoided completely;
- Users can switch from valid combination to the other without running again a procedure;
- Go-to Procedures: can be avoided as all is already managed in a centralized way with the cube visibility;
As you can see, we have achieved the following improvements:
- Navigation is simplified and only defined to improve the usability
- Fewer procedures to develop and for the users to execute
- Centralized definition which is much easier to manage in terms of maintenance
- Flexibility: the definition of data visibility is now at a combination level
- Immediacy: any change is immediately reflected in the application and can be even managed by the end-user without many navigation steps