rilldata
add a default label+description to the measure created by the "quick metrics" button
To help illustrate to users what the default populated measure means, we should add a defaul label "events per time period" and a default description "the number of events recorded during the selected period of time". The default number formatting is probably fine for this.
@AdityaHegde for implementation, @magorlick for string refinement and prioritization.
Would love to get this in - I would call COUNT(*) "Total Records" because we don't really know what the data represents, but every row is a record.
In the case of measures, I think we do know that the data represents a count of events -- because we currently only handle measures when given a time dimension, we are treating the upstream data model as an event table, wherein each row is treated as a time stamped event. Indeed, part of my intent in filing this issue is to clarify for users that what they are seeing is an aggregation of metrics over events. I'm not attached to particular language, but that is the correct semantics for the Explorer, and I think we ought to try to explain that mental model.
Right now we say nothing, which is entirely ambiguous, but even "Total records" is pretty ambiguous and doesn't really do as much as we could be doing to help teach users what the product is doing and help them build up that mental model of the workflow/pipeline. Obviously the current state is not good -- if a user is dropped into the dashboard and just see a line chart called count(*) it doesn't really do anything to explain what is going on, but e.g. "Total records" is (by design) semantically equivalent-- it's the phrase that would be correct to use if we really didn't know anything else about the structure of the data.
Thinking about this more, I think we can go even further than I originally suggested: we should incorporate the the name of the time column that "quick metrics" selects into the default label and description to give the user even more clarity about what we are doing. This is particularly important since we are automatically selecting a timestamp and it may be the wrong one. So, for example, if a data set has time columns receive_date, shipped_date, and order_date, and we automatically select receive_date, the count(*) measure we auto-create should have something like:
label: "Count of events, ordered by receive_date"
description: "The number of events recorded during the selected period of time, ordered by receive_date".
@magorlick you've mentioned in the past not liking it when tools auto-populate things and do it badly -- I think that the automatic choice of a timestamp column is a risk for us in that regard, so I think we should really try to lean into detailed default strings that help illuminate the choices we've made so that users can understand and correct any mistakes made by the "quick metrics" action, and that we should err on the side of over-explaining and verbosity in order to make sure that this info is "above the fold" when a user tries the "quick start" feature.
In the example above, receive_date is almost surely the wrong timestamp. What I think we should try to accomplish is to give the user enough breadcrumbs to be able to figure out what they are looking at in the dashboard ("oh ok, what I'm seeing has something to do with events of some kind"), that they probably want to change the timestamp to order_date ("hmm wait, receive_date events don't really make any sense for me, why would it be ordered by that? I'm interested in sales.), and perhaps that they could simplify label to just be something like "Number of sales".
Total Events assumes that the data they ingested is a time series, however it isn't necessarily true. I think we should design this in a way where in the future you can get meaningful insights for datasets that are not events over time. For example, leaderboards on a catalog with different metrics would be a great dashboard experience.
Users appreciate clarity but also brevity, and I think that the label should be either "Total Records" or "Total Events" and those details around how it was generated belong in the description, which would also be nice to automatically populate. If you have a strong feeling about "Total Events" in the context of the product today that is ok, but we might need to update this in a world where timestamps are not required to see a dashboard.
This issue should have been tackled a while ago, but I think @AdityaHegde could probably quickly patch this in. Re-assigning
