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

[Martin Abente]

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.

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

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

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