[Sugar-devel] [DESIGN] Sugar Journal - Erase confirmation

[Martin Abente]

On Wed, 22 Sep 2010 02:51:00 +0100, Gary Martin
<garycmartin at googlemail.com> wrote:
> On 21 Sep 2010, at 23:56, forster at ozonline.com.au wrote:
> 
>>> Agreed. I think the expectation there was that a confirmation dialog
>>> would
>>> appear in a strip beneath the toolbar, with "Cancel" and "Erase"
>>> buttons.
>>> 
>>> I also agree with Walter regarding the need for multiple selection
>>> support;
>>> we had some nice mockups with checkboxes that enabled single-click
>>> (without
>>> modifier) selection of sets of objects to take action on.
>> 
>> Increasing the workload in deleting can make it more risky. Back in the
>> bad days before resume by default I have lost work while deleting
journal
>> spam. The greater the level of tedium, the less the level of care. Its
>> easy to delete the wrong item, the journal reorders itself while you
are
>> hovering on an item and waiting for a menu. A confirm button won't help
>> there, you don't notice the changed selection.
>> 
>> Multiple selection reduces the tedium, confirmation then makes more
>> sense.
> 
> +1 for a confirmation once we have a multiple selection mechanism! 
> 
>> An alternative to confirmation would be to implement some sort of trash
>> bin, has that been considered? It could even be semi-hidden in control
>> panel and auto emptying.
>> 
>> I presume checkboxes means one at a time selection. Has selection of
>> consecutive items, either by mouse swipe or by start and end selection,
>> been considered?
> 
> My past votes have been towards a start/end selection, and/or a toggle
> selection mechanism (equivalent of Mac shift key start/end, and
individual
> selection while holding the command key). My worry with check boxes is
that
> it is always visible, cluttering the Journal display for what I'd
consider
> an advanced user function, and very introduces a UI modality that needs
> some explicit way for being un-set once started. The 'give everything a
> checkbox approach' also strikes me as the bad old way of HTML email
clients
> before reasonable JavaScript support that had no better design option at
> the time.
> 
> OT: For touch only UIs there seems no standard support for multi
selection
> of items in a list. Check boxes may be more explicit in these cases,
though
> some kind of tap and hold, and or tap hold and drag could also cover
> similar needs.

> For the iPad the design is to add a top level 'Edit' button
> as part of the list view, and when touched a new edit modality is
entered
> where all list entries then gain a new button for one tap easy deletion
> (and often also a drag reorder widget) — tapping edit again reverts to
the
> usual (safe) list view behaviour.  
>


This is a very interesting concept, I think the 'edit mode' could also
prevent entries from execute related activities, so selecting items could
be as easy as clicking on entries (without the need of extra buttons or
checkboxes). Selected items could be identified by changing its color.
While the journal is in 'edit mode' all entries could be gray=scaled, then
every selected entry would recover its color.  

 
>> The primary use cases for multiple selection are delete and copy
to/from
>> usb.
> 
> Yep, and perhaps also the share with friend case.
> 
> --Gary
> 
>> Tony
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel