Select one ... (check one with "x")
[ ] bug
[X ] feature request
We need a pattern for selecting a single row in datagrid and taking action on it especially when patch operations are not available. Think of a datagrid containing user accounts and a single action (Edit). How do you select one user and edit their account.
Currently, we don't have a pattern for this.
N/A
N/A
Angular version: 2.0.X
N/A
Clarity version:
Future
Browser:
all
@yenmade could you provide some UX input here on the pattern to be used for single row selection/action in a datagrid?
I will be looking at this alongside other datagrid items.
Attached are designs that include patterns for single/batch actions in a datagrid. We'd love to hear any feedback on this before we build it in Clarity. Thanks in advance!
Is the three dots button intended to replace the right click of an item ?
Also it will be of great use to have support for CTRL + click, SHIFT + click, CTRL/SHIFT + KEY UP/DOWN for multiple selection.
@zivanov123 thanks for your feedback. Some comments below:
This does not seem as single object selection. It would be better if we have selection not based on checkboxes, but on row click.
Having selection on row click wouldn't be a solution in the case you have click targets within that row (imagine you have input fields, flat buttons, or any other click targets). When a user clicks are they clicking on the row or that other click target?
Is the three dots button intended to replace the right click of an item ?
It is intended to provide the ability to add actions to a row.
Also it will be of great use to have support for CTRL + click, SHIFT + click, CTRL/SHIFT + KEY UP/DOWN for multiple selection.
Keyboard support is pretty important and a good suggestion. CC @yenmade and @youdz to make sure they can take a look and see what needs to be done for keyboard support.
@jaffoneh
Having selection on row click wouldn't be a solution in the case you have click targets within that row (imagine you have input fields, flat buttons, or any other click targets). When a user clicks are they clicking on the row or that other click target?
In such cases these clickable targets will be with higher priority. Does not seem as an issue which has no solution.
Thanks!
@zivanov123 the challenge is not only technical it is also a user experience challenge that we need to be careful about. We don't want to have click targets with different priorities on the same area for the user to figure out what to click, where, and when to get what they need. Hope that makes sense.
IMO what needs to be done is to have a story for master/details, allow for keyboard navigation, and allow multiple selection for mass actions. A good model is the Gmail messages list:
a) When a message is clicked it gets the focus, gets colored differently (yellow in my case) and its details get shown in the preview pane
b) Keyboard navigation (up/down arrow) allows to move the focus between items
c) User can select one or more items using the check boxes in front of messages. When one or more items are selected any item focus is lost, hence details pane becomes empty (with a link to clear the selection).
d) When an item is clicked the focus is regained by that item, and the selection of items (if any) is cleared.
@ductor we're actually considering summary/detail behavior as part of our overall design patterns so the above is very useful. Thanks for sharing! cc @yenmade
This is very concerning from an adoption standpoint. Single selection for datagrids is pretty standard behavior and is handled quite uniformly across libraries. It doesn't appear VMware is eating their own dogfood given vSphere's HTML5 fling has plenty of datagrids with single selection (see attached). I'll back up what zivanov said and say selection should be done on click, and we should be able to set an initial selected row programatically. I appreciate your initial design though, hope you revise it based on the feedback.

So there has been some discussion about this, and we're looking into maybe providing an option for the "full-row click" behavior many of you describe. Here is a plunker of a quick version of it, feasible right now with the current Clarity: https://plnkr.co/edit/OuZ3w6AecL4VvSXRd9sd?p=preview
It still has a few quirks, like the mouse not becoming a pointer, but that's the basic idea.
We're looking into potentially making this a simple one-line option, but it would rely on an informal contract that _you_ would never put any additional click targets (like buttons or links) inside the rows themselves. We have no way of detecting this, so if you did end up putting click targets, you'd probably end up with a broken behavior. But offering both options (full-row click with no sub-targets, and the solution proposed in the previous comments) is something we are considering.
@youdz I don't understand why having click targets in the selectable row would cause broken behavior? In some cases, you would want to provide a link to take the user to a different route on click, but still allow row selection if the user clicked on some other part of the row. It would be up to the developer to ensure they called e.stopPropagation() in their click handler if they didn't want the row to be selected as well.
There are most definitely usability issues with click targets in selectable rows (especially on mobile/touch devices), but I don't see a technical reason why it isn't possible.

where clicking on the VM's name will take the user to the summary page and clicking elsewhere on the row will select it and show the slave view below the grid.
@elesueur: Having a link inside a clickable row is basically putting a button in a button. Not only is this not W3C-compliant, but it's also generally bad experience for the user. A one-pixel misclick and you end up performing an action you didn't want.
Regarding e.stopPropagation(), it's generally something you really want to avoid. Doing so will break other components that rely on the bubbling up of the event. For instance, a dropdown listening to _all_ clicks on the page to close down. If the click happens to be on a datagrid element where you stop propagation, the dropdown doesn't close.
So overall, sure, there is always a technical way of doing it, but not only we won't support it, we also really advise against doing it.
Hi there 馃憢, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.
Most helpful comment
Attached are designs that include patterns for single/batch actions in a datagrid. We'd love to hear any feedback on this before we build it in Clarity. Thanks in advance!
datagrid_actions.pdf
datagrid_SingleBatch_actions.mov.zip