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

Clarify that re-labeling traces doesn't change trace file names #475

Open
ebugden opened this issue Sep 8, 2021 · 3 comments
Open

Clarify that re-labeling traces doesn't change trace file names #475

ebugden opened this issue Sep 8, 2021 · 3 comments

Comments

@ebugden
Copy link
Contributor

ebugden commented Sep 8, 2021

PR #451 lets users define a useful label for trace sets instead of being restricted to the default (ex. "Before applying patch A" instead of "trace-12sdai42b-202109081611"). However, at the moment it is isn't clear that this changing this label has no impact on the trace file names. This is confusing for users.

Prerequisite for merging PR #451. Discussed in PR comment.

Challenge

The challenge is that, since trace set generation is currently behind the scenes (i.e. it happens automatically when you open a folder with CTF traces), users don't know what a "trace set" is. It's easy for users to assume they're working directly with the filesystem. This is further reinforced by the default trace set name being name of the folder that contains the traces.

To clarify that changing the trace set label doesn't make changes to the filesystem, we need to first introduce the concept of a "trace set" and imply it's separate from the filesystem.

Possible solution

  • New default trace set name "Trace set - <folder name>": Ex. Instead of "my-trace-folder" the default name would be "Trace set - my-trace-folder". The folder name is a good element to include in a default name and then adding "Trace set - " suggests you aren't interacting directly with the filesystem.

Original discussion (from PR comment):

bhufmann: Secondly, we need to be clear that the renaming of experiment name doesn't change any file resources (i.e. the trace files)., ...

ebugden: I agree that it's not clear that changing the trace set label doesn't affect the filesystem and that this is confusing. But I don't think resolving this is within the scope of this PR. At the moment, trace set generation is all implicit and behind the scenes so the first step would be to to introduce the concept of "trace sets" that have no connection to the filesystem. If necessary, the changes proposed below could be made before merging this PR.

In the short term (new issues?):

  • Better default trace set name: The difference between the filesystem and the trace set would be more clear if the trace set label wasn't exactly the folder name (when automatically generating a trace set when a folder containing CTF traces), but this can be addressed in a different issue/PR. For example: "Trace Set 0 - Generated from trace-folder-name" instead of just "trace-folder-name".

bhufmann: This could be the description and shown as tooltip. Using "Trace Set 0", "Trace Set 1" is not necessary better than using the directory name. The directory name right now works well, for example, when opening a trace set from the LTTng session root directory and the trace set name becomes the session name. Another use case is, when the root directory is a test case name and opening the trace set name become the unit test name. Changing the name to "Trace Set 0" as default, would break these use cases.

I'm wondering if a dialog box should open with text box after selecting "Open with Trace Viewer". It opens with the default name. If the use wants to keep it, then he only needs to press ok. Otherwise the use can type a new name and then press enter.

@ebugden ebugden added this to the MVP milestone Sep 8, 2021
@ebugden
Copy link
Contributor Author

ebugden commented Sep 8, 2021

bhufmann: This could be the description and shown as tooltip. Using "Trace Set 0", "Trace Set 1" is not necessary better than using the directory name. The directory name right now works well, for example, when opening a trace set from the LTTng session root directory and the trace set name becomes the session name. Another use case is, when the root directory is a test case name and opening the trace set name become the unit test name. Changing the name to "Trace Set 0" as default, would break these use cases.

I'm suggesting adding "Trace Set - " or "Trace Set:" as a prefix to the folder name. Kind of how the trace analysis tabs have a "Trace:" prefix, but editable. Examples of adjusted names (tracevizlab example traces):

  • Trace Set: 103-compare-package-managers
  • Trace Set: 201-lttng-userspace-tracing

Pros

  • Keeps many strengths of using the folder name as the default
  • Clarifies that users aren't interacting directly with the filesystem
  • Can be edited out of the trace set name

The problem is that right now users have no way of learning that they're looking at a trace set and not the filesystem. Because trace sets are generated automatically right now, users have no reason to believe they're not interacting directly with the filesystem and there's nothing in the UI to suggest otherwise. (Granted this will be less of an issue when users are explicitly defining trace sets themselves, but at the moment changing the default trace set name could be a quick way to introduce the concept of a "trace set".)

Cons

  • Repetitive label that takes up room

@mirsky-work
Copy link
Contributor

  • Repetitive label that takes up room

How about changing the widget name from "Opened Traces" to "Opened Trace Sets" and perhaps elaborating more in the tooltip?

@ebugden
Copy link
Contributor Author

ebugden commented Sep 10, 2021

mirsky-work: How about changing the widget name from "Opened Traces" to "Opened Trace Sets" ...

Renaming the widget communicates more clearly that "the widget shows trace sets", but it doesn't communicate that "a trace set is not a folder". Without challenging the user's likely assumption that they're interacting directly with folders, changing the widget name risks reinforcing the idea that a trace set refers directly to the filesystem.

... and perhaps elaborating more in the tooltip?

Tooltips (especially tooltips that only appear after a long hover) can't be used to challenge a user's assumption since the user won't check the tooltip if they think they understand what they're looking at already.

@ssmagula Do you have any thoughts? We want to clarify that re-labelling a trace (or a trace set) doesn't change the file name.

@ebugden ebugden removed this from the MVP milestone Oct 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants