Skip to main content

Archipelo Dashboards

Archipelo dashboards are interactive visual displays that present data in a meaningful way. They help you quickly understand key metrics from all the data sources that we collect in Archipelo. They help find and understand patterns, and insights from the data collected. Archipelo Dashboards offer a variety of widget types to create informative and engaging visualizations.

Widgets Configuration​

All the widgets in dashboards are described by a simple struct with all the configuration parameters. Some of the parameters will be later adjusted to remove redundant fields. Today the struct can be found in widget_configuration.go.

There are a couple most important configuration parameters.

Queries​

This section is described in more detail in a separate document queries.md.

A single widget can have a list of queries, and these queries can be interdependent. This means that a single query can return an output that can be accessed by other queries through a variable name.

WidgetType​

We can divide widgets into two categories. Some of them are reusable and very generic and other are quite specialized to meet designs.

Generic widgets​

chart​

The Chart widget is used to display charts in a graphical format using ChartJS library. It supports:

  • line
  • bar
  • pie
  • circle

table​

The Table widget is used to display any kind of data in a tabular format. Data for this widget contains an array of rows and each row consists of multiple cells. It supports pagination.

list​

The List widget is used to display data in similar way to table form but is a bit more specific. It doesn't support pagination and has a couple additional ways of representing data.

single-value​

The Single Value widget is used to present one value and in addition to that a trend icon.

density-grid​

The Density Grid widget is used to display data in a kind of table with bubbles. I gets 2 dimensions of data and also 3rd dimension which is the size of bubble. It can be used to build age analysis graphs.

segmented-bar​

The Segmented Bar is a kind of linear version of "doughnut" chart. It presents n categories of data with values assigned ot them.

Sepcialized widgets​

The Header widget is used to display a header for reports.

segmented-circle​

The Segmented Circle widget is used to present a donoughts chart with some additional custom summary. Data presented in this component should actually be presented in 3 separate components if this component was more generic. Currently it presents doughnught chart with categories, inside the dougnouts there is a sum of values of all categories. In addition to that it presents numeric value on the left sie of the component, trend icon and some textual summary.

summary​

The Summary widget is used to display a summary of data. It is very complex widget because it also can contain subwidgets. This complication is introduced to meet designs but in general should be avoided and replaced by usage of more generic widgets.

issues-table​

The Issues Table widget is used as a specialized type of widget to meet quite specific design of present issues.

report-data​

The Report Data widget is used only as a container component. It contains other components inside.

Display Type​

This section should be replaced with more precise configurations of chart widgets. Today the only place where WidgetType is used is to distinguish bar chart from line chart. Both in fact can become separate WidgetTypes

Scale​

The Scale struct defines the range and unit of measurement for a widget. It is optional parameter. It helps ensure that data is displayed consistently and accurately based on expected range and unit.

Fields:​

  • Min: The minimum value of the scale.
  • Max: The maximum value of the scale.
  • Unit: The unit of measurement for the scale (e.g., "seconds", "%").

Example:

"scale": {
    "min": 0,
    "max": 100,
    Unit: "%"
}

ColorPalette​

The ColorPalette configuration parameter allows you to define the color scheme for your widgets, ensuring consistent presentations.

Some of widgets may require determining sequence of colors while other may nees color per cateogry (name).

With sequence of colors each data series visually distinguished from each other in consistent way. Configuration provides a set of predefined color palettes, each containing a sequence of colors.

Category color palette is used when you want to assign specific colors to specific categories of data. You can define a mapping between ategories and colors. As an example we can think of severity names to be consistently presented on each type of charts and widgets. In such way each data series names critical will be always presented using the same shade of red.

Params​

Some components may require custom configuration. An example of such component there is list widget which accepts some configuration parameters that are specific to this type of component. In this example there are 3 params positiveGood, valueType and listType.

SubWidgets​

Contains a list of subwidgets that should be displayed as children of a given widget. An example of a component that needs it is Summary component which we know from its description that we should avoid using such pattern. Eventuall we should probably get rid of this configuration parameter or alternatively extract container components and regular components. In that way only container components could have sub widgets an in addition to that continaer components should have any other beahvior other than just organizing child components.

Contains a list of subwidgets that should be displayed as children of a given widget. For example, the Summary widget currently uses this to display sub-components. However, we should avoid this pattern as much as possible.

Future Considerations:

  • Remove SubWidgets: We should aim to eliminate the SubWidgets configuration parameter entirely.
  • Extract Container Components: Instead of using SubWidgets, we can introduce dedicated container components (like ReportData) that specifically handle the organization of child components.
  • Container Component Behavior: Container components should have minimal behavior beyond organizing their children. They should not introduce additional logic or complexity. This approach will lead to a cleaner and more maintainable codebase, with a clear separation between container and regular components.