At Clariba we have many years of experience in the development and maintenance of SAP Design Studio and SAP Lumira dashboards. Early on we recognized the power these solutions have to produce stunning, actionable dashboards for C-level executives at top performing organizations in Europe and the Middle East.

With one of our prominent customers having more than 50 dashboards in production, and many other customers having similar complexity and volume, we developed the act·in | dashboard framework to provide a re-usable, component-based approach that allows for rapid development while also ensuring easier maintenance and support.

In this article we’ll share a few tips & tricks that we apply in our dashboard framework - hopefully you’ll find them useful:

1. CSS

Poor CSS, so useful and yet so disregarded! We’ve addressed CSS files first, as they are a common source of chaos, with endless lines of code which is hard or impossible to decipher without searching through the file line by line. To avoid this, there are some simple principles you can adhere to.

1.1   One CSS file for each screen

We’ve seen some companies with multiple dashboards sharing the same CSS. At first it may work okay, but as more dashboards are added, the single CSS file will become unmanageable, and keeping it updated will be impossible. So make sure each dashboard has its own CSS file.

If you have multiple dashboards sharing a CSS file because it’s a way to keep the design consistent, there’s a better way to do that - linking.

1.2   Link CSS files

CSS allows us to link different files to one another. We can have a CSS framework file in which we will create common classes for all dashboards, for example: the font type, title size, tables format, etc.

We can then link this CSS file to the CSS file that is being used in that specific dashboard, which will only contain the classes that affect it individually. By linking, we can access both the specific classes and the general ones found in the CSS framework.

To make this link we will create the two CSS files in the same folder, and at the beginning of our specific CSS we will make an @import of our framework:

1.3  Set the font type

Sometimes we find that the font type is specified in each class, which is unnecessary and causes more work if it needs to be changed. To define the same font for all of our dashboards is very simple - we only have to add a line of code. If we add it to the CSS framework, we only have to change this one line to change the font across all dashboards:

NB: This type of font is also applied to the icons. To be able to visualize the SAP icons we will have to specify the font as follows:

1.4  Add variables

So far we’ve used variables to standardise the colors that are used in the dashboards, but there’s more we can do.

Declaring the variables in the CSS framework means that if we want to change a color we only have to change it in one place. In addition, it allows us to maintain consistency of color across all dashboards without having to remember the correct RGB code each time. Instead, we just use the name of the variable that we have defined for that color.

Variables declaration:

Use of the variables:

2. Framework

It is important that we consider the common elements that will be shared across all dashboards, for example, the header, the footer, filters, tabs, etc. But it’s not just the visual aspect that we need to consider. There are also scripts that we can add to the framework, for example scripts to format texts, deviations, or to change pages, etc.

When we are going to start a new dashboard we can copy the framework and above that, add the specific elements of each new screen, always maintaining the same structure. Taking time to think about this before getting started on a new dashboard is always beneficial - we can save a lot of time.

3. Reusable Scripts

Creating reusable scripts is an important habit to adopt. It avoids repetition of code elements and greatly reduces the work involved in maintaining the code. To do this well, each script must contain a single task, and we should always try to reduce it to the minimum expression. We can then add input parameters and create scripts that return results which allow us to concatenate tasks and achieve the desired functionality.

4. Remove code from the buttons

Sometimes, we’ll come across client dashboards which have all the code in the objects. For someone who does not know the dashboard, it is very difficult to understand and maintain, furthermore it’s possible that code may be duplicated.

A better methodology is to only call scripts in an object rather than write the code them. It is useful to call a script by entering the object as a parameter, if we also use “this” to refer to the object itself, we can copy and paste the object without having to worry about changing the code one by one.

5. The basics

Last but not least, don’t forget the basic rules of programming - they apply to SAP Design Studio and SAP Lumira Designer just as much as to any language:

1. Limit the usage of global variables

2. Comment the code, but not too much, remember that good code should be understood on its own

3. Use easily understandable names, and avoid names that are too long

4. Maintain consistent formatting and indentation - this makes your code more readable

5. Structure the script into functions and group the functions into meaningful packages

6. Write functions in a generic way so they can be easily reused

These are some of the key elements that we apply within our act·in | dashboard framework to deliver successful projects in over 20 countries. We hope this article has been useful to you and you can apply some of these tips & tricks in your dashboard development.

If you have a strategy you want to share, or if you simply want to know more about our act·in | dashboard framework, please leave a comment or contact us via the details below.