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

[Ajay Garg]

On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg <ajay at activitycentral.com> wrote:

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


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.


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/0d738a6f/attachment-0001.html>