EN | ES
| Table of Contents |
|---|
There are two typical ways of working with platform dashboards, In the first one, a single user is in charge of all the tasks, while in the second one, there are different profiles.
Single Role
In this case, the one user will do all the tasks. This role isn’t an expert, tipically it’s a business knowledge user but don’t have high tecnical skills:is a non-expert role, typically a user who knows the business, but does not need to have great technical skills.
Quick generation of reposrtsreports/dashboards.
Use of builtin gadgets or prebuilt templateAll elements are created in pre-built templates.
Creation of all the elements from the dashboard engine.
Simple use of datasources. Can be necessary an expert user for this tasksPresentation through URL management of data sources: The collaboration of a data expert or queries may be required.
Direct presentation through the url of the dashboard or controlpanel access
Role splitting
With the role splitting, we’re going to paralelize and assigns the task an iterate between them easily. All the development layers are independent so this can prevent from blocking developer from each other. This have a zero cost of integration because all layers are linked by a pointer
...
access to the control panel.
It will be a role that uses, and only uses, the pre-built templates or gadgets.
Role splitting
In this case, we will address much more complex dashboards, focused on client customizations, and we will want to have a division of the work to be performed. A user can monopolize all the roles or just one and, depending on the complexity of the case, all the stages of development may be necessary or not.
...
By having stages in the process, we will be able to divide the work and iterate easily. All the layers are decoupled and, therefore, allow the work of one team not to affect another’s and, in addition, they make it possible for the integration cost to be completely null, by having reference to the lowest level components.
Starting from clear requirements, we can have some datscientics a data scientist uploading data to the platform and writting the diferent datasources. Front developer could only have tasks modeling the different data sources. We can have a front developer who is only in charge of building gadget templates (will always develop outside of the dashboarddashboards), while one layout designer can focus on dashboard design and interactions and can have the new upgrades of gadget templates only refreshing the dashboarda designer will link these templates to her dashboard and, simply by refreshing it, she will be able to see the changes that have been included. In the integration layerpart, we will have the same thing, case and we can have some developer dealing with the task of integrate the dashboard engine in the front aplication with use URL way of VueJS wrappera profile in charge of integrating the engine in other applications, also in a decoupled way, through URL or the VueJS Wrapper.
...