Masks highlight what is relevant and conceal what isn’t. This applies to Mardi Gras and also to data in IT systems.
Every use case should have its own mask? Really? It’s design and implementation takes up too much time and means maintenance of the application is too costly.
When it comes to designing masks we experience the same thing again and again – that the use case details are crucial for the design of the view.
You need to draw up a job overview. All the users agree that it has to show the customer, the items, the scheduled date of completion and the guaranteed date of completion for every order.
However, there is disagreement about all the other details:
- The production managers/Group Management are mainly interested in all the delayed orders in order to gain an overview of the current problems.
- The assembly teams check which set-up processes are scheduled and mainly want to be informed of processes with very tight schedules.
- The dispatch department considers it relevant to know which products and quantities are produced on site and need to be packed.
For each of these use cases, addtional data and highlighting/sorting are required for a mask so that the user gets the relevant information quickly. Depending on the project budget and on how co-operative the users are, there are various solution approaches here:
- Focus is on one of the masks, the other use cases are neglected.
- A complex mask is created which caters to all use cases
- An individual mask is designed for each use case.
We have found that if you focus on creating a versatile, complex mask, then the individual use cases are not supported very well. This can easily be seen in the case of SAP masks. These show a great deal of information, right down to the very last detail and in some cases they are even distributed on several sub-tabs. In each of the named use cases, too much information was a distraction to the user. Focusing on one of the masks makes the other users’ work difficult and creating one mask for each user case is time-consuming and thus expensive.
The solution: individual views
We have frequently observed this conflict among the use cases in projects and have created a platform technology which solves the problem in development projects. When using the OPTANO solution, users have the option to change masks themselves at any time and they can store this change as a new view. They can use the new view themselves and also place it at their colleagues’ disposal (as an open view). In OPTANO, users can make the following settings themselves:
- select the columns to be displayed (from a pre-defined total amount)
- add several columns with calculation rules (similar to an Excel formula)
- group by one or more columns
- filter data by columns or complex formula expressions
- format the datasets, generally or data-dependently
If such a compiled view is saved, it appears in the tree view under the “original” view as an individual view with a selected name. If an individual view is no longer required, then it can simply be deleted.
Of course, it is still important that the project team chooses the required data fields in OPTANO appropriately and specifies the calculated information to datasets. The procedure becomes even easier, though:
- The required data fields are gathered and defined with the users.
- The number of these data fields then results in the total extent of a mask to be implemented which can be done with reasonable effort.
- The development team (or the user himself) creates individual masks based on the requirements of each use case.
This reduces the development costs and increases the value of the application because the users can adjust it to their preferences at any time.
Various user group views from the same basic view
View - delayed orders
View - Assembly team for hydraulics
View - Packing team Factory IMP
An unformatted basis mask
Info from Carsten, Reply AG: The SAP WebClient now gives you the option to store views. (However, you can’t group these views and you cannot apply conditional formatting). This web client is used in SAP CRM, among others.
Author: Jens Peter Kempkes