[Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

Hi Ajay/Anish,

On 18 Jul 2012, at 11:57, Anish Mangal <anish at activitycentral.com> wrote:

> I would like to propose the long-discussed-finally-implemented ;-)
> journal entry batch operation and multi selection feature for
> inclusion in sugar-0.98. All the necessary and relevant details should
> be present in the associated feature page:
> 
> http://wiki.sugarlabs.org/go/Features/Multi_selection_screenshots
> 
> AFAIK, This feature was initially brought up in discussions in EDUJam
> in 2011 and an initial implementation was made by Martin Abente. The
> current implementation, done by Ajay, has been derived from that
> keeping the UI experience largely the same while significantly
> speeding up operations like select/deselect.
> 
> Should you have any design related questions about this, feel free to
> reply to this thread.

At last Tuesday's design meeting we didn't make it back around to this agenda item, so here's my feedback/notes after testing the DX3 image with the new rpms:

- FIXED. Once in multi-select mode, the favourite stars no longer visibly updates, though changes update later once multi-select mode is exited. 

- FIXED. Auto deselection after batch operation.

- UNRESOLVED BUG. Tick-box slow/erratic behaviour in dx3ng143 with latest rpm fixes image on XO1, still needs mouse movement to redraw. This is also an issue when using the "Select all" toobar button, as the list view tick-boxes do not update until after the "Select all. You have selected N entries. (Ok)" dialogue is clicked.

- NEW BUG. Renaming an entry while in multi-select mode does not display the name change, only updates the name displayed after multi-select mode is exited.

- NEW BUG. If you rename while in multi-select and then try to copy, the entry can't be copied and raises an error "Entries without a filename cannot be copied."

- UNRESOLVED DESIGN QUESTION. Should filters continue to work once in multi-select mode e.g: Filter for star favourite items in Journal; multi select all stared items; un-favourite some entries while in multi-select mode. Should they be removed from the multi-select view, or stay? Currently they stay, but this causes a visual 'jump' when exiting multi-select mode as the initial filter is re-applied to the view. Same issue if filtering the Journal by title, and you rename some entries while in multi-select mode.

- FEEDBACK. In multi-select mode the toolbar button string 'Select none' would be better renamed as 'Deselect all'.

- TESTING. A loaded Journal with ~100 items, and a USB stick with 900+ items was tested. Selecting individual items one by one is reasonable (ignoring the above unresolved redraw/event bug). Batch selecting, deselecting, erasing operations are pretty quick (batch feedback progress is helpful especially for the 900+ item case). Batch copying is the slowest operation (as to be expected), feedback progress here is essential for even a few items.

- FEEDBACK. In the primary multi-select toolbar, add a separator and text widget to show how many items are selected, and how many are in the current multi-select view e.g. "Selected 3 of 123" so the current multi-select state is always visible to the user. This same widget can be used for progress feedback during batch operations e.g. "Copying 9 of 22: <title>", "Erasing 3 of 15: <title>", "Deselecting 5 of 17". This removes the need for all progress alerts during batch operations, see below.

- FEEDBACK. {confirmation_before, progress, confirmation_after}
    ... select_none {N, N, N}
    ... select_all {N, N, N}
    ... erase {Y, N, N}
    ... copying {Y, N, N} 

- FEEDBACK. We should allow a user to abort a batch operation when an error occurs. Use cases, encountering many errors during a batch operation when a volume runs out of space, or becomes unavailable. One solution on other platforms is a check box for in the error dialogues "[√] Apply to all" (to ignore future errors of this type during this batch process), and/or an additional button "Stop". I'd suggest our batch operation errors dialogues add a "Stop" button to allow aborting the batch process, and that the current "Ok" button is renamed "Continue" to be more clear.

- UNRESOLVED DESIGN QUESTION. Do we want to allow a user to abort a batch operation while it is in progress? Use case, copying/erasing many items over a slow network, or usb device, and deciding if it is not worth the wait. I think, for now, we can avoid this extra UI work as the batch features do provide the option to cancel before they begin. We should revisit this if it turns out to be a frustration for users. The UI design would likely be to add the cancel icon (X) to the primary toolbar while a batch operation is in progress.

Regards,
--Gary