[EuiIcon] Add tokenDimension

[dej611]

In Kibana we would like to improve support for fields of [time series dimension] type: (https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds.html#time-series-dimension):

elastic/kibana#163323

PR: elastic/kibana#163382

Would be nice to have a new token in EUI for this type of field: https://eui.elastic.co/#/display/icons#tokens,
Visually, I think it should somehow be related to a tag or a label, but this is already taken by the version field type: #5520

[cee-chen]

@MichaelMarcialis or @andreadelrio, do you mind responding to or taking this?

[andreadelrio]

Would be nice to have a new token in EUI for this type of field: https://eui.elastic.co/#/display/icons#tokens, Visually, I think it should somehow be related to a tag or a label, but this is already taken by the version field type: #5520

Given that tokenTag is already taken by the version field type, we could potentially use some of the ideas Elizabeth had for the tokenVersion which we didn't take further because it was decided to use the existing tokenTag.

We could do something like this and instead of the V use a D. @dej611 what do you think?

[dej611]

It would be nice to hint to time series somehow next to the D maybe.

[MichaelMarcialis]

@dej611: A while back, we added TSDB-specific tokens for gauge and counter metric fields. Is this request for a higher-level time series field token? Or would these tokens account for your needs here?

[andreadelrio]

Another option would be using the existing clock icon and passing it to EuiToken.

Or alternatively, do a mix of the D with a small clock though at that size it might be hard to tell what each element is (D, clock).

[dej611]

@dej611: A while back, we added TSDB-specific tokens for gauge and counter metric fields. Is this request for a higher-level time series field token? Or would these tokens account for your needs here?

The time series dimension is the complementary part of a time series metric, like a counter or a gauge: i.e. if you have multiple sensors for measuring the temperature somewhere, then temperature would be the gauge metric, while the sensor_id the dimension of the document.

Or alternatively, do a mix of the D with a small clock though at that size it might be hard to tell what each element is (D, clock).

I like this idea, but as you said the clock is big enough to cover the D and make the icon hard to clearly identify.

[JasonStoltz]

Hey all, any updates on this issue?

[dej611]

I would put this discussion on hold for the moment as there have been few changes in discussion and the outcome of such discussion can have an effect on how and what to define as "time series dimension".
I will keep it posted here and in case will ping to resurrect this issue.

[JasonStoltz]

Would you mind if we closed this as not planned for now, and we can re-open it later if needed?

[dej611]

sure 👍

[dej611]

@JasonStoltz the topic clarified a bit recently, so I think it is time to resurrect this issue. Do you mind to reopen this?

[cee-chen]

@dej611 Could we post what the final direction/design for the icon should be before re-opening? Or alternatively, if a designer simply wants to open a PR with tokenDimension, that would be fine as well :)

[dej611]

I think the design from @andreadelrio was on a good track. The clock icon was a bit too big IMHO.

[cee-chen]

@andreadelrio @MichaelMarcialis do either of you mind chiming in here before re-opening? Or alternatively @dej611 do you mind writing a bit more about what exactly was clarified on this topic?

[dej611]

The clarification happened more on our side, so no more to add on here.
But I can sum up the whole idea of the semantic for the token: as already stated here a dimension field is the counterpart of a metric field, hence it helps to group by a metric by one or more dimensions.

Let me make an example, say there are log records, metrics are extracted from here, and few dimensions can be defined as host, path, country . Users can then decide to see the metrics overall, broken down by host or by host and country, etc...
This exists only in a time series context.
Only keyword fields can be dimensions for now, but it could be potentially extended the support to other types in the future.

So here's some thinking point:

• it would be great to have a simple identifiable token shape to quickly spot dimensions vs non-dimensions
• it would be nice to hint something about time series in the design, but not strongly required
• if a dimension can be multiple types perhaps it's worth exploring the idea of having some indication of the sub-type (not important now, but perhaps to keep in mind for future iterations)

This is a full brain dump of the problem as best as I can do.

[cee-chen]

Thanks for the context Marco, re-opening. Would appreciate it if a designer could take it from here.

[cee-chen]

@MichaelMarcialis @andreadelrio Any chance we could get this looked at? Or know a designer we could assign this to?

[MichaelMarcialis]

@andreadelrio, did you wish to continue working with @dej611 on your D + clock token concept? If you've got other higher priorities, let me know and I'd be happy to jump in to help.

[MichaelMarcialis]

Hey, @dej611. I've put together some tokens for this issue. In addition to the requested TSDB dimension field, I've also put together updated concepts for the old TSDB metric counter and gauge fields. The reason for this update was so that we could incorporate some kind of visual connection/relationship between all the TSDB tokens (in this case, via the inclusion of a subscript-styled clock).

Options A and B explore the letter concept you and @andreadelrio proposed earlier. Option C takes a more abstract approach, using a folder icon to convey grouping/categorization, and a bar chart indicating only increasing cumulative values (counter) or values going both up and down (gauge). Let me know if any of these options hit the mark. Thanks!

Actual Size

Option A

Option B

Option C

Zoomed In

Option A

Option B

Option C

[MichaelMarcialis]

@dej611: When you get a moment, would you mind responding to the comment above on which (if any) of the options you'd like to proceed with? Thanks!

[dej611]

Sorry, missed the previous comment.
I think option A makes more sense to me.
I also like option C a lot, but for the I'm a bit afraid the folder icon is not easy to interpret as "dimension": for gauge and counter instead I think the icons work great. Maybe we can mix the dimension icon from A with the other 2 metric icons from C?