Introduce the concept of a "trace set" to the UI (formerly "experiment")

[ebugden]

In a couple recent PRs there have been discussions about how to clarify that actions taken on the "trace sets" (formerly experiments) in the "Opened Traces" widget do not affect the trace files:

• Allow editing trace set labels via Opened Traces widget #451 (comment)
• Add ability to remove trace sets from Trace Explorer #541 (comment)

These discussions suggest that it may be useful to introduce the concept of a "trace set" or "trace group" to the user to make it clear that they're not interacting directly with the trace files.

Other relevant context

• Consider changing the term "experiment" #194

Discussion excerpt from #541 comments

ssmagula: Is it correct that clicking this close-box merely removes the traces from the UI of the viewer?

bhufmann: What it does it removes the traces from the trace viewer UI and from the trace server back-end. But, the actual traces files are not deleted from the local file system.

ssmagula: Thanks, all for clarifying. I grasp the main issues, now.

Short term: Let's change the labeling in the UI
from "Opened Traces" to » "Trace Sets"

This will enable the UI to use "Remove Trace Set" (on hover of close-box, and on right-click) to refer to the action of getting rid of this element ("trace group" seems equally clear, and we need to formalize our nomenclature, see below). The word "delete" implies "destruction that is non-recoverable." When a user gets rid of a trace set, the user will lose the indexing and any config, but this can be redone so in my opionion, that's still a recoverable action. My gut is that confirming a recoverable action is not needed. But I'll defer to those who better know the pain of losing a giant trace set.

This discussion is a great example of why crystal clear nomenclature is vital. We (the product development team) use the word "Traces" to refer to both "a single trace data file" and "a group or set of trace data files, which have already been indexed, and may already be configured by the user"

How might we even further clarify these nouns to the user? If we are finding it hard to refer to these core nouns in a non-ambiguous way, how will users feel in the product?

Recommended:

• A single trace file should have an icon and label that communicates "a single trace data file"
• A group of "trace data files" should similarly have a label and an icon that communicate "multiple trace data files" Maybe an acronym representing the trace format is also useful info to help disambiguate this file vs. that file?
  If people agree, I can write the user story for this

mirsky-work: @ssmagula, the distinction is already communicated today. Trace sets list the containing traces:

[ebugden]

I don't agree that the list in the Opened Traces widget is sufficient because I don't think it's clear for beginners that the items in the list are trace files. One approach would be to make it more clear that the list items are trace files (maybe with an icon next to each item?).