[Sugar-devel] [DESIGN] multi-selection in journal

[Martin Abente]

On Sat, Jun 4, 2011 at 9:05 AM, Gary Martin <garycmartin at googlemail.com> wrote:
> Hi Martin
>
> On 3 Jun 2011, at 16:47, Martin Abente <martin.abente.lahaye at gmail.com> wrote:
>
>> On Thu, Jun 2, 2011 at 9:27 PM, Gary Martin <garycmartin at googlemail.com> wrote:
>>> Hi Martin,
>>>
>>> On 31 May 2011, at 05:38, Martin Abente wrote:
>>>
>>>> Hello Amigos,
>>>>
>>>> Lately I have been working on the support for multi-selection in the
>>>> journal. This feature was originally part of Dextrose3's TODO [1], but
>>>> during EduJAM [2], many people were interested in having it on Sugar
>>>> mainstream, so I will give it a try ;)
>>>>
>>>> I already have a functional prototype running on sugar 0.9.x (check
>>>> video!) [3], its design was based on different ideas and proposals
>>>> [4,5]. My current patch does the minimum required to get this working,
>>>> avoiding any big code re-factoring or massive rewrites (for now).
>>>>
>>>> Anyway, I would like to hear everyone's feedback on the current design!
>>>
>>> First, thanks for taking this challenge on!
>>>
>>>> Thanks in advance,
>>>> tch
>>>>
>>>> References:
>>>> 1. http://wiki.sugarlabs.org/go/Dextrose/3/Todo
>>>> 2. http://wiki.sugarlabs.org/go/EduJAM/2011/Brainstorm
>>>> 3. http://www.sugarlabs.org/~tch/journal2.mpeg
>>>
>>> Nice movie :) some quick general questions/comments:
>>>
>>> - When clicking "Select all" does it only select all the currently visible objects? When clicking "Select none" does it clear the tick selection from hidden objects?
>>>
>>
>> It selects / clears all the objects that are result of the current
>> query, that is why I though it was very important to show the number
>> of entries affected by the operation in the confirmation steps.
>>
>>> - I'm not convinced changes to object details while in the multi-select mode should change the filtered selection shown. You show in the mpeg
>>> un-favouring an object in detail view and it disappearing while still being ticked for a multi-select operation, will this hidden but still ticked object be
>>> operated on?
>>
>> Nope, because is not part of the current results set (query) any more.
>> I think is very important that it only affects what the user can see
>> (with scrolling being the maximum effort required) when it trigger one
>> operation.
>>
>>> Keeping the two workflows separate might help – step one, if needed set your filter to narrow down the number of objects displayed; step two, activate >multi-selection (this list is now locked in), make your checkbox selection, take action. Or perhaps any selected objects that are filtered out could simply >be de-selected?
>>>
>>
>> If current logic is confusing, de-selecting filtered objects sounds
>> like a reasonable alternative.
>
> OK, on thinking over a little more, de-selecting any filtered out objects does seem a wise step. Example: User filters Journal by a tag they have made called [junk]; of the five objects that now appear they select one and then use the new select all button to select the rest; they then decide to edit the tag details of object so that it is no longer tagged [junk] and it disappears (still with tick selection) from the list; they now use the Delete button and confirm the deletion of the four selected and visible objects...
>
> What state is the UI now in? All four previously visible and selected objects are now gone but there is still one hidden selection. Do you show an empty list still with the multi select toolbar (user is trapped now),

