[development] Have you ever laughed fate in the face?
Neil Drumm
drumm at delocalizedham.com
Fri Jul 21 01:28:43 UTC 2006
Chad Phillips -- Apartment Lines wrote:
> just to put everybody in the loop here: chx and i have been discussing
> the idea of a deletion API for drupal core, which would address killes'
> modular concerns as regards this functionality, as well as allow us to
> break out all the confirm code into a seperate module. what this means
> is that site admins would have the following options for a deletion
> workflow:
>
> 1. the current scheme: no trashbin, with confirm screens
> 2. trashbin with confirm screens
> 3. trashbin with no confirm screens
> 4. no trashbin, no confirm screens (for those who like to live dangerously!)
>
> simply enable or disable either of the confirm.module or trashbin.module
> to get the desired combination.
>
> in addition, the API would provide non-core modules with greater access
> to the core's deletion cycle (which is currently fairly closed)
My latest thinking:
- The trashbin concept is a good idea and is core-worthy (with the usual
rigorous review and such). Norman [1] and Tog [2] (to name two) agree
that confirmation dialogs are often read-over, leading to unintended
consequences [3,4].
- A delete API is a good thing. Everyone loves APIs.
- Confirm screens (and later, a trashbin if in core) are basic
functionality that users should not have to think about (see
http://lists.drupal.org/archives/development/2006-07/msg00450.html). The
confirm screens should be hard-coded into core (system.module if the API
calls for adding them via hooks).
- The best place to put the choice to disable confirm screens (if a
modular trashbin is present for example) is in the API, so code can
disable it as appropriate without the need for a UI element. A module
can add the UI for disabling confirm screens if a particular site needs it.
- The delete API idea does make trashbin able to live in contributions,
but remember that moving from contributions to core is rarely smooth.
- As always, if there is a large amount of code that is added but not
used much, put it in a .inc file next to the relevant module and include
it on demand.
[1] http://en.wikipedia.org/wiki/Donald_Norman
[2] http://en.wikipedia.org/wiki/Bruce_Tognazzini
[3] Norman, _The Design of Everyday Things_ p 113:
"The user has requested deletion of the wrong file but the computer's
request for confirmation is unlikely to catch the error; the user is
confirming the action, not the file name. Thus asking for confirmation
is unlikely to catch all slips."
[4] http://www.asktog.com/columns/069ScottAdamsMeltdown.html, "Error
Four: Confirmation Substituted for Undo" section:
"For some bizarre reason, we seem to have settled on always, always,
always giving users undo for such critical operations as deleting a
single character. When users delete an entire document, however, we
offer no possible recovery. That, in the real world, would be evidence
of insanity."
--
Neil Drumm
http://delocalizedham.com/
More information about the development
mailing list