[User Experience] Proposal for design polish and improvements to the view

[formgeist]

Summary

I've been meaning to summarize some suggestions for design polish and improvements for the new User Experience - in an effort to round off the app before release.

I've put together a Figma mock that exemplifies a lot of the suggested improvements but also has some clarifying questions around what's being displayed. Feel free to comment back in the Figma file. I've listed them below as well, for those not familiar with Figma or have trouble viewing them.

→ Figma review file

• 1. Is there a unit?
  - [ ] 2. "Longest task duration"?
• 3. Looks like we could need another time format for going to minutes.
• 4. Delimiter for numbers
• 5. Feels like the frontend and backend need to sync on the unit - in this case it was showing "0.88 s" instead of 880 ms.
• 6. This feels very round compared to everything else on the page. I think it's fair when you're above 10,000 page views to start rounding to K, but anything below should be able to be displayed as absolute.
• 7. Aligning page view reports together (page views + by browser and operation system).
• 8. Aligning page load duration metrics together.
• 9. Add label for the different levels. We should also align with Google's definitions, so "Average" becomes "Needs improvement".
• 10. We should have tooltips explaining each of the metrics for users who are not familar with them.
• 11. Add title and metric agg. label
• 12. The green feels too related to the status above in the Core Vitals. I wonder if we can assign the blue in the palette for "no breakdown" / overall visualization. Once we group by any of the dimensions, we can use the default palette assignment.
• 13. Same as the Page load distribution visualization - use blue when there's no breakdown. Additionally, the percentile markers could use a monochrome color to separate from the visualization. They become easier to spot.
• 14. Are these values averages?
  - [ ] 15. Increase section title (euiTitle default size)
• 16. Change takes to is for the mouse over description on CLS only
• 17. Initial (simple) clarification of which metrics are affected by the percentile selector (with a better UX addressed in [User Experience] Improved UX for the percentile selector #79263)

cc @drewpost @shahzad31 @elastic/observability-design

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[drewpost]

Thanks for this @formgeist ! We've been doing bits and pieces of this so some of these may already be covered. Let me address your points:

1 - This value is being removed so moot point now
2- "long task" is a thing and you're looking for the longest one of the long tasks. The label is a bit awkward but I don't have a better suggestion!
3 - Calculation error. This will never be that long. Longest should be in the tens of seconds range at absolute worst
4 - Calculation error. This will be less than 10 usually
5 - Had some chats internally about this. Backend time is very granular and benefits from being in ms as the granularity is meaningful. It's not so much in front end time. Elastic has a pretty fast site. usually these values will be in seconds with tenths of a second decimal places as any more fidelity isn't truly useful. It would also be weird to see ms here as you'd be having to convert into seconds mentally.
6 - I agree!
7 - Not 100% sure what you mean here? We do have the breakdown option that lets you view that chart by the dimensions you mentioned. Is that what you're after?
8 - Not sure I follow, sorry!
9 - Love that
10 - TOTALLY agree. I've asked for that, explanations that some browsers don't support all metrics and also a link to the web.dev article about core vitals.
11 - Agree. They're median. @shahzad31 was going to add a percentile selector that could also double as a label? WDYT?
12 - Agree. Steer clear of semantic colours
13 - Great improvements
14 - Medians but the values on core vitals are going away
15 - Good shout

[formgeist]

Thanks @drewpost - I've commented back on the ones that you had questions for. Happy that the rest was useful...

2- "long task" is a thing and you're looking for the longest one of the long tasks. The label is a bit awkward but I don't have a better suggestion!

Could it be "Slowest long task duration"?

5 - Had some chats internally about this. Backend time is very granular and benefits from being in ms as the granularity is meaningful. It's not so much in front end time. Elastic has a pretty fast site. usually these values will be in seconds with tenths of a second decimal places as any more fidelity isn't truly useful. It would also be weird to see ms here as you'd be having to convert into seconds mentally.

Alright, perhaps assumed that the Elastic.co website was a good use-case. I just though it was strange to see the Frontend display 0.88 s instead of 880 ms. Just thought the format would be more dynamic and based on typical thresholds, instead of a hard set value e.g. seconds.

7 - Not 100% sure what you mean here? We do have the breakdown option that lets you view that chart by the dimensions you mentioned. Is that what you're after?

8 - Not sure I follow, sorry!

So I'm propose to flip the map and pie charts so the relevant content is vertically aligned. Right now, the page duration visualizations are across from each other and the page views are across from each other. I understand they're in different sections, but I didn't think flipping the map and pie charts would confuse anyone, and the benefit would be to have the page view information together vertically.

Before

After

11 - Agree. They're median. @shahzad31 was going to add a percentile selector that could also double as a label? WDYT?

Yeah, I think that can work too. Probably still need a panel title and then a selector. Will the metric aggregation only be for those metrics displayed or also for the Core web vitals underneath? Because then it might be better to have the aggregation selector by the section title "User experience" - thoughts?

[drewpost]

Thanks @formgeist

2 - I like the idea but I think we need another synonym for duration. Slow implies speed and it really isn't a speed thing. It's more about the duration that task was running.

5 - so for the front end, if it's below 1s it shows ms but above, uses the 3.4 sec type format? I'd be happy with that.

7/8 - ahhhh, that makes perfect sense and I like the balance. I'd say go for it.

11 - Good point. It will apply to the user experience metrics only. The Core Vitals are basically mini distributions already so wouldn't be impacted.

@shahzad31 over to you for how you'd like to handle this (ie a single ticket, etc)

[formgeist]

@drewpost Small question; for the Core web vitals distribution definitions, we're pretty close to the Google definitions, but "Average" is "Needs improvement". Was there a decision not to align there?

[drewpost]

@formgeist Great catch. It should match Google's definition 100% - we missed that one

[formgeist]

@formgeist Great catch. It should match Google's definition 100% - we missed that one

OK, I'll add this to the list above ^

[shahzad31]

converted bullet points to checkboxes to mark them as complete as we work on them. I will pick few them in ongoing PR's for rest might do a single pr.

[formgeist]

@shahzad31 sounds good

[shahzad31]

@formgeist reduced a text size a bit from your figma file for needs improvement change

[paulb-elastic]

My understanding is that #79824 will resolve items 11, 14 and 17.

@shahzad31, you mentioned that (15) can't be done (make Page load duration and User experience metrics have the same sized heading), is that right? cc @formgeist

[formgeist]

@paulb-elastic @shahzad31 I think we have since tweaked the headings a bit, so the section titles are not needed at this time. I'd consider 15 not needed anymore.

[shahzad31]

Closing, since all points have been addressed