[Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries
Ajay Garg
ajay at activitycentral.com
Wed Aug 8 05:42:22 EDT 2012
Hi Gary.
Please find the link, for the latest sugar-rpm, that contains the
fixes/changes, as per the 3 action-items marked for me, in 7th August's
design-meeting ::
http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix-plus-3-more-7th-august-action-items/sugar-0.94.1-31.dx3.noarch.rpm
For brevity, here are the action items, and the corresponding patches ::
#action improve batch tick redraw-intervals (ajay)
http://git.sugarlabs.org/dextrose/mainline/commit/cdcf2717fe4bdd42cdbb632c51b0b371e2e3352f
#action change status strings to normal case and remove braces and / for
friendly language (ajay)
http://git.sugarlabs.org/dextrose/mainline/commit/767074994a0ea7f8356a1feafb7f2becae1b49f3
#action make Stop aleart before batch operations really stop the batch
operation (ajay)
http://git.sugarlabs.org/dextrose/mainline/commit/f4ab20a311e5090aca2e1d757c6433eb19c5522a
Please test as usual, on the dx3ng147 image :)
Also, please let know for further feedback, on the mailing-list itself. The
next Tuesday is still 6 days away :D :D
Thanks and Regards,
Ajay
On Mon, Aug 6, 2012 at 3:13 PM, Ajay Garg <ajay at activitycentral.com> wrote:
> Hi Gary.
>
> Finally... the checkbox-issue has been solved :)
>
> Please find the "fixed" rpm, containing the checkbox-fix at
>
> http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix/sugar-0.94.1-31.dx3.noarch.rpm
>
> For brevity, here is the patch link ::
>
> http://git.sugarlabs.org/dextrose/mainline/commit/381e706de7e7309d27a44ed064794a44d50aad4a
>
> The sugar-toolkit rpm remains the same as before.
>
>
>
> So, in addition to the "a) - i)" points of the previous mail, I add the
> next point ::
>
> j)
> Now there is prompt feedback of checking/unchecking the checkboxes and
> favorite-icons.
>
> However, note that for favorite-icons, there is a logical hinderance to
> true prompt feedback, as described in
> http://bugs.sugarlabs.org/ticket/3147.
>
> Checkboxes' feedbacks work perfectly !!
>
>
>
> Thanks and Regards,
> Ajay
>
>
>
> On Sun, Aug 5, 2012 at 12:02 PM, Ajay Garg <ajay at activitycentral.com>wrote:
>
>> Hi Gary.
>>
>> Please find attached the links to the "fixed" rpms.
>> Please "--upgrade --force --nodeps" on the dx3ng143 image, on which you
>> have been testing.
>>
>>
>> http://people.sugarlabs.org/ajay/root/multi-select/sugar-0.94.1-31.dx3.noarch.rpm
>>
>> http://people.sugarlabs.org/ajay/root/multi-select/sugar-toolkit-0.94.0-20120805.dx3.fc14.i386.rpm
>>
>>
>> For brevity, the patches are at ::
>>
>> http://git.sugarlabs.org/dextrose/mainline/commit/38a261887ed44756147bae44277642252cae628f
>>
>> http://git.sugarlabs.org/dextrose/mainline/commit/0c71cf00dfb8fe507627109748b5539e0eeba87f
>>
>>
>>
>> Following are the changes/fixes ::
>> All courtesy you :)
>>
>>
>>
>>
>> a)
>> 'Select none' renamed as 'Deselect all'.
>>
>>
>>
>> b)
>> Now, a text-widget has been added to the top of EditToolBar.
>> This serves the following two purposes ::
>>
>>
>> * 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,
>> and 97 is assumed to be the total number of entries.
>>
>>
>> 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.
>>
>>
>>
>> c)
>> Due to b), the progress-statuses are now NOT shown as alerts; rather as
>> texts in the text-widget.
>>
>>
>>
>> d)
>> However, any errors (such as "Entries without a file cannot be copied")
>> are continued to be shown as alerts.
>>
>>
>>
>> e)
>> Other than the progress-texts, and error-alerts, the only other
>> notification shown are the confirmation-alerts before beginning
>> with the "Batch-Copy" and "Batch-Erase".
>>
>>
>>
>> f)
>> During Batch-Operations (almost exclusively Batch-Copy), if an error
>> occurs, users are presented with two options ::
>>
>> * "Stop" - This stops the batch-operation there and then.
>>
>> * "Continue" - Proceed forward with the next journal entry.
>>
>>
>>
>> g)
>> As seen in f), the "Ok" of the error-alert has been replaced (only
>> textually) by "Continue".
>>
>>
>>
>> h)
>> There were exceptions of the form "KeyError: 'keep'" occuring in logs.
>> This was due to some cases, wherein "keep" property was not present in a
>> particular journal entry.
>>
>> So now, as a fix, we first check if "keep" is a valid metadata-key. If
>> yes, we read its value to gauge favorite-status.
>> Else, we assume that the journal-entry is an unfavorite by default.
>>
>>
>>
>> i)
>> VERY IMPORTANT NOTE ::
>>
>> Renaming a journal-entry (by clicking and modifying the contents of the
>> title-cell, has been disabled functionally.
>> This is because, the following happens when a rename is done in the
>> "Documents" view ::
>>
>> * Initially, the UID is same as the path of the entry in "Documents".
>>
>> * User changes the name. The change is written on the DS, and the UID
>> changed.
>>
>> * Now, since refresh is inhibited in multi-select view, we need to
>> fetch the new value of the title from the DS.
>> This requires the UID, through which the UID could be fetched.
>> Since the name of the "Documents" journal-entry has
>> changed, so has its UID. But in the memory, the old UID still
>> resides. Fetching the "new" title from the "old" UID does not
>> work.
>>
>> Now, I tried disabling the renaming while rendering the listview,
>> but that could not be done, as rendering th listview requires
>> knowing whether we are in multi-select mode, while multi-select
>> mode is set, after the listview is rendered. So, we are in a catch-22
>> situation.
>>
>> So, the way it works now in multi-select mode ::
>>
>> * User is apparently able to edit the title, but that is all what
>> happens.
>> There is no efective change - neither in backend, nor in frontend.
>>
>> In the normal view, the renaming works as usual.
>>
>>
>> ======================================================
>>
>>
>> PENDING CHANGES ::
>>
>> a)
>> As explained in point i) above, the renaming will not work, while in
>> multi-select mode (however, the bug you reported wherein trying to rename in
>> "Documents" folder renders the UI unusable, has been duly fixed (of
>> course, by not allowing the renaming to happen).
>>
>> If this is indeed required, this will be a major change in the way we
>> deal with UIDs for non-journal mount-points. But given that renaming is
>> affected only in multi-select mode (renaming does not work at all in
>> multi-select; while it works as usual in normal-mode), I am a bit sceptical
>> to regarding this.
>>
>>
>>
>> b)
>> A solution to the following bug ::
>>
>>
>> *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.*
>>
>> still eludes me :(
>>
>> This is an important issue, since (although there is no unusable UX, or
>> any such major workflow blocker), the select/deselect "visual" "feedback"
>> is an important thing, that should be conveyed as soon as possible. Though
>> Gary's feedback on adding a text-widget on the top EditToolBar, does help
>> show the number of entries selected, and thus gives a "textual" "feedback"
>> :)
>>
>> I would request all sugar-devel members to please post a solution to the
>> issue, for which the discussion is going on, in the thread ::
>> http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038626.html
>>
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Aug 4, 2012 at 9:59 PM, Gary Martin <garycmartin at googlemail.com>wrote:
>>
>>> 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/20120808/67706694/attachment-0001.html>
More information about the Sugar-devel
mailing list