Slicing dashboards

Slicing is a mechanism to compute many variants of the same dashboard and let end-users interact with the resulting sliced dashboard through a search-like navigation. For example, through slicing, it is possible to create a product inspector which consolidates - for every product - all the KPIs and linecharts of interest.

The following script provides a simplistic variant of such a dashboard:

table Products[pid] = with
  [| as Product, as Color, as Price |]
  [| "pants",   "blue",    25       |]
  [| "shirt",   "white",   15       |]
  [| "socks",   "green",   5        |]

table Slices[slice] = slice by pid title: Products.Product

show table "My Products" a1c3 sliced with
  Products.Product
  Products.Color
  Products.Price

In the above script, by pid defines the groups and title: Products.Product sets each slice’s display name. The selector lets users choose a slice by that name. The sliced annotation partitions the table tile’s data by slice.

Creating Slices adds slice as a secondary dimension of Products. The argument-free sliced annotation uses that dimension. For another data table, propagate the dimension explicitly when needed, as in Orders.slice = Products.slice. See the current slicing reference for complete examples, including sliced linecharts.

In summary, we have:

• Slices, a table. Each line of this table corresponds to a view of the dashboard that can be selected by the user.
• slice, the primary dimension of the table Slices.
• sliced, an annotation on supported tiles that partitions their data by the slice dimension.

When a tile is marked sliced, its input table (the common table of its input vectors) is partitioned by slice. The resulting tile is computed separately for each slice. The selector chooses which precomputed variant is displayed. Inside show chart, the annotation belongs on individual blocks rather than on the tile. Tiles without sliced keep their global data, although their StyleCode may still vary per slice.

The table Slices can be defined at most once in an Envision script.

The option by behaves like it does for any aggregator, the only limitation being that the number of slices is limited to 200,000. In particular, it is possible to use multiple vectors through the usual syntax by [expr1, expr2, expr3].

The creation of the table Slices accepts an optional subtitle to specify a label (the first argument is the name, see above). The label can be used to enrich the slice selector as illustrated by:

table Products = with
  [| as Product, as Color, as Price |]
  [| "pants",    "blue",   25       |]
  [| "shirt",    "pink",   15       |]
  [| "shirt",    "white",  15       |]
  [| "socks",    "green",  5        |]

table Slices[slice] = slice by Products.Product // implicit line continuation
    title: Products.Product
    subtitle: join(Products.Color; ", ") by Products.Product sort Products.Color

show table "My Products" a1c3 sliced with
  Products.Product
  Products.Color
  Products.Price

In the script above, the second argument join(Products.Color; ", ") .. is the concatenation of the color values. Indeed, unlike the previous example, the shirt slice has two elements instead of one as we are grouping by Products.Product (while we were previously leveraging the autogenerated dimension Pid of the Products table).

The option by Products.Products is required in the script above, but this requirement is somewhat accidental. As the table Products appears on the left side of the assignment, into Products is added by default to any aggregation that does not specify its by on the right. However, in this case, the target table for the text concatenation is not the Products table by the Slices table itself. This quirk would also be eliminated by the future syntax (cf. roadmap above).

Advanced remarks: Envision, and its implementation by Lokad, is geared toward batch processing where scripts are run fast, from minutes (for the big ones) down to a few seconds (for the small ones). Once the execution of a script is complete, our goal is to maintain a latency under 500ms to display even very large dashboards over typical internet connections. However, our goal is not to run a script (even a small one) in milliseconds. Indeed, guaranteeing low latencies while supporting a language having the level of expressiveness of Envision is a devilishly difficult problem. The slicing mechanism can be seen as a way to cheat with latencies. Instead of being able to compute a small dashboard very fast (while enforcing plenty of restrictions on the computations themselves), Lokad precomputes up to a large number of dashboards (with no particular restrictions on the computations), and then serves the pre-computed results very fast. Under the hood, each slice remains stored on the server-side and only gets pushed to the client browser when the slice is effectively visited.