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

[Ajay Garg]

Thanks a ton Gary.
This is REALLY useful :)

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 :)




>
> - 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?




>
> - 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.




> - 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/20120803/ca3513e0/attachment-0001.html>