[MGNLUI-2789] Show the number of selected items to prevent inadvertent deletion and data loss Created: 03/Apr/14 Updated: 30/Nov/15 Resolved: 04/Jun/14 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | tree/list |
| Affects Version/s: | None |
| Fix Version/s: | 5.3 |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Joerg von Frantzius | Assignee: | Federico Grilli |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | support, usability, ux | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Description |
|
When the tree is larger than the current view, then it can happen that the user inadvertently selects multiple items: if there already was a selection outside of the current view, and the user selects another item in the current view. (This is possible because multiple selection in Magnolia is with checkboxes, while e.g. in Windows Explorer it is done with Ctrl+Click) The number of currently selected items should always be visible, e.g. at the bottom, or even more information on the multiple selection should be shown (selected names). Currently the bottom only shows information about a single selection. On multiple selection, it shows only the name of the first selected item. When deletion is chosen on a multiple selection, the confirmation dialog message hints at multiple objects being deleted only by an additional plural "s". It should state the number of items going to be deleted, and maybe also paths. |
| Comments |
| Comment by Andreas Weder [ 16/Apr/14 ] |
|
Hi Joerg, thanks for your feedback. You're definitely right on this. In fact, already the original concept for apps calls for the total number of items and the number of currently selected items to be visible at all times in the bottom right corner, at all times. It's the spot that's been reserved for this ever since. You can find this on almost every mockup and visual design. We actually did show this piece of information at some time during 5.0 development, but it turned out to be very expensive to compute these numbers, in particular when the queries got more complex. This may have changed in the mean time. We could also choose a different approach in computing the numbers. Or we could delay computing these numbers until the tree is visible and accessible. I'll add this to our things to research. I also agree that we should name the amount of numbers to be deleted in the confirmation dialog. Again, this has been in at some time, but has fallen out again. I'll check if we can deliver this in a upcoming release as well. |
| Comment by Federico Grilli [ 03/Jun/14 ] |
|
After a brief discussion with Andreas, it was decided that the total number of items is less important to display than the selected items (which are what is actually needed to solve the issue in question).
|
| Comment by Andreas Weder [ 04/Jun/14 ] |
|
Here's some comments on the value of showing the total number of items. In general, and the way this is designed in our case, such information is related to the view and not the underlying data set.
So where do I see the value of a total number of items count in our view?
Performance-wise, let me say that it would be a no-go if the view get's significantly less responsive due to us obtaining this info - then I'd rather not show it. I would reckon that in all our views, obtaining the total item count is similarly expensive: we use a query with various filters in each case. That query returns a number of items, and that number is what we have to show. What I would expect to be a killer is lazy loading, which we have to offer to be able to deal with larger data sets. Another problem I see is that we can't rely on any JCR operation to get this data, as we do offer JCR-agnostic content apps now. One nice pattern I see and which is typically used to deal with costly operations that deliver 2nd-class information is this:
I guess even in this case, ensuring that computing this number does not interfer with whatever the user does with the list, and with other users using the same instance, is non-trivial. To summarize my thoughts on showing the total number of items in a view:
|
| Comment by Federico Grilli [ 04/Jun/14 ] |
|
Confirmation dialog message will be tackled in a different issue. |
| Comment by Andreas Weder [ 13/Jun/14 ] |
|
Linking to a follow-up issue requesting that all selected child items of a parent node being closed get deselected. |