Opened 9 years ago

Closed 8 years ago

#3368 closed enhancement (fixed)

delete in Journal detail view should prompt to confirm delete

Reported by: walter Owned by: garycmartin
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: design Version: Git as of bugdate
Severity: Critical Keywords:
Cc: Distribution/OS:
Bug Status: New

Description

At the Holmes Camp, I saw several times that teachers (not kids) accidentally deleted Journal entries from the Detail View by mistaking the delete button for the back button. It would be a useful enhancement to add a confirmation to delete to avoid this problem.

Change History (3)

comment:1 Changed 9 years ago by garycmartin

+1 Sounds like a good idea, and we will want to keep an eye open for other distructive toolbuttons in activities as we move towards a touch friendly interface as toolbuttons can't be discovered via hover hints.

comment:2 Changed 9 years ago by sascha_silbe

  • Bug Status changed from Unconfirmed to New
  • Component changed from sugar to design
  • Distribution/OS Unspecified deleted
  • Owner set to garycmartin
  • Severity changed from Unspecified to Critical
  • Version changed from Unspecified to Git as of bugdate

A different option would be to support some kind of undo for the erase operation, making it a two-stage process. An existing metaphor for this is the recycle bin, storing the to-be-deleted entries until they get irrecoverably removed by emptying the bin.

In general, pervasive undo is a better solution than asking security questions: It only takes a _single_ mistake, one Yes instead of a No (or vice-versa) in order to do (usually irreparable) harm if you can't undo an action.

Erasing may be considered an exception because general-purpose computers require free space on permanent memory in order to operate correctly. On XOs it's easy to run out of space even during normal operation; erasing large entries is the only way to reclaim space and make the computer usable again. This means we should carefully consider what a good design would be: Because it happens regularly, there's a high chance of mistakes happening (even with a two-stage approach). OTOH it must be efficient to use and reasonably immediate.

comment:3 Changed 8 years ago by godiard

  • Resolution set to fixed
  • Status changed from new to closed

Delete in the Journal detail view already ask confirmation in sugar 0.98

Note: See TracTickets for help on using tickets.