-
Notifications
You must be signed in to change notification settings - Fork 11
Description
I was using tidymetrics in a screencast and I noticed how much more opinionated it is than it needs to be. This makes it difficult to get someone up and running,
I'd be very happy to implement this myself but wanted to run the approach by you @ramnathv
Current interface
Right now, create_metrics() requires the following in the YAML header:
name, which it then splits into three parts (because the first is generallymetrics_), and the second and third turn intocategoryandsubcategoryownermetrics, withtitleanddescriptionfor each metricdimensions, withtitleanddescriptionfor each metric
Proposal
I'm proposing a new interface. First, all the metadata is optional, so that if you run create_metrics on a table with a date column you'll get something right away.
category(optional)subcategory(even more optional)owner(optional)metrics(optional): If this doesn't have anything in it, the titles will be the metric IDs, and the descriptions could be blank.dimensions(optional) If this doesn't have anything in it, the titles will be the metric IDs, and the descriptions could be blank.
(For reverse compatibility we could maybe allow name that gets split up into category/subcategory, but I'm not even sure about that).
How we'd handle this in shinymetrics is an open question. If a description is NA, it could show no description at all, or could say something like "To fill in a description, add description: to the metric's metadata" or whatever.
Note that this would make the metric full IDs less strict; they wouldn't always be category_subcategory_prefix_metric, they might just be category_prefix_metric or just prefix_metric. But I think it's worth it to have people get up and running with a metric really quickly.