[development] Have you ever laughed fate in the face?
Neil Drumm
drumm at delocalizedham.com
Tue Jul 18 03:45:21 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.
Why do we need the ability to enable or disable trashbins or confirm
screens? Are there any precedents or conventions for this in other
software, web or otherwise? What group of users who might want this? [1]
- New user: shouldn't have to think about delete workflows, would rather
be doing more tangible things to learn and use Drupal.
- Web developer: probably not concerned about delete workfows, it
doesn't help the deadline.
- Site maintainer: not concerned with delete workflows, it isn't
day-to-day maintenance.
- Power user: might be concerned with delete workflows, if a client asks.
This isn't good for consistency either. More and more people are using
multiple Drupal sites. Different delete workflows following identical
buttons on different sites will lead to confusion [2]. In this case,
confusion could be disastrous.
Instead, I think we should set up guidelines for deletion. Here is a draft:
- Bad: Deletion with no confirmation, or a non-standard confirmation,
and no obvious way to restore deleted data.
- OK: Deletion with Drupal's standard confirmation screen.
- Good: Deletion with Drupal's standard undo functionality [3].
This should be tested to see if the 'good' recommendation is really good
in the real world:
1. Deploy the feature in a relatively familiar environment (a staging or
test site)
2. Ask someone who commonly deletes things to delete something and
narrate what they are thinking.
3. Observe what happens, ask questions, and take notes.
[1] Using rough groups from the old administration usability survey,
http://www.surveymonkey.com/DisplaySummary.asp?SID=1425065&U=142506581557
[2] People build mental models for how the tools they are using work.
Different delete workflows require different mental models, where a
single one is expected.
[3] Can't be a guideline until that is in code.
--
Neil Drumm
http://delocalizedham.com/
More information about the development
mailing list