[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:
dependency
relation
is related to MGNLUI-2964 Deletion confirmation message should ... Closed
is related to MGNLUI-3002 Unselect items when you close a node ... Closed
is related to MGNLUI-2806 Show the total number of selected ite... Closed
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).
What we'd like to display in any case would be not the total number of items (not a big deal), rather the amount of visible items. I will investigate and see if that is feasible for 5.3 with a reasonable effort, else we will drop it for now
We will certainly display the amount of selected items in the left bottom corner of the status bar according to the following rules

  • 0 items selected = "No item selected"
  • 1 item selected = "/path/to/selected"
  • 2 or more items selected = "n items selected"
    This would also solve the issue with multiple items selected where in the status bar one can only see the path to the first of the selected items, thus causing confusion.
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.

  • This means that all item counts are related to what the view shows, not to what the data set contains. The latter would be shown separately on a info or details pane showing statistics on the actual resource (aka the repository workspace) - we currently don't offer that.
  • This also means that item counts work best if adapted to the context they show in: the exact text they show should be explicit and formulated in a way that makes sense for the view. E.g if the view shows a filtered set, we say "5 items found"; it it shows a flat list of all assets, it could read "503 assets"; in a tree, it would read "45 items visible".

So where do I see the value of a total number of items count in our view?

  • in a filtered view or list of search results, this info is very and most useful as it counts the number of results.
  • in our list or thumbs view, the total number of items is interesting to some degree, in particular for cases, where we don't show folders, but only actual items - which we do in our list views.
  • in a tree view, it typically denotes the number of visible items. The value of this information in a tree is arguable. The information as such has little value. It does get some value, however, if we would offer a "select all" function (through a checkbox in the header).

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:

  • We show the total number of items count right away, if we're able to show all items in the view.
  • In case we detect we have to offer lazy loading, we would defer computing that count until the view and all its currently showing items are fully rendered. We would show a text like "Counting #visible items..." while a background thread determines that number.

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:

  • showing the total number of items in a filtered view or list of search results would be essential as it offers an integral information of any search.
  • in all other cases, even list/thumbs views, the value of this count is arguable.
  • I thus recommend we do not invest too much time into this now. A good, not too expensive solution will probably have to be researched somewhat.
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.

Generated at Mon Feb 12 09:00:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.