Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Towards reports and timeless views. #1091

Open
MatthewKhouzam opened this issue Jul 11, 2024 · 3 comments
Open

Towards reports and timeless views. #1091

MatthewKhouzam opened this issue Jul 11, 2024 · 3 comments
Labels
help wanted Extra attention is needed UX User experience improvement

Comments

@MatthewKhouzam
Copy link
Contributor

Hi all,

We are looking as to how to display views where the X axis is another unit than time. Examples can be function density views and flame graphs.

In trace compass eclipse, they go everywhere and are thus... less guided in the UI/UX.

In the Theia extension, we have the opportunity to make something nicer. This is the first thing people tend to look at in investigations, we should consider this to be the first impression after the trace is open.

I do not want to bias this with my opinions too much, so I am putting this placeholder up in case anyone wants to have their voice heard in this specific field.

@MatthewKhouzam MatthewKhouzam added help wanted Extra attention is needed UX User experience improvement labels Jul 11, 2024
@compudj
Copy link

compudj commented Jul 17, 2024

I'll use this opportunity to provide some feedback, some of which is based on our past experiments with lttng-scope.

Here is a rather disorganized desiderata list:

  • When a non-time-x-axis chart is shown, it typically covers an area of the trace (or all the trace). It should be very clear which time area of the trace is covered by the chart, IOW for which time range/ranges is trace data being aggregated ?
  • Being able to interact with elements on the chart would be great, e.g. quickly finding max/min values and being able to select them, see details, open more detailed views about the surrounding of those extremes,
  • Make it clear what each axis is representing, with clear units.
  • Show readable axis units, e.g. use k, M, G rather than large numbers or exponential (nnEmm) values.
  • When a number shown is large (many characters), it typically contains very few significant numbers. How to best present the significant numbers only and cut away the non-significant ones in a way that is clear to the end user should be carefully thought through.
  • Allow users to choose the math function to apply on each axis: linear, log, others. This should be clearly shown on the axes labels.
  • Allow auto-selection of math function to apply on an axis based on the content shown: e.g. we could auto-detect if logN is a good way to show an axis based on the content. There should always be a way to override this if we guess wrong.
  • There should be a legend somewhere that shows the meaning of line color, line types, icons, markers.
  • Grids may be interesting to easily show alignment of axis steps with data, but beware that it does not overburden the view (e.g. grid colors should be really pale). This is probably something that could be optional. Make good default choices for it.
  • Make sure the time-aligned views cannot be mistaken to be on the same "time alignment" as non-time-x-axis views. There should be some hint to the end user that a group of time-aligned views are indeed showing time as x axis. A non-time-x-axis view should not be visually integrated in a way that would let users think they are time-aligned. This probably has more impact on groups of views that have time as an x-axis. It is important though to clearly show this in order to allow users to distinguish between time-x-axis and non-time-x-axis views.
  • Users will likely want to compare different instances of those charts one against the other to see difference in distributions, e.g. between different traces, between different point in time within a trace, between different processes, between different machines, and so on. It would be important to allow users to collect those charts into a "report" and allow them to "tag" each chart with a specific name so they can quickly make sense of how they relate to one another. Whether the charts in those reports need to be interactive is not a given: perhaps just a snapshot would be fine.

@MatthewKhouzam
Copy link
Contributor Author

Thank you very much! This is the kind of feedback we're looking for.

I was thinking that we may want "gutters" or some kind of marker to differentiate the views, but also, maybe the non-time views should be non-interlaceable with the time views.

i.e.

Resource view
flame graph
Threads view
Density
IRQ latency

would be impossible.

Some items I though of that could be atemporal:

  • Cycles
  • Durations
  • Memory Usage
  • Number of Occurrences
  • user defined (I don't want to stop someone from using this to put temperature or power...)

This is not a process that we can do overnight. We won't get it right, but we want it good enough to start to make the user experience pleasant.

@ebugden
Copy link
Contributor

ebugden commented Jul 17, 2024

@MatthewKhouzam Would there be interest in mockups / graph sketches of how to display titles/labels/units? As in, is there time for doing more core changes to chart components/layout?


+1 Clarify difference between time-based and not time-based charts e.g. via no interlacability #650
+1 Clarify explanations of chart contents (descriptive title, units, axis labels) #647

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed UX User experience improvement
Projects
None yet
Development

No branches or pull requests

3 participants