Usability: Workflow (published / unpublished) as buttons
Arancaytar - July 13, 2008 - 16:58
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | usability |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (code needs work) |
Description
The Usability Report complains about such critical settings as "Published" being hidden in a collapsed fieldset. Nick Lewis suggests to solve this by changing the workflow to intelligent buttons that showed up depending on context and user permissions:
On a new node:
[Publish] [Save as Draft] [Preview]
On a non-published node:
[Publish] [Save changes] [Preview]
On a published node:
[Save and republish] [Save and unpublish] [Preview]
Comments?
#1
I like that. Here is a preliminary patch.
Of course, tests will fail with that, because we changed the button names.
#2
I would say that for a published node, [Update] would be a better way to describe [Save and republish]. It's shorter and I think makes more sense, because you aren't changing the node and then publishing again, you're just updating and existing published node.
Since tests will fail, CNW.
#3
Update is the wrong term. We use Save for the action of submitting content, and Update for changing the database schema. So while we can possibly leave out the words "and Republish" we do have to say "Save" just for consistency.
#4
I think this might work better:
On a new node:
[Save as Draft][Publish] [Preview]
On a non-published node:
[Save as Draft][Publish] [Preview]
On a published node:
[Save changes] [unpublish] [Preview]
Will look into how some other systems are doing this.
***
Consider adding status messages between published and unpublished. How best to phrase them is tricky, but they'd need to get the point across that content is live, and anyone can now view vs. changes are saved, and the piece of crap draft is still a secret between the user and the cms.
Its good to reassure users that the system did what they thought it was supposed to do (and alert them if something else had happened).
#5
Sounds good.
This changes the labels to what you suggested, and adds a message whenever the node status changes. Specifically:
+ if ($form_state['old_status'] != $form_state['values']['status']) {+ if ($form_state['values']['status']) drupal_set_message(t('@type %title has been published.', $t_args));
+ else drupal_set_message(t('@type %title has been unpublished.', $t_args));
+ }
(old_status is 0 if the node has not yet been created, so saving a newly created node as a draft will not be called "unpublishing".)
#6
This mostly works for me. Only found two issues:
1. Node type settings provides a mysterious "published" checkbox. See screenshot.
2. Two messages popup -- one for status, and the other to alert the user that the node was updated. I feel like there only needs to be one message, and two is a bit strange.
Also a couple odd things I noticed while testing -- neither of these are a result of the patch -- they work like this on head as well...):
1. Hit submit and press the back button, then save again -- you get an error.
2. The unpublished style bleeds into the message, and looks shoddy (see attached screenshot).
#7
@Nick Lewis: for your two "unrelated" issues:
#1 is by design
#2 is already reported in http://drupal.org/node/282852
I agree about the need to have a unique message on submit. Also, the "published" checkbox should be renamed "publish by default".
#8
The checkbox will probably still be required. It may seem as if requiring the user to select an option by pressing a button eliminates the need for the default value, but there are still access permissions to think of. A user who can't administer content will be unable to save default-public content as a draft, or publish default-nonpublic content.
Yes, pet peeve here. It's been that way in D5, too. Drupal is being overzealous about preventing post conflicts - if the node was saved after the form was last generated, the submission is blocked. Two solutions, a simple, specific and a complex broad one, which are not exclusive:
1. Check the user who last modified the node. If it is the same user, odds are he knows what he's doing and should be allowed to overwrite his own submission.
2. Warn the user, generate a diff and allow him to merge the changes immediately. Mediawiki does this very elegantly.
But that should be another issue. Say, this: #106953: Better handling of editing conflicts
I was wondering whether to add the message or replace the existing one. Perhaps the latter is indeed the better idea.
#9
On further review of my own patch:
<?php$form['options']['status'] = array(
- '#type' => 'checkbox',
- '#title' => t('Published'),
+ '#type' => 'hidden',
'#default_value' => $node->status,
);
?>
This should probably be '#type' => 'value' and not 'hidden'.
#10
Also, don't forget that value-type fields have a #value, not a #default_value.
#11
@Arancaytar in #8 - that's a good point about the permissions.
This patch might need to be merged with #214190: Publish nodes permission in order to work cleanly.
I have concerns about Nick Lewis' third situation here:
If they unpublish, does this save changes or not?
#12
It does, and I'd argue for "Save and unpublish" too (I actually kept that in my last patch). There's no law against multiple word lables, especially when the button actually does two things (saving and changing the public status).
I'd love to get the patch you linked to in. It's very impractical to use drafts on any site, just because publishing and unpublishing requires global mod permissions.
#13
@Arancaytar, catch -- I agree, I gravitate towards the fewest words as possible, and sometimes have too much faith in stuff like that being implied. I forgot that usability law: More words less thought required > few words more thought required.
#14
[Sorry if this is the wrong place to post this, but the issue is pretty much the same (except for the version)]
I've done something similar in a module for D6. I was thinking about making it publicly available on the modules page.
It'd be good for minor usability improvements for node publishing and administration, based on Dries' posts on the reports from the two universities, and would be D6 (and <6 for who's interested in porting).
Anyone have any suggestions or objections? I'm assuming these Workflow changes will be D7 only, so in helping those D6 users until then, maybe a module would be nice?
#15
@eisicht: you are right in that this wouldn't probably go into D6. Feel free to publish a module :)
#16
Hm.
If I had my way, core would support far *more* workflow states (all nice and customizable ala Workflow module, of course) than merely Published, Unpublished, and Draft. For example, "Pending legal review" or "Needs editing and approval."
Not having applied this patch, but going by Nick Lewis's "mock-up" in #4, I don't think this UI will scale for more states. It would "lock" sites into having only those three, and all other workflow states being added in via some other means, thus causing inconsistency.
I realize that right /now/ we don't have customizable workflow states in core, and may very well not for D7 (or even D9 ;)). But my preference would be for this would be to have the UI be both user-friendly for the current case but flexible enough for core or contributed modules to add additional states later on, as necessary.
#17
I agree with you, and I conclude that there is some confusion about what a "state" in the workflow actually is.
Here on d.o, we have a nicely defined workflow for issues - active, cnr, cnw, rtbc, fixed. You can select these from a drop-down menu. On a fresh Drupal installation, all you have are some checkboxes - it's not so much a work "flow" as an option.
If workflow is intended to be extensible, covering more than just Published/Invisible, as the issues here on d.o, then we need to find some way to make the workflow a drop-down menu. Otherwise, with only two states (or rather one toggling option, "Published") to choose from, the buttons make sense. What we need to get away from, though, are the checkboxes...
#18
@webchick, I hear you on the need for multiple types of workflow states, and that this patch interferes with a consistent UI element that could be used for all. However, I think that publish, unpublish, and draft are the workflow states that 95% (a number pulled out of my ass, of course) will ever have to deal with. And that they are important enough to warrant "special case" treatment. Additional workflow states should use what? A checkbox, or perhaps radios? I think most of them may want to use radios, but I just don't know... anyways, i think this is still an improvement that the vast majority of drupal sites will benefit from.
I am biased, since I've had to make this modification on multiple drupal sites via client request.
#19
Moving all usability issues to Drupal - component usability.
#20
Moving all usability issues to Drupal - component usability.