On Sat, Jun 4, 2011 at 1:17 PM, Martin Abente <martin.abente.lah...@gmail.com> wrote: > On Sat, Jun 4, 2011 at 9:05 AM, Gary Martin <garycmar...@googlemail.com> > wrote: >> Hi Martin >> >> On 3 Jun 2011, at 16:47, Martin Abente <martin.abente.lah...@gmail.com> >> wrote: >> >>> On Thu, Jun 2, 2011 at 9:27 PM, Gary Martin <garycmar...@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. >
err, explicitly > 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@lists.sugarlabs.org >>>>> http://lists.sugarlabs.org/listinfo/sugar-devel >>>> >>>> >> > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