Well, that is not what happens, the logic behind the "edit" toolbar
is: it will show up _if_ there are one or more objects selected in the
current results set ( NOTE: a result set is composed of elements that
matches the search criteria, once you removed the junk-tag from that
element it doesn't belong to that result set any more).

So, what happens is that after you delete all these junk-tagged
elements, the journal will show the "journal is empty" message and
since there are no selected objects in that result set, it will show
the main toolbar again.

But, if the user changes the filtering criteria again, and that
"hidden selected" is included in this new result set then it will
activate the toolbar again, so the user can know there are still
selected objects. (NOTE2: All operations affects exclusively the
elements of the current result set, so there are no risks of loosing
data unexpectedly).

Regardless of which behaviour is the best, the strongest point about
the current is: selection/de-selection must be always implicit
(individually or through toolbar's modifiers) and that is more
consistent IMHO.

Anyway, Ill experiment with that other behaviour too.

>do you stay in multi select mode and magically reveal the one hidden but selected object (confusing), do you drop back into the default Journal toolbar (user can now change the filter) but have one object still selected (confusing).
>
> Oh and an elephant hiding in the UI room is that Sugar went with the word Erase rather than Delete ;)

Ops, ill change that.

>
>>
>>> - A slight variation to this design raised a while back is to pick up on how most iPad apps now deal with multi selection lists. Rather than always
>>> showing a long line of checkbox clutter, consuming screen space, have a distinct "Edit" button in the main toolbar.
>>
>> I had the same idea originally, but there is no more available space
>> in the main toolbar, we proposed using the new toolbars in [5] but I
>> though it would be better to not touch the current design that much
>> for now. Also in [4] they described this behaviour so I just followed
>> it.
>>
>>> Once clicked display the checkboxes next to each object ready for multi-selection, once cancelled hide/clear the checkboxes. This button could perhaps
>>> be a single toggle icon that looks like your current "Select all/none" icons, and would also provide continuity toggling between the two toolbars (i.e.
>>> the multi-select on/off button would have the same placement in each, the far left would seem a likely position). This might also avoid a tick box vs.
>>> favourite star confusion.
>>>
>>
>> I am not so convinced there will be such confusion, because once a
>> user clicks on the checkbox it will be pretty obvious what it does,
>> after inspecting the toolbar. (Action and re-action consequence)
>
> Yes I think it's clear when you're actively making a selection, I'm more worried by the case when you return to the Journal from elsewhere and it is still in multi selection toolbar mode. I already find it a little disorienting when returning to the Journal and finding it with a previous filter set up (where did the new Journal entry I was just working on go), and especially the case of returning to the Journal when it is in Detail view (hopefully much improved by the new 'edit detail anywhere' work).
>

Hmm, if you think the way around it could be confusing also if you
leave the journal and it looks different when you come back. :S

>>
>>> ^^^ FWIW the above 'always show all checkboxes vs. edit mode toggle button' I seem to remember had an even split when it was last discussed – so likely no clear winner.
>>>
>>> - Need to make sure it is very obvious how to get out of a multi-select mode. We don't want to end up with another mode confusion as in Home
>>> favourite vs. list mode.
>>>
>>
>> I haven't tested my prototype with a caacupe kid yet, but I think the
>> current behaviour is very consistent and it gives me the feeling that
>> is also very "natural".
>>
>>> - If Journal is in the multi-select mode, do you still get the mono action hover palette pop-up? Can you still resume an object?
>>
>> Yes, like I commented to Simon, changing the meaning of those elements
>> might be confusing. Personally, I don't see this feature as a whole
>> new "journal mode" (at least not like in home-vs-list), for me is just
>> a toolbar change to do something very specific. Everything else should
>> be the same in order to avoid confusions.
>>
>>>
>>> I do like all the confirmation dialogues when performing operations on multiple objects. Also it's a nice touch that deleting all multi-selected objects also de-activated multi-select mode, where as the copy to action keeps the multi-select mode as is in case you want to perform extra steps on the current selection :)
>>>
>>> Great to see multi-select moving forward at last!
>>>
>>
>> Thanks for your feedback, Ill keep iterating on all your suggestions.
>
> One other small touch to your current multi select toolbar would be to disable (ghost) the Select none button if there are already no selected objects, and likewise disable the Select all button if all objects are currently selected - just to help reinforce their function.

If there are no selected objects the toolbar will not show up! :)

>
> Regards,
> --Gary
>
>>
>>> Regards,
>>> --Gary
>>>
>>>> 4. http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#06
>>>> 5. http://wiki.sugarlabs.org/go/Journal_NewUI
>>>> _______________________________________________
>>>> Sugar-devel mailing list
>>>> Sugar-devel at lists.sugarlabs.org
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>