Kibana: [APM] Consistent flyout headers

[sqren]

In https://github.com/elastic/kibana/pull/44842 the trace sample header was redesigned and simplified:

For consistency this design should be applied to the following components:

Flyout - Transaction details

• Service name (link)
• Transaction name (link)
• Timestamp (relative, absolute)
• Duration (% of trace)
• HTTP info
• Related errors

Flyout - Span details

• Span name
• Service (link)
• Transaction (link)
• Timestamp (relative, absolute span.timestamp.us)
• Duration (% of trace)
• Span type, subtype and action

Trace sample header

• Timestamp (relative, absolute)

Error occurrence header

• Timestamp (relative, absolute)
• HTTP info
• Transaction name (link)

Additional tasks (polish)

• We will show relative time and put absolute timestamp a tooltip on hover
  
• Update the colour of the separating "pipe" between each section in the summary to euiColorLightShade
• Unbold the request method in the HTTP info badge;
  
  
  
  • Current:
  
  
  • New:
  
  

For both components, it is important that all the information that is removed is still available in the "Metadata" tab.

[elasticmachine]

Pinging @elastic/apm-ui

[formgeist]

Should also include the Span detail flyout

[sqren]

@formgeist I initially added Span detail flyout to the issue but removed it again because it's too different from the others. I think it will require additional design work/thinking and should probably be a separate issue. I haven't created the issue yet because I'm not sure what we want instead of the current grid. If you have any ideas feel free to open an issue (or if you think it's very similar to the single line design in the trace sample header I'll add it here)

[formgeist]

https://github.com/elastic/kibana/issues/31895 was created to align the two flyouts, but I'll create a new one that displays in the new format for both and thereby we should achieve consistency for all 🎉

[formgeist]

On the other hand, we should just use this for the design and then I'll create implementation issues when it's done.

[sqren]

@formgeist Afaict this is pretty much ready for implementation. What do you think is missing?

[sqren]

Yes, I closed #31895. Was that premature? I didn't see any reason to keep it around since we are going away from the grid layout.

[formgeist]

@sqren Perhaps because I wasn't around for the decision to remove the information we have in those headers, but I have some concerns around removing the transaction sample ID link in the Error occurrence header. And we're missing an example and description of the Span details flyout in the above summary. Just thought it might be helpful to have proper visual examples of all of the headers and their contents?

[sqren]

I have some concerns around removing the transaction sample ID link in the Error occurrence header

Good point. I agree that should be part of the 1-line design for the error details page. I'll update the description.

we're missing an example and description of the Span details flyout in the above summary

Maybe I was not clear above. I think this is very different from the others cases (transaction flyout and error details page) and will require more work (both design-wise and implementation-wise). So it feels like it should be a separate issue. I'm also fine with leaving it as-is.

Just thought it might be helpful to have proper visual examples of all of the headers and their contents?

True, that would be nice 👍

[sqren]

I'm thinking the design for the error details page could either have the transaction name:

Or the transaction id like today:

[formgeist]

Maybe I was not clear above. I think this is very different from the others cases (transaction flyout and error details page) and will require more work (both design-wise and implementation-wise). So it feels like it should be a separate issue. I'm also fine with leaving it as-is.

I'm not sure I follow how it's different from the other flyout (or cases), can you elaborate?

I've created the following mocks of the two flyouts and the error occurrence header.

Flyout - Transaction details

• Service name (link)
• Transaction name (link)
• Timestamp
• Duration (% of trace)
• HTTP info
• Related errors

Flyout - Span details

• Span name
• Service (link)
• Transaction (link)
• Timestamp (span.timestamp.us)
• Duration (% of trace)
• Span type, subtype and action

Error occurrence header

• Timestamp (relative and absolute)
• HTTP info
• Transaction name (link)

Thoughts?

[sqren]

@formgeist I think that looks great!
For the error occurrence header you added both the relative and the absolute timestamp. Is that something we should have on all of them for consistency? We are pretty short on horizontal space, so might make sense to show the absolute timestamp as a tooltip? (We should probably do this everywhere we show relative timestamps)

[formgeist]

For the error occurrence header you added both the relative and the absolute timestamp. Is that something we should have on all of them for consistency? We are pretty short on horizontal space, so might make sense to show the absolute timestamp as a tooltip? (We should probably do this everywhere we show relative timestamps)

I think that's an excellent idea. This came up yesterday https://github.com/elastic/kibana/issues/46074 where we're not displaying the absolute timestamps in the user preferred timezone, but we do for all the charts. I'm wondering if there's a downside to displaying relative time, absolute time in a tooltip, but both shifted to the timezone the user is in and not ever displaying the _real_ timestamp recorded?

These are the updates mocks for all the headers;

Flyout - Transaction details

Flyout - Span details

Error occurrence header

[sqren]

@formgeist Really nice touch also showing the timezone 👍

[formgeist]

@dgieselaar Also added an example of the updated Trace sample header, as we're changing the time to relative and adding the timestamp in a tooltip.

[formgeist]

@dgieselaar Didn't include this task in here because it's not critical to it's implementation, but perhaps worth looking at after? https://github.com/elastic/kibana/issues/46074

[katrin-freihofner]

Are we sure we want to drop all the labels even in the details (flyouts)? I think it totally makes sense to have the new/small version on the overview but I would keep the labels in the details to make sure this information is 100% understandable.

[sqren]

@katrin-freihofner personally I think the grid ended up way too cluttered. Random bits of information scattered around. It seems much better to me to have the absolute minimum of must-have info.
In the metatab the user will still have access to all the information.

[katrin-freihofner]

@sqren thanks for pointing that out - I forgot that we have this information available in the meta tab. I'm also fine with tidying up and redesigning it - I just want to make sure we have the labels available somewhere.

[sqren]

Yeah, that's a good point. And I'm actually not 100% sure we currently have all the info in the metadata which is why I added this paragraph to the bottom of the description:

For both components, it is important that all the information that is removed is still available in the "Metadata" tab.

[formgeist]

I think we have the data as the user.agent information has been added to the Metadata tab as part of https://github.com/elastic/kibana/pull/44842. Although the tab hasn't been re-organized, so finding some specific value might require the user to in-browser search for it.

[dgieselaar]

The colors for the badges look slightly different in its current state than in the design. The design seems to have lighter shades. Which ones should I stick to?

[formgeist]

I think https://github.com/elastic/kibana/issues/45406 is already going to update the status colours, so ignore the colours in my designs for now.