[Discover] Histogram cleanup

[gvnmagni]

TL;DR The histogram could benefit from a design intervention that could improve its style and role within the Discover page.

This issue is meant to be a starting point to discuss about the role and implementation of the histogram at the top of Discover page. The main issues are related to its style, to its importance and therefore role within the page.

Dimension and proportions Currently, the histogram suffers a little its small height. The bigger risk in this case is given by how we read charts, unfortunately the chart proportions could affect greatly how we perceive trends and changes in values over time. To give a brief example, the following image show the same exact data displayed on 4 chart which differ only in term of proportions. As everybody can see, the chart itself can emphasise or reduce the importance of values and changes affecting a correct read and interpretation of data. We should take in consideration what would be the best proportion by default for this chart.

Chart typology

If there is little room to improve the histogram proportion and its visual importance, we should then consider if that is the right chart for the context. Barchart are the best option to compare height of bars and therefore to quickly understand if there are differences between two buckets, having a little height unfortunately affect enormously the functionality. Would be interesting to consider alternatives and see how they perform in the same context

Style

The current use of labels on axis and placement of elements could be revised a little bit to increase as much as possible the amount of space dedicated to the proper chart. Some work in this case is already in progress through other initiative but it is a good idea to consider this aspect as well.

As I said, this issue is meant to be a "conversation starter" and none of the images above are proper design solutions, the goal is start considering how to improve the current histogram not only revolving around its aesthetic but also its role and function.

[elasticmachine]

Pinging @elastic/datavis (Team:DataVis)

[monfera]

Great work @gvnmagni! Jotting down my initial feelings here.

A. Things I immediately like:

1. The more subdued, professional color (blue or grey instead of our green is a clear improvement)
2. The width of the bars compared to the raster pitch is nice (ie. there's just a minimal bar separator, as befits a histogram or continuous time series)
3. Presence of a more clearly readable grid raster (reading in Discover is on the quantitative side, so a sparkline-ish sparsity wouldn't serve that page as well as this nice grid)
4. Niced Y axis
5. Lack of an X axis line (see my point on a zero line below)

B. Things where it might contradict to the (current) context:

1. The current time axis tick labels are on the right of each tick line, ie. not centered underneath
2. On this mock, the middle of the bar is aligned with the tick/gridline, which works quite well with center aligned, categorical-style X axis tick labels, but doesn't play well with the current label positioning
3. There are time axis grid constraints with the design intent of preventing overly dense gridding (present in the top rightmost bar charts)-though it still looks good, and has merit. So maybe we'd need to make the minimum gridline distance responsive to the Cartesian width in pixels (the same density would be weird on a wide chart)

C. Things I wish could be added

1. (definitely important) Indication in the design as to how we're supposed to handle, if at all, a zero line, as values in the future can be negative, it's not necessarily just positive counts anymore(feels important) Redundant Y axis, due to the very wide aspect ratio typical in Discover and similar settings
2. (feels important or useful) The current time axis is hierarchical, and a purpose was to convey the structure and fabric of time, to help users preattentively grasp the temporal stretch in front of them. Eg. it's nice to see the day separator when plotting hours
3. (optional) Indication of the bin unit length and bin unit (may have been intended/permitted, but thought of it as a separate overlay)
4. (optional) Integration of the design with the other chart-bound overlays (time range indication, maybe even the buttons), for example, to convey how we increase the height of the Cartesian area
5. (optional) Constrain the bar density and/or bar count: for example, the bars seem super dense on the top right charts. This brings us to a philosophical question (Section D)

D. Control of the time domain and bin width I assume here a future state where we have zoom and pan. A direct manipulation zoom and pan directly controls the time domain, but not necessarily the bin width (therefore bin count). The bin width is important, and there are conflicting forces at play:

1. The user may be interested in a specific resolution, eg. "I need to see 5-minute bars". It's not super clear to me how particular our users are about time bins. For example, ES can serve 7min 13.7 second long bins. But are there actual users who would need it? Or even a 7 minute bin? Maybe it's enough to give eg. 1, 5, 15 and 60 seconds/minutes. Do folks need specific bins, like 10 or 20 seconds/minutes? Or is it enough if we have a dense enough coverage, eg. 1, 5, 15 and 60 is enough, or maybe 1, 2, 5, 10, 15, 20, 30, 60? Or even 3, 4, 6, 12? (Note: Offsetting doesn't matter, because even an offset value should, I think, be "slotted" tidily between two tick/grid lines, ie. it's just querying detail - shifting the bars would look odd too)
2. Too thin or too thick bars are problematic
3. In the presence of zooming, there must be an automatic control of bin size. Just making existing bars thin/numerous or thick/few isn't proper zooming. So the current control tuple of { timeDomain, binWidth } is substituted with { zoomLevel, intendedDensity } where intended density ranges from sparse to dense, but still leads to a decent number of bars, for the given Cartesian pixel width (eg. it's OK to have 2-3 bars on a chart that's 120px wide, but not OK on a 900px wide chart, etc.) My conclusion is that, since the time bin needs to be automatically controlled, the user would not typically control the bin width directly. Although, if needed, it'd still be possible for the user to set it directly, and/or tweak the density on the general "Forms UI" part. The user can't really zoom and use the UI at the same time. Of course, even if the user sets some custom bin width, subsequent zooming will probably snap out of that resolution

Maybe we can call it a kind of "smart summarization" 😄

E. Histo bar, categorical bar, points/lines In the past, the Discover chart was a pure histogram (counts) so the full-width, touching bars were sensible. We'd need to know if this is sensible for the currently envisioned new aggregates, and if not, what other geometries come in play. Also, how would the use of other geometries (lines, points, boxplots) influence the rest of the chart.

F. Preexisting design concept - timeslip A significant amount of design work went into the timeslip prototype, which addresses many of the items above, and took care of a number of other considerations (zoom and pan; fading out partial bars and tick labels at the edges etc.). It's also conducive for certain other types of geometries. The current mock above seems more suited for a categorical interpretation of time, in some contrast with the already introduced time axis. While there are some open questions above, and others may have too, I also wonder if we can take the timeslip prototype as a design orientation point and pose issues or design alteration suggestions relative to that

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)