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

[Gary Martin]

Hi Ajay,

On 4 Aug 2012, at 10:21, Ajay Garg <ajay at activitycentral.com> wrote:

> On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg <ajay at activitycentral.com> wrote:
> Thanks a ton Gary.
> This is REALLY useful :)

Fab :)

> Please find the comments inline.
> 
> 
> On Fri, Aug 3, 2012 at 6:29 PM, Gary Martin <garycmartin at googlemail.com> wrote:
> 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.
> 
> Great !!
> 
> 
>  
> 
> - FIXED. Auto deselection after batch operation.
> 
> Great !!
> 
> 
>  
> 
> - 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.
> 
> Yep.. this is becoming a real pain.
> I have tried the solutions listed at http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038626.html, but none seem to work :-\
> Anyways, I am still trying ..
> 
> [Ajay ACTION 1] : Fix this.
> 
> 
>  
> 
> - 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.
> 
> Thanks. Reproduced the bug at my side.
> 
> [Ajay ACTION 2] : Will fix.
> 
> 
>  
> 
> - 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."
> 
> Hmm.. I think this is a false-negative.
> I tried the following ::
> 
>               * Entered "multi-select" mode.
> 
>               * Selected an entry (by ticking the check-box).
> 
>               * Re-named the entry (however, the rename was not immediately visible, due to the above bug).
> 
>               * Copied the entry to "Documents".
> 
>               * Exited "multi-select" mode.
> 
>               * Clicked "Documents" icon.
> 
>               * The entry (WITH THE MODIFIED NAME) was present.
> 
> I guess the error message "Entries without a file cannot be copied" occurred on an entry, that would have anyways given this message, even if you hadn't renamed the entry.
> 
> [Gary ACTION 1] : Please let me know if you still face the error :)

OK, sorry I must have missed an extra step (I can't reproduce this just now). Will email you if I can find a reliable way to reproduce it.

However, I seem to have found a more nasty bug, while trying to test... Switch to the Journal Documents view; select an item; rename the selected item; the selected item will be deselected – though you'll still be in multi-select mode (but with nothing selected); click the toolbar button Select none; Journal will now be in a bad/unusable state, spinning busy cursor, can't escape multi select mode, shell log shows tracebacks IOError: Couldn't open metadata directory. I needed to restart Sugar to get back to normal. I'll post some shell logs in a separate email to you.

> - 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.
> 
> Well, I would say not to effect the change during multi-select mode, because of the following reasons ::
> 
>               * Currently, the code is tightly bound to having the "current" listmodel entries in the cache. 
>                 A re-fresh, would cause the cached entries to be re-distributed, requiring a very major code change.
> 
>               * The original motive of "allowing" the user to set/unset favorite status, and rename entry, is to help the user do the processing on the entry,
>                 as she selects the entry. So, I guess it would be ok to effect the filters of these "secondary" features, AFTER the original action (copy, 
>                 erase) is completed, and "multi-select" mode exited.
> 
> [Gary ACTION 2] : Anyhow, please let me know if you think otherwise :)
>       
>  
> 
> 
> - FEEDBACK. In multi-select mode the toolbar button string 'Select none' would be better renamed as 'Deselect all'.
> 
> Ok.
> 
> [Ajay ACTION 3] : Will fix.
> 
> 
> 
> 
> - 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.
> 
> [Gary ACTION 3] : Ok, so we show the progress for all = "Select", "Deselect", "Copy", "Erase", right?

Yes, but in the primary title bar as a text widget.

> - 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.
> 
> Gary, please clarify a bit more.
> For eg, if a user wishes to do batch-copy on 15 entries (out of 97 entries), so would the snapshots be like ::
> 
> 
> <First row of text widget>      Selected 15 of 97
> <Second row of text widget>  Copying 1 of 15 <title>
> 
> 
> <First row of text widget>      Selected 15 of 97
> <Second row of text widget>  Copying 2 of 15 <title>
> 
> 
> <First row of text widget>      Selected 15 of 97
> <Second row of text widget>  Copying 3 of 15 <title>
> 
> 
> <First row of text widget>      Selected 15 of 97
> <Second row of text widget>  Copying 4 of 15 <title>
> 
> ..
> ..
> ..
> ..
> 
> 
> <First row of text widget>      Selected 15 of 97
> <Second row of text widget>  Copying 14 of 15 <title>
> 
> 
> <First row of text widget>      Selected 15 of 97
> <Second row of text widget>  Copying 15 of 15 <title>
> 
> 
> 
> OR WOULD IT BE SIMPLY
> 
> 
> 
> <First row of text widget>  Copying 1 of 15 <title>
> 
> 
> <First row of text widget>  Copying 2 of 15 <title>
> 
> 
> <First row of text widget>  Copying 3 of 15 <title>
> 
> 
> <First row of text widget>  Copying 4 of 15 <title>
> 
> ..
> ..
> ..
> ..
> 
> 
>  <First row of text widget>  Copying 14 of 15 <title>
> 
> 
>  <First row of text widget>  Copying 15 of 15 <title>
> 
> 
> [Gary ACTION 4] : Please clarify.
> 
> 
> I think I understood what is required.
> 
> * The widget is supposed to display only one line, at ANY time.
> 
> * Usually, while in "multi-select" mode, it will display "<x> of 97 selected", where "x" is the number of entries currently selected.
>   Here, as we select/deselect by single-click, or "select all" / "deselect all" button,  the update happens consequently.
> 
>   So, as is obvious, this modification helps show the number of selected entries, even when entries are selected/deselected one at a time
>   (previously, the status was shown, only when "select all" or "deselect all" was done).
> 
> * During batch-copy, or batch-erase, this widget shows the running status of the entry currently being processed.
> 
> * This seems to be a sleeker design, as it does do away with showing the running status as an alert.
>   After all, alerts are meant to convey a potentially major action ..
> 
> 
> So,  modified action for Gary :D  ::
>           [Gary ACTION 4] : Please confirm, as to if my understanding is correct.

Yes, that's it! :)

Regards,
--Gary

> 
> 
> Sorry for the inconvenience.
> 
> Thanks and Regards,
> Ajay
> 
> 
> 
> 
> 
> 
> - FEEDBACK. {confirmation_before, progress, confirmation_after}
>     ... select_none {N, N, N}
>     ... select_all {N, N, N}
>     ... erase {Y, N, N}
>     ... copying {Y, N, N}
> 
> Ok. Got it :)
> 
> [Ajay ACTION 4] : Will make the changes.
> 
> 
>  
> 
> - 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.
> 
> Ok.
> So,
>                     * [Ajay ACTION 5] : We add a "Stop" button, which occurs on any error alert message. 
>                        If the user clicks the "Stop" button, the batch-operations ends there ans then.
> 
>                     * [Ajay ACTION 6] : "Ok" button will be renamed to "Continue" button.
>  
> 
> - 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.
> 
> +1.
> Anish too had suggested the same, but then we forfeited the idea, as this would make this (unnecessarily?) complex.
> 
> Anyways, in-field experiences are the real teachers :D :D
> 
>  
> 
> Regards,
> --Gary
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> 
> Gary, waiting for your responses :)
> 
> Thanks again.
> 
> Thanks and Regards,
> Ajay
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120804/75a9ddf2/attachment-0001.html>