Prominence of measures and new features

[adrianmroz]

It's issue for discussion and suggestions. Ideas ready for planning and implementation should be assigned in new issues and linked here.

Rationale

We want to add more features connected to measures. We need to clarify them, try to generalise if possible and find good way to present them in interface.

Row for measures below Filters and Splits (#216)

We could add new row for measure pills below Filters and Splits rows above main visualisation. Measures could be placed there by drag and drop or after clicking measure on the left and selecting "Add" action.

Additionally, we could add "Add" action after each row of pills with context dependent dropdown (searchable?).

This way, these rows would play role of visualisation configuration summary and for most cases left panel could be hidden.

After clicking measure pill we would get configuration menu for it just like for filters or splits.

Filtering on measures (#41)

We could also drop measures on Filters row and use them as Having clause for filtering.

examples of having filters needed

Multiple formatters (#217)

Right now each measure have one format for displaying values. Would be beneficial to provide multiple formatters. Some users want general perspective on values and prefer nicely formatted numbers with metric suffixes. In other cases exact value would be preferred to compare values.

Percentile settings (#219)

For quantiles should be possible to pick percentile. Also should be possible to present multiple percentiles on same chart.

Percent of total and percent of parent (#218)

This "measures" should be possible to apply for all measures if there's any split.

Multiple measures on one chart

If measures are compatible (need to answer what make measures compatible) they could be presented on one chart.

Simple expressions for measures (#254)

Should be possible to calculate rations or differences between measures if they're compatible. It's extension of previous point.

[adrianmroz]

~~UI for measures~~

~~* "Add" button for measures/splits ... Search inside.~~ ~~* Row for measures~~ ~~* Actions: Add, Replace, Filter~~ ~~* Different colours for measures and dimensions (dimensions should have one colour)~~

~~Having filter for measures~~

~~* Available always for all measures.~~ ~~* Not supported for "virtual" measures~~

~~Formatter~~

~~* Default or from config file for measure~~ ~~* Exact (only if different than first one)~~ ~~* Percent ( 0[.]00% )~~ ~~* Custom~~

~~* Formatting for measure should be consistent in whole UI~~

~~Percent of parent/total~~

~~* Availability depending on number of splits. (from 1 splits)~~ ~~* Ignore current transformed measures~~

~~Percentiles~~

~~* this measure can be added multiple times~~ ~~* only percentile~~ ~~* tune params are defined in config~~ ~~* initial value from config~~ ~~* should handle adding measure with the same percentile value~~

Measure expressions

In Add dialog it's possible to create "virtual" measure. One operator (add, sub, mul ... ) and two non-virtual measures. (Think about percentiles).

[adrianmroz]

#218 #219 #254 are connected and need a bit more planning.

Main points:

1. Percent of parent/total is a kind of Measure Expression.
2. SeriesDefinition and DataSeries should have 1..1 relation. Hopefully we could merge them later, but for now, SeriesDefinition should hold information about selected Series and it's settings and helpers for UI of Series representation. DataSeries is responsible mainly for converting Series into plywood sub-query and for getting corresponding value from Datum.
3. Measure Expression have operation/transformation as field and it should transform Measure formula to correct plywood expression. DataSeries should handle applying period in generic way.
4. serialisation and deserialisation of Series is dead end. Series should be able to serialise into plywoodKey and used only there. Usages of nominalName should be removed. In TabularOptions we should search for key inside SeriesList and when defining sorting we should store whole Series or simpler representation - something tangible (more in #251). This is required for MeasureExpressions to work and will simplify query generation.
5. DragManager should differentiate between Dimension vs Split and Measure vs Series.
6. Split, Filter and Series should keep value of corresponding Dimension/Measure to simplify usage. Dimensions/Measures will not change during app lifetime and even then. we keep only immutable value. We won't need to thread DataCube through all of our application.