[Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries
Gary Martin
garycmartin at googlemail.com
Tue Aug 14 12:46:14 EDT 2012
Hi Ajay,
On 14 Aug 2012, at 11:51, Ajay Garg <ajay at activitycentral.com> wrote:
> Hi Gary, Anish, Gonzalo.
>
> The "impatient" UI-interaction bug has been fixed via ::
> http://git.sugarlabs.org/dextrose/mainline/commit/e34ba2bc5554621a7770c8f5960f257bff9787f8
>
> The latest sugar-rpm (containing the fix) can be found at ::
> http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-14th-august/sugar-0.94.1-31.dx3.noarch.rpm
>
>
> Please test on the dextrose image as usual :)
Thanks. have just been testing an bumped into this new issue with the Journal UI is locking during a batch operation. You can't interact with error alerts:
http://wiki.sugarlabs.org/go/File:Journal_multiselect_lock_prevent_interacting_with_error.png
Regards,
--Gary
>
>
> Thanks and Regards,
> Ajay
>
>
>
> On Tue, Aug 14, 2012 at 8:59 AM, Gonzalo Odiard <gonzalo at laptop.org> wrote:
> Probably have sense blocking the Journal ui (and show a clock cursor)
> when doing a slow operation.
>
> Gonzalo
>
>
> On Mon, Aug 13, 2012 at 11:27 PM, Anish Mangal <anish at activitycentral.com> wrote:
> There seem to be many bugs where something 'ugly' happens when
> something is clicked "while" an operation is happening.
>
> Can't we just lock all UI actions *while* batch operations are taking
> place (and only have an abort/cancel button)? Of course, this might be
> harder said than done, and might not be the best way codewise (was
> just thinking in terms of UX)
>
> On Tue, Aug 14, 2012 at 4:34 AM, Gary Martin <garycmartin at googlemail.com> wrote:
> > Thanks Ajay,
> >
> > On 13 Aug 2012, at 07:05, Ajay Garg <ajay at activitycentral.com> wrote:
> >
> >> Hi Gary.
> >>
> >> Made the change via the patch ::
> >> http://git.sugarlabs.org/dextrose/mainline/commit/d9426b3b0be8249110d3073015d2514402734930
> >
> > That's a much smaller code change than mine ;)
> >
> >> The latest sugar-rpm can be found at ::
> >> http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-13th-august/sugar-0.94.1-31.dx3.noarch.rpm
> >>
> >>
> >> Please test with it, on your dextrose image as usual :)
> >
> > Have found a new nasty bug. If, while a batch operation is in progress, you uncheck some items, multi-select gets rather unhappy. My test case:
> >
> > 1) copy ~100 items over to the Documents folder
> > 2) switch to view the Documents folder
> > 3) check an entry and the select all
> > 4) scroll down a few pages
> > 5) click Erase
> > 6) confirm the Erase
> > 7) uncheck some entries while the batch is running
> > 8) wait for Erase batch to complete
> >
> > Result: I now see the Toolbar hint that says "Selected 3 of 100" (I unchecked 3 items during the Erase batch operation), however all ~100 items are still displayed and shown checked. I then clicked Select all and got a spinning cursor and a seemingly stalled Journal stuck in multi-select mode. As I moved the cursor over the list area the activity icons started to redraw in black and white (no more ownership stroke and fill colour, I guess due to catching up with erased metadata). Needed to reboot Sugar to recover, and on checking Documents all items had been erased.
> >
> > You can get into similar multi-select stalls by being 'impatient' with the UI:
> >
> > 1) select ~100 items
> > 2) click erase
> > 3) confirm erase
> > 4) click Deselect all while the batch is still running
> >
> > I'll post the shell log to you in a separate email.
> >
> > Regards,
> > --Gary
> >
> >> Thanks and Regards,
> >> Ajay
> >>
> >> On Mon, Aug 13, 2012 at 5:24 AM, Gary Martin <garycmartin at googlemail.com> wrote:
> >> Hi Ajay,
> >>
> >> On 12 Aug 2012, at 20:30, Gary Martin <garycmartin at gmail.com> wrote:
> >>
> >> > Hi Ajay,
> >> >
> >> > On 8 Aug 2012, at 10:42, Ajay Garg <ajay at activitycentral.com> wrote:
> >> >
> >> >> 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
> >> >
> >> > Spotted one case here, in line 96:
> >> >
> >> > if (current_entry_number % twenty_percent_of_total_items) == 0:
> >> >
> >> > If there are only a small number of items (e.g. 11) being batched operated on then it redraws too frequently (in ~2 at a time for 11 entries), so is quite slow. Batch operations should be in blocks of 10 or more at a time (unless there are less than 10 items in which case do them all at once). This also means your test at line 80 isn't being usefully triggered and I think can be removed (as far as I can tell, please test).
> >> >
> >> > The test case at line 96 should be something like:
> >> >
> >> > if min (total_items, max (10, (current_entry_number % twenty_percent_of_total_items))) == 0:
> >>
> >> Sorry that test case for line 96 made little sense! Second attempt:
> >>
> >> if current_entry_number % max(10, twenty_percent_of_total_items) == max(10, twenty_percent_of_total_items) - 1:
> >>
> >> So this should refresh the list no more frequently than every 10th entry processed, and when there are > 50 entries the 20% starts to have an effect on the distance between updates so that not too much time is wasted redrawing when there are many entries being batch processed.
> >>
> >> Your test case at line 80 should stay so that at least the first page of entries gets a reasonably quick update if there are many entries being processes, and your clause at line 86 for redrawing at the last entry covers the case for when there are < 10 items.
> >>
> >> Apologies,
> >> --Gary
> >>
> >> >
> >> > Regards,
> >> > --Gary
> >> >
> >> >> #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
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
More information about the Sugar-devel
mailing list