Re: [development] Have you ever laughed fate in the face?
On Jul 17, 2006, at 2:40 PM, Neil Drumm wrote:
I think this is a good change. Forgiveness is a good thing to have. But it simply can't be added without people looking at it. Same goes for every other feature.
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) i've already begun work on this, and my goal is to have this up for testing within one week, if all goes well. in the meantime, i would still love to get reviews of the original trashbin patch, as most of that code will be used in this new API schema. patch is located here: http://drupal.org/node/35422#comment-115495 test site is located here: http://undo.xcarnated.com/
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/
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this?
I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad. We must really break out of that "all or nothing" thing in Drupal. usability is not about offering less choice. It's about making stuff easier. Aand "easy" is not a synonym for "less choices". Bèr
Ber, exposing a deletion API, and letting *developers* change the behaviour is one thing. Providing two modules for the *users* to stare at is another... IMHO one of Neil's points was this. Gabor On Tue, 18 Jul 2006, [iso-8859-1] B�r Kessels wrote:
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this?
I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad.
We must really break out of that "all or nothing" thing in Drupal. usability is not about offering less choice. It's about making stuff easier. Aand "easy" is not a synonym for "less choices".
B�r
Op dinsdag 18 juli 2006 11:00, schreef Gabor Hojtsy:
Ber, exposing a deletion API, and letting *developers* change the behaviour is one thing. Providing two modules for the *users* to stare at is another... IMHO one of Neil's points was this.
Then he did not make himself clear in that: «Why do we need the ability to enable or disable trashbins or confirm screens?» I answerd that with: because we might want to, and because it is not going to hurt anybody. Further on he states: «Bad: Deletion with no confirmation, or a non-standard confirmation, and no obvious way to restore deleted data.» This might be very true, for quite some people. and as long as it is a guideline that is perfect. But who the ** are we to decide that no-one is allowed to have this? Especially since this is a concios decision, it bothers me. Then he goes on with: «This should be tested to see if the 'good' recommendation is really good in the real world:» which is very good: suveys, investigation of our users etc. But htis should never turn into inflexible "but a mayority wants it like this so you have to live with it" hardwired deletion system. And because this was a comment on the proposal to split it out into two modules, using a hook, It is rather safe to assume he was commenting on that proposal. Having two modules is not 'staring at'. It offers not "config options" or space-shuttle-worthy interfaces". Offering a choice by disabling a module hurts no-one, confuses no-one but offers us full fredom to chose what is best in our particular cases. BTW: I am purposedly replying here and not in the issue, that is long enough as it is. I also started this discussion for a purpose, because Drupal has a rather (IMO) bad habit of oversimplifying stuff, by hardcoding its decisions in core (which is not the same as simplifying the interfaces). Think about "if you want search, and users, you MUST have a user-search tab on your search page". Or "If you want a contact form, you are forced to offer contact-form for each user (this changed in HEAD!)". I am certain all of you can find numerous examples where your site/client/users wanted Foo, but drupal forced you to get Bar with it. or where did not want A but disabling it, made itimpossible to do C and D from then on. Bèr
Bèr Kessels wrote:
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this?
I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad.
What specific situations have you been in (or anticipate to be in) where you will need to modify the delete work flow?
We must really break out of that "all or nothing" thing in Drupal. usability is not about offering less choice. It's about making stuff easier. Aand "easy" is not a synonym for "less choices".
Right, it is about offering the right choices. We aren't removing anything; we are trying to figure out the right way for a new feature to work. -- Neil Drumm http://delocalizedham.com/
On Wed, 2006-07-19 at 01:39 -0700, Neil Drumm wrote:
Bèr Kessels wrote:
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this?
I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad.
What specific situations have you been in (or anticipate to be in) where you will need to modify the delete work flow?
quickies I think of.... -administrative oversight of deletion -allow archival of deleted items to another server while deleting them from customer facing servers. -protect end-users and administrators from accidental deletion.
We must really break out of that "all or nothing" thing in Drupal. usability is not about offering less choice. It's about making stuff easier. Aand "easy" is not a synonym for "less choices".
Right, it is about offering the right choices. We aren't removing anything; we are trying to figure out the right way for a new feature to work.
Darrel O'Pry wrote:
On Wed, 2006-07-19 at 01:39 -0700, Neil Drumm wrote:
Bèr Kessels wrote:
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this? I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad. What specific situations have you been in (or anticipate to be in) where you will need to modify the delete work flow?
quickies I think of....
-administrative oversight of deletion -allow archival of deleted items to another server while deleting them from customer facing servers. -protect end-users and administrators from accidental deletion.
None of these call for removal of any trashbin we might add. -- Neil Drumm http://delocalizedham.com/
We need to prevent users from deleting their nodes. They can discontinue (unpublish), but not delete them. (We want the node data to still be in the database, not just in a restorable trashbin). Would be good to allow for this kind of configuration. --mark On 7/19/06, Neil Drumm <drumm@delocalizedham.com> wrote:
Darrel O'Pry wrote:
On Wed, 2006-07-19 at 01:39 -0700, Neil Drumm wrote:
Bèr Kessels wrote:
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this? I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad. What specific situations have you been in (or anticipate to be in) where you will need to modify the delete work flow?
quickies I think of....
-administrative oversight of deletion -allow archival of deleted items to another server while deleting them from customer facing servers. -protect end-users and administrators from accidental deletion.
None of these call for removal of any trashbin we might add.
-- Neil Drumm http://delocalizedham.com/
-- mark burdett mark@goodstorm.com +1 (415) 341-2815 [mobile] +1 (415) 223-0305 [office] http://www.goodstorm.com/ 835 Terry Francois St San Francisco CA 94158-2209
I agree with Mark. As some probably know. Many systems never delete anything from the database. In my case, these systems were in the Pharmaceutical Industry where everything needs to be 100% audited (http://www.21cfrpart11.com). So what IT called deleted, was actually just a flag in a column and no "user" could see these items without going through the approved and tested workflows. So just for the record, I would like a "deleted" column in Drupal. Preferably it would be something I don't have to think about. The db layer could automatically adjust incoming SQL to filter out the deleted records, hence existing code would not need changing. Alternatively, querys that need to access deleted records could pass an additional variable to say so. Simon mark burdett wrote:
We need to prevent users from deleting their nodes. They can discontinue (unpublish), but not delete them. (We want the node data to still be in the database, not just in a restorable trashbin). Would be good to allow for this kind of configuration.
--mark
On 20-Jul-06, at 12:17 AM, sime wrote:
So just for the record, I would like a "deleted" column in Drupal.
In some of our internal applications, we've gone with a "deleted date" field to indicate when a particular record was marked as deleted by a user. So you get built in tracking of actions, and the system can easily filter out items with a deleted date (> 0 or "not null" depending how prefer your tables) while being able to hang onto the data in case it is needed later on. -Rowan
On 20 Jul 2006, at 7:57 AM, Rowan Kerr wrote:
On 20-Jul-06, at 12:17 AM, sime wrote:
So just for the record, I would like a "deleted" column in Drupal. What I think would be cool... is if you had the db_create_table function, to spawn new derivative tables.
ie: node_deleted (or node_archived) , etc. The logic for applying updates to trash binned content can become very complex though =( -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Rowan Kerr wrote:
On 20-Jul-06, at 12:17 AM, sime wrote:
So just for the record, I would like a "deleted" column in Drupal.
In some of our internal applications, we've gone with a "deleted date" field to indicate when a particular record was marked as deleted by a user. So you get built in tracking of actions, and the system can easily filter out items with a deleted date (> 0 or "not null" depending how prefer your tables) while being able to hang onto the data in case it is needed later on.
if you didn't want to do custom development, you could use workflow and workflow_access for this. worflow_access is part of the na_arbitrator bundle.
On Thu, 20 Jul 2006 09:44:20 -0400, Moshe Weitzman <weitzman@tejasa.com> wrote:
if you didn't want to do custom development, you could use workflow and workflow_access for this. worflow_access is part of the na_arbitrator bundle.
I was actually referring to desktop apps and other non-drupal stuff, but it's good to hear that workflows are coming along. :) -Rowan
How is this different than "unpublishing" a node? Perhaps the Delete button should become an Unpublish button. Then an admin would use the regular admin interface if a node needed permanent deletion. Farsheed --- sime <info@urbits.com> wrote:
I agree with Mark.
As some probably know. Many systems never delete anything from the database. In my case, these systems were in the Pharmaceutical Industry where everything needs to be 100% audited (http://www.21cfrpart11.com). So what IT called deleted, was actually just a flag in a column and no "user" could see these items without going through the approved and tested workflows.
So just for the record, I would like a "deleted" column in Drupal.
Preferably it would be something I don't have to think about. The db layer could automatically adjust incoming SQL to filter out the deleted records, hence existing code would not need changing. Alternatively, querys that need to access deleted records could pass an additional variable to say so.
Simon
mark burdett wrote:
We need to prevent users from deleting their nodes. They can discontinue (unpublish), but not delete them. (We want the node data to still be in the database, not just in a restorable trashbin). Would be good to allow for this kind of configuration.
--mark
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Farsheed wrote:
How is this different than "unpublishing" a node? Perhaps the Delete button should become an Unpublish button.
Unpublished things might want to be published later. Deleted things are things that don't need to be seen again (at least thats the assumption at the time of deletion). The whole node status thing could use some work (I think drafts would be useful and the whole http://drupal.org/node/38451 mess for example), but is not relevant for a general delete API. -- Neil Drumm http://delocalizedham.com/
mark burdett wrote:
We need to prevent users from deleting their nodes. They can discontinue (unpublish), but not delete them. (We want the node data to still be in the database, not just in a restorable trashbin). Would be good to allow for this kind of configuration.
Best solution: permissions or somesuch to regulate deletion. Okay solution: make a disable_node_deletion.module that takes the delete buttons out via formapi. -- Neil Drumm http://delocalizedham.com/
Jakub Suchy wrote:
Okay solution: make a disable_node_deletion.module that takes the delete buttons out via formapi.
This is not okay solution, it's only security by obscurity.
Formapi can also be used to unconditionally throw a validation error on the confirm form. -- Neil Drumm http://delocalizedham.com/
On Wed, 2006-07-19 at 10:39 -0700, Neil Drumm wrote:
Darrel O'Pry wrote:
On Wed, 2006-07-19 at 01:39 -0700, Neil Drumm wrote:
Bèr Kessels wrote:
Op dinsdag 18 juli 2006 05:45, schreef Neil Drumm:
What group of users who might want this? I want this. What is wrong with choice? Offering choice, with good defaults is good. Offering only the good defaults without any choice to break out of them is bad. What specific situations have you been in (or anticipate to be in) where you will need to modify the delete work flow?
quickies I think of....
-administrative oversight of deletion -allow archival of deleted items to another server while deleting them from customer facing servers. -protect end-users and administrators from accidental deletion.
None of these call for removal of any trashbin we might add.
There was nothing said about the removal of trash bin functionality. If you want use cases for removal of... I'm an admin of site with a bunch of content that is there an then gone, maybe some sort of collaborative tool using drupal, and having to regularly dump the trash bin is just annoying. continuity of the existing user interface (the trashbin while not new in most gui's, would be a big change for the drupal ui). I think that should be kept in mind.. Massively changing interfaces can annoy users. I know the menu rearrangements in drupal from version to version have made my life annoying on more than on occasion. Options are better than hardcoded ideas. I use drupal as an application platform. That kind of control over the deleting workflow would be nice. It would be nice on a per node type basis. personally I prefer a take what I want dump the rest approach to setting up drupal.
Neil Drumm wrote:
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]
I have requested that Drupal be made more modular so that people who want it can use Chad's trashbin.module and people who don't (me) don't need to bloat their Drupal by a largish amount of code.
- 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.
No Drupal site is the same as any other. With the same argument you could argue against things like form API's ability to put in new fields into preexisting forms. Yet you didn't, IIRC.
Instead, I think we should set up guidelines for deletion. Here is a draft:
Sorry, no. Your guidelines might be right for your site(s) but wrong for mine, they might be right in one culture and wrong in multiple others. Drupal has long enough suffered from things like, "I don't think we'll ever need this (on drupal.org)". We should not strive to take choices away from people who want to build websites. Cheers, Gerhard
On 7/18/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
We should not strive to take choices away from people who want to build websites.
That's probably the best point. I think this should only be exposed to the "power user" or anyone with admin access, but not an everyday "user" (which I believe is the current intention of Chad and Killes). For other examples of this kind of interaction: I love some of the "trashbin" features in GMail which are similar to this. For example - I had composed a resonse to Neil, then decided against it so I "discarded" the response. But GMail doesn't delete it, it just hides it. Then if I decide I want it back I can just un-discard the response and I have the content again. While this is not a common interaction model on many websites, it is a fancy helpful and easy-to-use one! We already have settings in Core that allow drupal's site-admins to create sites with wildly different functionality: the comment sorting/viewing/posting settings can make different sites very different from each other. I see that as a strength, not a weakness. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
Greg Knaddison - GVS wrote:
On 7/18/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
We should not strive to take choices away from people who want to build websites.
That's probably the best point. I think this should only be exposed to the "power user" or anyone with admin access, but not an everyday "user" (which I believe is the current intention of Chad and Killes).
No, at least not mine. The idea is to allow for modules to handle the deletes by implementing hooks. Modules are enabled by site admins not end users. If I write "user" in a Drupal development context, I always mean the person that downloads drupal-4.7.x.tar.gz, installs it, and creates the site. The users of said site are that site's users not Drupal's. Cheers, Gerhard
Gerhard Killesreiter wrote:
Greg Knaddison - GVS wrote:
On 7/18/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
We should not strive to take choices away from people who want to build websites.
That's probably the best point. I think this should only be exposed to the "power user" or anyone with admin access, but not an everyday "user" (which I believe is the current intention of Chad and Killes).
No, at least not mine. The idea is to allow for modules to handle the deletes by implementing hooks. Modules are enabled by site admins not end users.
Hmm, it /might/ be I misread Greg's comment. :p Cheers, Gerhard
On Jul 18, 2006, at 7:28 AM, Gerhard Killesreiter wrote:
If I write "user" in a Drupal development context, I always mean the person that downloads drupal-4.7.x.tar.gz, installs it, and creates the site. The users of said site are that site's users not Drupal's.
not to pick a fight about terminology, but i think this is misleading... ;) we, the drupal developers, should be concerned about the usability of drupal for both of these sets of "users". i think it's more consistent to call the end-users of drupal sites "users" and the people who download and install drupal the "admins". that's how it breaks down for them, that's the basic terminology within drupal itself, and i think that's how most of us already talk about things. of course, there are different kinds of "admins" (i.e. someone who knows nothing about php and installs drupal via a packaged installer vs. a developer who sets up a site out of a cvs workspace), but i'm less concerned about that distinction, and "developer" vs. "power admin" vs. "novice admin", etc, would easily get the point across if you needed to be specific. the only reason i raise it is that i'd be wary of any mindset or terminology choice that tends to push end-users-of-drupal-sites off the radar of the development community, since we have to make drupal "easier" for them, along with admins (and, as dries and others have pointed out, us developers, too). On Jul 18, 2006, at 8:35 AM, Gerhard Killesreiter wrote:
Hmm, it /might/ be I misread Greg's comment. :p
right, no harm done. ;) i'm just pointing out why adopting consistent terminology about something as important as this would help avoid misreading each-others proposals... especially if a major development focus for the foreseeable future will be "usability"... "usability for whom?" i'd argue all three groups (users, admins, developers) could use some lovin', and obviously different patches will effect the usability for different groups. we'll all be happier and get more done if everyone immediately understands which group(s) a given patch or proposal targets (and not just for usability, for that matter). thanks, -derek
On Tue, 18 Jul 2006, Derek Wright wrote:
we, the drupal developers, should be concerned about the usability of drupal for both of these sets of "users". i think it's more consistent to call the end-users of drupal sites "users" and the people who download and install drupal the "admins". that's how it breaks down for them, that's the basic
Nope. A lot of people work here to set up sites and then leave to others to administer. Then those admins use what they got. So they have never bothered downloading the site software, they might not even know that they are administering a Drupal based site. Admins is not the right terminology, it only assumes ongoing maintanance IMHO. Gabor
On Jul 18, 2006, at 10:16 AM, Gabor Hojtsy wrote:
Nope. A lot of people work here to set up sites and then leave to others to administer. Then those admins use what they got. So they have never bothered downloading the site software, they might not even know that they are administering a Drupal based site. Admins is not the right terminology, it only assumes ongoing maintanance IMHO.
maybe. if you think so, please propose a better terminology, instead. ;) however, i think your distinction doesn't matter that much... if someone is a "site admin" "site maintainer", whatever you want to call it, they've got access to [site]/admin/* (note the URL, that's what i'm talking about when i say "our existing terminology...") and things we do (like the settings page re-org) will effect them, even if they don't necessarily use the word "drupal". they're an "admin" IMHO. not all "admins" necessarily download and install the software themselves. some have a working, basic site handed to them by a drupal hosting service, others by a consultant/web designer/etc. i don't really care. if they mess around in [site]/admin/*, have power to ban/approve users, do administrative stuff, etc, they're an "admin"... if you really want to split out the sub-group of admins that install their own site from the ones that have it handed to them by a consultant or hosting company, you could add a 4th term to my list: "site builder" (or something). so, you'd have: developer site builder admin user would that make you happier? true, some changes only effect site builders and not admins, so in the interest of avoiding ambiguity, i suppose that 4th classification could be helpful. and, i guess that themeing and "designing" is a layer that usually lives between developer and admin, so that's another group of folks to lump in as "site builders". that said, my goal is to use concise terminology, so if you're talking about a change that only matters for people doing themeing, you can just say so... i still think "user" means "end-user-of-the-drupal-site", i.e. what the majority of us are in relation to drupal.org[1], not just dries/ steven/killes since they "downloaded drupal and installed the site" (vast oversimplification, just trying to make the point)... thanks, -derek [1] yes, obviously some of us have some limited "admin" rights on drupal.org, e.g. to admin content, but that's not the main idea. obviously, there are MANY shades of grey. i'm just talking about the big picture.
On 7/18/06, Derek Wright <drupal@dwwright.net> wrote:
if you really want to split out the sub-group of admins that install their own site from the ones that have it handed to them by a consultant or hosting company, you could add a 4th term to my list: "site builder" (or something). so, you'd have:
developer site builder admin user
would that make you happier? true, some changes only effect site builders and not admins, so in the interest of avoiding ambiguity, i suppose that 4th classification could be helpful. and, i guess that themeing and "designing" is a layer that usually lives between developer and admin, so that's another group of folks to lump in as "site builders". that said, my goal is to use concise terminology, so if you're talking about a change that only matters for people doing themeing, you can just say so...
From Neil's email on the subject:
What group of users who might want this? [1]
- New user: - Web developer: - Site maintainer: - Power user:
Which cites the definitions given in this survey: http://www.surveymonkey.com/DisplaySummary.asp?SID=1425065&U=142506581557 I think we've got user definitions and that they are pretty good. And I think we should try to make sure Drupal is easy to use for all of them. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
Op dinsdag 18 juli 2006 20:08, schreef Derek Wright:
they're an "admin" IMHO. not all "admins" necessarily download and install the software themselves. some have a working, basic site handed to them by a drupal hosting service, others by a consultant/web designer/etc. i don't really care. if they mess around in [site]/admin/*, have power to ban/approve users, do administrative stuff, etc, they're an "admin"...
All the sites that I built for various clients can be split up into two kinds of sites: over-the-wall and nicely-preprepreprepared. The first group is for people who know Drupal well, know php etc (usability is not an issue with these sites), I finish requested modules and trow it over the wall. The second group allows me to be very creative with settings, permissions, modules, filters, roles etc. They require a very tight focus on usability. And frankly, * the more freedom Drupal gives me, the finer grained the permissions are, the more modules I have, the better the usability for the end-user/client is! If *I* am given more flexibility I can build a very good, usable, well structured site for a client. If Drupal (or any module) takes that power away from me, (oversimplifying) I end up delivering a less usable site. My client has to see/do things he/she could do without. My client gets options on his screen that he really does not need. (Yes, you still need to give someone full administer node permissions if all he wants is promote a node to frontpage). My client has a much less usable site. Take views, or cck: They are very complex, but I can learn it once, and my clients never need to learn it. So why simplify views to make it more "usable"? All my client sees is a table with all his products in it. He never needs to know that I fought with views exports. That I digged for the proper CCK field setting. And FWIW: I count myself as a Drupal user. My clients never (should) need to know they are Drupal users. They use a site. They really don't care what stuff is behind it. Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
Gerhard Killesreiter wrote:
Neil Drumm wrote:
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]
I have requested that Drupal be made more modular so that people who want it can use Chad's trashbin.module and people who don't (me) don't need to bloat their Drupal by a largish amount of code.
If there is a lot of additional code, then it should be included conditionally as we usually do.
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.
No Drupal site is the same as any other. With the same argument you could argue against things like form API's ability to put in new fields into preexisting forms. Yet you didn't, IIRC.
I think form API is a significantly different situation.
Instead, I think we should set up guidelines for deletion. Here is a draft:
Sorry, no. Your guidelines might be right for your site(s) but wrong for mine, they might be right in one culture and wrong in multiple others.
Thats why we back up the guidelines with supporting works, research, and testing as appropriate. We already have the 'bad' and 'okay' guidelines in our unwritten set of conventions.
We should not strive to take choices away from people who want to build websites.
We should offer the right choices. -- Neil Drumm http://delocalizedham.com/
"taking away freedom" sounds more like a political soundbite (no, no one in particular ...) than a useful argument - i think it'd be more constructive to be specific. Here's my two specifics: 1. as an example - my experience with Mailman is that it has too many choices about configuring lists - not only are the choices hard to understand, some combinations should never be chosen. I really like sympa, as an alternative, where you can choose the type of list you want, and then you can fiddle with the details if you understand them. In this case - the equivalent would be that you would choose a 'workflow' level of abstraction when setting up, but could modify the details if you knew how to and needed to. 2. re: neil's question about why you might want to change it. When someone (someone else of course!) just imported 200 nodes and goofed something, and I have to manually delete them all, I want to turn off the trashbin and (maybe) the confirm. Of course, there will always be better tools to accomplish this, but I suspect this kind of thing happens a lot in real life. In fact, anytime there are automated publishing mechanisms (aggregator2 springs to mind as well), then there will be times when you want to skip the workflow to fix errors. Conclusions: 1. From a code point of view, I think the separate module(s) is a good idea. 2. From a usability perspective, I think an interface that offers choices that are tailored to use-cases rather than to technical details is essential. Having access to the technical choices is nice. I don't think these two conclusions need to be contradictory. -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
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/
Neil Drumm wrote:
My latest thinking: ...
- And I'm not personally going to worry about the database model, other than say that Dries has an excellent point and Chad has a good response. I will review for usability, code clarity, scalability, security, etc. -- Neil Drumm http://delocalizedham.com/
participants (16)
-
Adrian Rossouw -
Alan Dixon -
Bèr Kessels -
Chad Phillips -- Apartment Lines -
Darrel O'Pry -
Derek Wright -
Farsheed -
Gabor Hojtsy -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Jakub Suchy -
mark burdett -
Moshe Weitzman -
Neil Drumm -
Rowan Kerr -
sime