Selecting Experiments redefining

[maxagin]

This is an attempt to improve the interaction that is currently in place, also in tight relation with other ongoing work. The main motivation is to provide the user ability (to interact) to work with the row content (for example modifying the cell's info directly in the experiments table) without seeing the unnecessary styles. Any click on the row in the current case will trigger the BG style to appear, this is what we want to resolve.

Full information can be found in Figma.

TODO

• Select 3rd from the top + Shift and 1st from the top, nothing in between selected. Also by removing one of the two selected both will take unselected status.
• In the case of multiple selections, should not we have Unselect All option in the menu?

[maxagin]

Hey folks! Please share with me your comments. I think this is something that will help us to have a bit better user interaction experience. WDYT?

[shcheklein]

@wolmir I think it's related to what you do now (multi-row select). What's your take on this?

@maxagin is it a draft still? We need to make it a bit more realistic - see the table with checkpoints, workspace, etc.

[maxagin]

@wolmir what will be happening with expS, when the new branch has been created? Please help me to understand. Thanks

[wolmir]

While I was trying to create a new branch in order to answer Max the command failed because the branch name was already taken.
But the extension didn't report it.
Maybe it's a bug?

[wolmir]

What happened here was that DVC created a new branch from that experiment, but nothing happened visually, except for that Toast message.
It makes sense to me, because you can only be working on a single branch at a time anyways.

Is there a need to see them in the table as well?

[wolmir]

@maxagin I liked the checkbox design!

What should happen if I select an experiment with child checkpoints?
Only the parent should be selected, or should all its checkpoints be selected as well?

[wolmir]

And also:

We already have an experiment toggling feature.
Should this row selection be interpreted as the same thing?
What I mean is: if I select a table row via the checkbox should the corresponding experiment be toggled as well?

[maxagin]

What should happen if I select an experiment with child checkpoints?
Only the parent should be selected, or should all its checkpoints be selected as well?

1. How does this work now @wolmir ?
2. For now we need actions only for the Experiment (I think) so yes - the only parent

[maxagin]

We already have an experiment toggling feature.
Should this row selection be interpreted as the same thing?
What I mean is: if I select a table row via the checkbox should the corresponding experiment be toggled as well?

In terms of the logic, it is the same. However please review the specs and let me know if there is something that functioning differently from what we currently have.

[maxagin]

All the above questions are resolved. Thank you @wolmir 👍

[maxagin]

Context menu behaviour. @wolmir just for information. (! however, in VSCode it seems like always on the right side :)

Screen.Recording.2022-06-20.at.2.23.44.PM.mov

[wolmir]

@maxagin Can you add a spec on Figma for an experiment with checkpoints, please?
I would like to know how it should look with only the parent checkbox at the top.

[maxagin]

@wolmir yeah. working on it right now

[maxagin]

Here we are @wolmir . Take a look and let me know if I have missed something or not.

[wolmir]

Thank you!

[shcheklein]

@maxagin It seems that it should be possible to star a child (checkpoint).

There are also actions (drop down menu) that could be applied to those also. How will they interact with checkboxes?

[maxagin]

It seems that it should be possible to star a child (checkpoint).

Good. Will create an example

@shcheklein There are also actions (drop down menu) that could be applied to those also. How will they interact with checkboxes?

I and @wolmir had met and I understood that there are no actions for the checkpoint currently. Let's please clarify this.

[wolmir]

@shcheklein At the moment the only option we can apply to multiple rows is to remove them. And this remove option is restricted to the checkpoint tips only.

Should we add the checkbox to the checkpoints anyway?

[maxagin]

@wolmir @shcheklein

Should we add the checkbox to the checkpoints anyway?

We can add it when we have a case. The point of this question was to clarify that currently, we do not have actions for the checkpoints.

[shcheklein]

Should we add the checkbox to the checkpoints anyway?

No, no need for this.

[maxagin]

In terms of selecting the rows with a checkbox, all the following platforms are works the same: airtable, wandb and studio. Exactly as proposed here.

I completely agree with Matt that we better use a native set of tools where it is possible, but to my opinion, this and other similar cases are different as they have multiple actions at the element (the row) and user experience, in this case, dictates a different approach I think.

Screen.Recording.2022-06-24.at.1.30.45.AM.mov

Screen.Recording.2022-06-24.at.1.31.56.AM.mov

Screen.Recording.2022-06-24.at.1.34.27.AM.mov

[mattseddon]

Here we have a table. Which has multiple levels of hierarchy - rows, columns, cells + some rows are collapsible + we have already a few states per row - star, toggle on / off plots. This seems to me a scenario that goes beyond the regular one - atomic items. Users need to interact with all these levels, independently.

In our example, the atomic record is the row. Clicking on the row means that you can interact with that row through the context menu. This should not break/interfere with the other ways that the user can interact with the row. I don't see the benefit of doing this through add an additional checkbox. It seems like the main reason for making this change is so we can drop the inline copy button and move to "the user will select and copy the value", this is fine in principle but we do not always have the space to show the full value. Meaning users can/will lose precision when extracting values from the table.

In terms of selecting the rows with a checkbox, all the following platforms are works the same: airtable, wandb and studio. Exactly as proposed here.

I disagree that the checkbox in Studio behaves the same way as what is proposed here. The checkbox in Studio is used for:

1. Selecting rows to display (loosely equivalent to star behaviour)

2. Selecting rows to display in trends (loosely equivalent to select for plots behaviour)

3. Selecting rows to compare directly (we do not have this behaviour)

4. Selecting a row to run a new experiment (available from context menu)

They are not used to select rows to interact with through a context menu. There is in fact no context menu available in Studio:

We can also analyze how other tables do this - Airtable, Excel, Studio, etc. Or maybe VS Code itself has something a bit more relevant for this?

The Jupyter extension has a data viewer. Which looks like it uses something similar to the Webview UI toolkit's data-grid component. I've had a quick play with this and it seems very basic. There are cell-level interactions but not much else:

My questions are

1. Why are we not aligning with either the rest of VS Code or Studio?
2. What is the value of removing the inline copy button?
3. Can we reduce the number of elements/concepts needed to interact with experiments?

[maxagin]

We want to be able to work with row:

1. modifying the cell's info directly
2. star rows
3. copy info
4. ...

We want to do this without contrast hover styles and unnecessary on-click styles.

Regarding select on click.
Where will the user need to click to select the row?
On the cell with information, which can have some actions also?

...

Would like to refer to this comment: #1924 (comment)

@mattseddon the main motivation is to provide the user ability (to interact) to work with the row content (for example modifying the cell's info directly in the experiments table) without seeing the unnecessary styles. Any click on the row in the current case will trigger the BG style to appear, this is what we want to resolve.

#1924 (comment)

[shcheklein]

So, the key here "In our example, the atomic record is the row. " vs "cell is the atomic record". To be more constructive we need a better list of workflows we expect users to do with cells and if those can be replaced with anything

• editing them in the workspace
• show tooltip on hover (now) + on click eventually?
• copy - should be one click or may be two clicks or select with a click + Ctrl+C (cell or icon)

anything else?

My intuition was:

• that any cell-level interactions (even the existing button) are enough to start considering checkboxes, because otherwise users will be missing clicks and copy cells instead of selecting them, etc
• we'll have more things to do with cell values later where click is required (click to show it for example in a tool tip that doesn't disappear, some other things?)

---

What is the value of removing the inline copy button?

It's somewhat related, but we can actually keep (and probably should) the button and reconsider this later. No matter we do checkboxes or not.

Why are we not aligning with either the rest of VS Code or Studio?

Discrepancy between using circles and checkboxes for plots bother me as well though.

My take - both of them are simpler to what we are trying to achieve here. (comes down to the level of granularity again that we need to agree on)

Can we reduce the number of elements/concepts needed to interact with experiments?

Any specific suggestions in my mind? Do you mean, btw, "actions" (like drop the whole concept of stars, or copy-paste cell, or don't allow multi-select at all, etc?)

[mattseddon]

We want to be able to work with row:

1. modifying the cell's info directly

Experiments are immutable once they are finished the only row that we would be able to inline edit is the workspace record. As the workspace record is the only record that could have inline edit and it will probably never have any multi-select options we should consider disabling "selection" of this row altogether.

2. star rows

In order to star multiple rows I would have to click on the checkboxes (right next to the star), select the ones that I want and then invoke the context menu to star the records.... why not just click on the star icons?

3. copy info

The existing button works well for this. Mainly because we do not display all of the decimal places for numeric values. See below for an example of where we would lose precision by selecting and copying the value.

Regarding select on click. Where will the user need to click to select the row? On the cell with information, which can have some actions also?

They should be able to click anywhere on the row (that isn't a copy button). What are the proposed cell-level actions outside of copy that make sense? Having the tooltip activate only through a hover makes sense to me.

So, the key here "In our example, the atomic record is the row. " vs "cell is the atomic record". To be more constructive we need a better list of workflows we expect users to do with cells and if those can be replaced with anything

editing them in the workspace
show tooltip on hover (now) + on click eventually?
copy - should be one click or may be two clicks or select with a click + Ctrl+C (cell or icon)
anything else?

I don't see anything outside of these options. I would not add the show tooltip on click option as this is also not available anywhere else in VS Code.

Any specific suggestions in my mind? Do you mean, btw, "actions" (like drop the whole concept of stars, or copy-paste cell, or don't allow multi-select at all, etc?)

Drop stars, drop checkboxes, focus around the dot for selection. Leave multi-select how it is implemented now. Give the option to collapse to selected but have it based on dots. This would replace the need for stars altogether. This aligns with the behavior in Studio of selecting up to 7 commits to display together or in trends (plots). Being able to "favourite" more than 7 experiments seems unnecessary and adds clutter to the table. This also gets over the issue of not being able to display stars in the tree.

[shcheklein]

that isn't a copy button.

That alone can annoy, wdyt?

Having the tooltip activate only through a hover makes sense to me.

More or less, but potentially - click can activate (and pin) tooltips. That's what Studio does because it has more information and we will have too.

I would not add the show tooltip on click option as this is also not available anywhere else in VS Code.

It's available to some extent for the notifications. Also, we can't completely limit ourselves to the behavior available in VS Code. E.g. recently we were expanding tooltips to add links to them - what would be a solution there if tooltips in VS Code disappear immediately.

For files we'll want to show more information in those tooltips, we want people to allow to copy all of it or parts of it.

Drop stars ... This aligns with the behavior in Studio

Studio doesn't have stars semantics and anything close to that yet.

To be honest, I don't quite understand how "up to 7 commits" and "basing these on dots" can solve the problem that stars are solving. Dots are used not to "favorite" something but as a replacement for an "eye" icon - to show / hide on the plots dashboard. Stars have a completely different semantics, right? I can star something (and definitely 7+ experiments), but I don't see all of them on the plots.

This also gets over the issue of not being able to display stars in the tree.

Most likely we'll have to write our custom tree if needed to accommodate our needs. Again, my feeling is that we go into extremes sometimes (both ends) - let's do a complete SaaS in VS Code and let's not use anything at all that doesn't exist in VS Code.

[maxagin]

both ends

I just tried to propose a more clear solution for the user, also taking into consideration the platform specifics :) Thanks

[wolmir]

@shcheklein @mattseddon @maxagin

Should I hold the stars PR for now too? Until we can discuss this further, possibly in the planning today?

[shcheklein]

I think we agreed on doing stars separately a while ago. I see that they are almost ready. I would go forward and merge them. For now I don't see any better suggestion that could replace them and it's only somewhat related to the things discussed here.

[wolmir]

@maxagin @mattseddon @shcheklein @rogermparent
Checkboxes demo:

Screen.Recording.2022-06-30.at.16.13.21.mov

[shcheklein]

thanks @wolmir - that looks cool to me

[wolmir]

With shift+click batch selection:

Screen.Recording.2022-06-30.at.17.48.50.mov

[maxagin]

Hey @wolmir. Here are a few comments I have collected during my latest review of the exps table:

• Select and apply star, appears with a small delay.
• Select 3rd from the top + Shift and 1st from the top, nothing in between selected. Also by removing one of the two selected both will take unselected status.
• In the case of multiple selections, should not we have Unselect All option in the menu?
• If a column has resided, the hint is showing not in the right place.

[wolmir]

Thanks @maxagin I'm implementing a new demo for today's planning meeting with this UX in mind

[wolmir]

@mattseddon @maxagin @shcheklein

What's the correct behavior for bulk selection?

1. Select all checkpoints in the batch
2. Don't select any checkpoints in the batch, unless they all have the same parent.
3. Select only the checkpoints that are visible (expanded) in the table

[maxagin]

@wolmir for now, it is: check the checkbox -> Shift (Mac) -> check another checkbox - will select all in between. Or I am missing something? Are you working on the bulk selection?

[wolmir]

It's because of this particular comment from Matt: #1964 (comment)

I already fixed the bulk selection bugs, but I want to implement the correct behavior for that case.

[maxagin]

Good! Have I answered your question here #1924 (comment) Thank you @wolmir

[wolmir]

I don't see how selecting every checkpoint in between would be useful, though. We can only star multiple selections for now

[maxagin]

@wolmir

1. Star / unstar
2. Delete?
3. Unselect selected

Scenario: I want to star a few expS -> I have selected multiple rows -> I change my mind and need an option to unselect all.

Right?

[wolmir]

@maxagin Sorry, I was talking about the multiple selection of rows

See this demo here: #1986 (comment)

As you can see, every checkpoint is selected in the range specified by the user.

But the only option the user has at that point is to star/unstar them.
And if you star all the checkpoints of a tip, you might as well just star the tip.

So it seems more useful to select only the tips, because then the remove option is available as well.

[maxagin]

@wolmir Currently (on prod) it is working more clearly I think - if the parent is selected, the children are not.

Screen.Recording.2022-07-05.at.2.55.34.PM.mov

[maxagin]

@wolmir But the only option the user has at that point is to star/unstar them.

And unselect all

[wolmir]

Got it, thanks!

[mattseddon]

Is the description in this ticket stale?

[wolmir]

@iterative/vs-code
I edited the description by moving items to #1562 and removing the TODOs we agreed not to do.

Given the description that remained, I believe it's safe to consider this done, because the objective was accomplished (moving from line-clicks to checkboxes).

The rest are improvements/fixes (created in #2028 )