[Sugar-devel] [DESIGN] Sugar Journal - Erase confirmation
mabente at paraguayeduca.org
Wed Sep 22 09:45:01 EDT 2010
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
>>> appear in a strip beneath the toolbar, with "Cancel" and "Erase"
>>> I also agree with Walter regarding the need for multiple selection
>>> we had some nice mockups with checkboxes that enabled single-click
>>> 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
>> 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
>> 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
> +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
> selection while holding the command key). My worry with check boxes is
> it is always visible, cluttering the Journal display for what I'd
> 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
> the time.
> OT: For touch only UIs there seems no standard support for multi
> of items in a list. Check boxes may be more explicit in these cases,
> 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
> 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
> 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
> Yep, and perhaps also the share with friend case.
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel