...
Onesait platform has a very powerful and flexible dashboard system for data representation. In this tutorial, you will are going to create a dashboard that allows you to see the high degree of customization degree, the power of connection and interaction with the data, and the speed of development speed .
To do this, once inside the onesait platform, we will go to the Display> Dashboard Display > Dashboards Management menu, where you we can create a new dashboard.
Dashboard creation and initial configuration
...
To create a dashboard, we will go to its creation page and fill in the basic fields of identification, description, image, whether it is public or not, category and subcategory. The dashboard has a number series of properties that will allow you us to configure its operation. These are:
Para crear un dashboard, iremos a su página de creación y rellenaremos los campos básicos de identificación, descripción, imagen, si es público o no, categoría y subcategoría. El dashboard tiene una serie de propiedades que nos permitirán configurar su funcionamiento, estas son:
- Initial Dashboard Style (type):
...
- Initial Dashboard Style (type):
It allows you to choose an initial dashboard style that configures not only its style and behavior, but also a series of JavaScript and CSS libraries that can be loaded initially in the dashboard. These initial styles can be pre-created in the general management of the console by Administrator users to have a library of dashboard types where you can choose the style and initial libraries that the dashboard will load. This management (initial dashboard styles) has been recently added to the onesait Onesait functionalities:
...
In this dashboard that you are going to create, youwill you will use a series number of JS libraries and styles to use in several components such as the horizontal slider, the progress bars or the Datatable table. These files are the libraries of these plugins and their styles:
Permite cargar aquí una serie de archivos JS, CSS para poder ser luego utilizados en el dashboard, pensado para cargar plugins de terceros o estilos de UX acorde a cada proyecto, o controladores JavaScript con la lógica de ciertos gadgets template para estructurar, organizar y optimizar el código de los dashboards. Estos archivos y configuración es justamente lo que puede guardarse previamente en la gestión de estilos de dashboard, de la que hemos hablado en el estilo inicial del Dashboard.
En este dashboard que vamos a crear vamos a usar una serie de librerías JS y estilos para usar en varios componentes como el slider horizontal, o las barras de progreso, o la tabla Datatable, estos archivos son las librerías de estos plugins y los estilos de los mismos:
...
| class | codeHeader |
|---|
...
| language | xml |
|---|---|
| theme | Confluence |
| title | Estilos CSS |
| linenumbers | true |
...
| Center | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
|
Next, you will also load the additional JavaScript files for the plugins you will use:
| Center | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Next, you will also load the additional JavaScript files for the plugins you will use:
| Center | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Finally, still in this section of the dashboard configuration, you will enter a code to dynamically load AngularJS directives. This is very useful, since a part of the Dashboads engine is implemented on Angular:
...
| class | codeHeader |
|---|
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<script>
// DYNAMIC LOADING OF ANGULAR DIRECTIVES
window.addEventListener('DOMContentLoaded', function() {
window.setTimeout(
function(){
angular.element(document.getElementsByTagName('body')[0]).injector().loadNewModules(['angularjs-gauge'])
},0
);
});
</script> |
Dashboard Construction:
When building a dashboard, you must bear in mind several things: the dashboard's structure or layout and the components that you will include, which will be described in the dashboard's WIREFRAME. The other key element when building a dashboard is data. Data will give life to the dashboard's visual components and you must know what data they are, either DATASOURCES or API, and what filters or behaviors they have with each other, which will be describe in the dashboard's DATA COMMUNICATION.
Wireframe:
Just like in the Web design, a layout or an initial design is made to have a clear structure of the page. A dashboard is exactly the same, you need to know what information is going to be represented and how to define the spaces, the dashboard structure and the components that you'll need. Let's see these examples in the dashboard that you are going to build:
With this information, you can get an idea of the structure by knowing the proportions the zones will have, then, through the gadget wireframe, you get an idea of what visualization elements you are going to place in each zone to represent the information, and finally, to help the programmers and the dashboard's programming, you can also see the plugins that you will be using in each of the zones. Whether you are going to build a dashboard of a single gadget template with all these programmed elements, or you are going to use N gadgets distributed throughout the different zones, these functional design elements are always a reference, allowing to save a lot of time and above all maintainability of the same dashboard.
The resulting dashboard will look like this, although we still have to see how the data will be connected, and how gadgets interact with each other to filter the information:
Data Communication:
Once you have a clear idea about the dashboard structure (layout) and the visual elements (gadgets) that you are going to use to represent the information, you clearly need the Data to be represented. There are two ways to bring data from the platform to the dashboard: API (REST) and Datasources. Usually, due to power, data transformation and query optimization, we will use Datasources (advanced SQL query via webSocket with configuration, transformation, paging and filtering capabilities).
Just as it is important to be clear about the visual structure, it is equally or more important to know what data you are going to need, how is this data structured, and most importantly, how they are orchestrated with each other. That is to say, usually you are going to load 1 or several gadgets with their datasources, and you are also going to load multiple datasources in other gadgets templates. The important thing is also to know how the gadgets filter each other, giving life and power to the Dashboard. Let's see below the data schemas of this Dashboard:
...
Finally, still in this section of the dashboard configuration, you will enter a code to dynamically load AngularJS directives. This is very useful, since a part of the Dashboads engine is implemented on Angular:
| Center | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Dashboard Construction
When building a dashboard, you must bear in mind several things: the dashboard's structure or layout and the components that you will include, which will be described in the dashboard's WIREFRAME. The other key element when building a dashboard is data. Data will give life to the dashboard's visual components and you must know what data they are, either DATASOURCES or API, and what filters or behaviors they have with each other, which will be described in the dashboard's DATA COMMUNICATION.
Wireframe
Just like in the Web design, a layout or an initial design is made to have a clear structure of the page. A dashboard is exactly the same, you need to know what information is going to be represented and how to define the spaces, the dashboard structure and the components that you'll need. Let's see these examples in the dashboard that you are going to build:
With this information, you can get an idea of the structure by knowing the proportions that the zones will have, then, through the gadget wireframe, you get an idea of what visualization elements you are going to place in each zone to represent the information, and finally, to help the programmers and the dashboard's programming, you can also see the plugins that you will be using in each of the zones. Whether you are going to build a dashboard of a single gadget template with all these programmed elements, or you are going to use N gadgets distributed throughout the different zones, these functional design elements are always a reference, allowing to save a lot of time and above all maintainability of the same dashboard.
The resulting dashboard will look like this, although you still have to see how the data will be connected, and how gadgets interact with each other to filter the information:
Data Communication
Once you have a clear idea about the dashboard structure (layout) and the visual elements (gadgets) that you are going to use to represent the information, you of course need the Data to be represented. There are two ways to bring data from the platform to the dashboard: API (REST) and Datasources. Usually, due to power, data transformation and query optimization, we will use Datasources (advanced SQL query via webSocket with configuration, transformation, paging and filtering capabilities).
Just as it is important to be clear about the visual structure, it is equally or more important to know what data you are going to need, how is this data structured, and most importantly, how they are orchestrated with each other. That is to say, usually you are going to load one or several gadgets with their datasources, and you are also going to load multiple datasources in other gadgets templates. The important thing is also to know how the gadgets filter each other, giving life and power to the Dashboard. Let's see below the data schemas of this Dashboard:
With this information we quickly see the correlation between zones, gadgets and data sources (DS Datasources) directly with the first image. The second and third images show something that happens a lot in dashboards and that happens in the case of multi-datasources: Loading processes of multiple datasources depending on the interaction with its components. In this example we see that we have 4 datasources, 1 for each zone, and two loading processes, 1 the initial one, which is called "All", which initially loads the Datasource of Zone 1 DS_Plant and triggers the load when the data arrives. of the 2nd Datasource DS_Centrales, which in turn triggers the loading of the 3rd and 4th Datasources DS_Production and DS_Aeros, since they depend on the Central, and the central, in turn, depends on the Plant. The code that allows this fantastic interaction is:
With this information, you can easily see the correlation between zones, gadgets and data sources (DS Datasources) directly with the first image. The second and third image images show something that happens a lot in dashboards and that, in the case of multi-datasources, happenscan happen: Multiple data loading processes depending on the interaction with its components. In this example, you can see that you have 4 four datasources, 1 one for each zone, and two loading processes, 1 one the initial one, which is called "All" and initially loads the Datasource of Zone 1 DS_Planta and is triggered with the arrival of data from of the 2nd second Datasource, DS_Centrales, that in turn triggers the load of the 3rd third and 4th fourth Datasources DS_Production and DS_Aeros, since they depend on the Plant, and the plant in turn depends on the Plant. The code that allows this fantastic excellent interaction is:
| Center | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
...