Usability: Make "publishing options" easier to understand

The t() strings need to be improved. use %type and replace as appropriate.

also, I may be wrong but isn't node->type the machine readable name of the node type?

+1.

Looks great to me

I'd make it non-italic but that might be personal taste.

We went through this idea of strtolowering the human readable node type and decided against it for the other "Edit Blog entry" pages or whatever they were. What if your node type is named "Betty's recipe" or "XYZ Company" or "eCommerce product"? But, it does look weird have the caps in there...Is it overkill to add a Human readable lowercase or should we just lowercase it and not worry about it? I'd almost rather have it look weird and maintain case, then be grammatically incorrect by lowercasing those edge case node type names. Either way we need to be consistent in the other parts of Drupal. Thoughts?

Also, these are my votes for text. We are removing node from user facing text. Also, we'd need to match these on admin/content/types.

Publish this @type
Promote this @type to the front page (this one is tricky because you can set your front page to something else. Think we should add some description text to admin/settings/settings)
Make this @type sticky at top of lists
Create a new revision for this @type

Sorry to be a pain, but the other issues in my comment are still there, i.e. "node" in user facing text, and some of the other wording. I think we need another review too.

Sorry, I meant your last patch in #11 says "node-overview page":

+  $form['options']['promote']  = array('#type' => 'checkbox', '#title' => t('List this @type at the node-overview page', array('@type' => $post)), '#default_value' => $node->promote);

I think adding more text to these options is merely going to make the interface more ugly without fixing the underlying issue, which in my mind is Half of the node options checkboxes are defacto "actions", and therefore want to be submit buttons.

I'm not going to attempt to block this patch as I'm wading heavily in the waters of subjectivity and don't have a patch of my own on hand. However, personally, I don't think its an improvement.

We really should be conservative about adding too much text to our node forms... True usability improvements -- in my mind -- remove the need for having ugly sentence long descriptions for every form field. In fact, too much help text is becoming a usability problem in my mind (on the grounds that it often deemphasizes the really important and necessary help text) -- but that's another issue....

The improvement I want to see is this: actions should be submit buttons, attributes should be checkboxes.

1. "Publish" should be a submit button that saves a node with $node->status = 1
2. The unchecked "publish" should be another submit button titled "save as draft" that sets $node->status = 0
3. "create new revision" -- this is the most complex usability problem -- should probably disappear all together in its current form, and instead be a link to a special form with menu path node/$nid/revision/add -- the main difference between the revision form and the regular node form would be that the submit buttons would be specific to revision related actions, e.g. something along the lines of "save as draft revision", "save as live version" -- it really deserves a lot more thought than we realistically have time for in this release.
4. sticky, and promote should remain unchanged -- simple checkboxes with an explanation. "Publish", or "save as unpublished" "Sticky" isn't an action so much as a behavior that you want a node to have.

I partly agree with Nick as far as adding making the text more verbose doesn't improve usability IMHO, it just forces the user to read more text.

We might add a description to the individual checkboxes, but I think the flags are pretty self-explanatory. If the user doesn't understand "Promoted to front page" or "Sticky on top of lists", it's because s/he doesn't understand the underlying concepts. This means the user is obviously overstrained with the permissions of his/her role.

While some of the checkboxes could be seen as actions, I don't want the node edit form be cluttered with various submit buttons. In the end, the flags can also be seen as the attributes to start with, and actions as something that can change these attributes on certain events. Don't see a logical flaw here.

Still, I agree we should reconsider "create new revision", as this one "just feels weird" and is not self-explanatory to untrained users. Also the term "draft" is a quite interesting perspective to look at unpublished nodes.

Anyway we need to move this to D7 as we are in string freeze and need some more thoughts about this here.

As a new Drupal user, this was quite confusing. The interface should be as consistent as possible, so putting interface elements that look "equal" in functionality together when they do not work the same way is basically breaking the interface. Having to click on "Create New Version" each time doesn't make sense from a UI perspective and is not expected behavior.

It appears the point was that users might not want to create a new version each time. Fair enough.

In looking at this, it seems that the revisions checkbox could be revised to say something like "Allow version history." If this is checked, the submission buttons would change to something like "submit new version" and "overwrite current version".

This way the extra submit options only appear if the versioning toggle is on.

My $0.02.

Accidentally changed the thread title. My bad.

Moving all usability issues to Drupal - component usability.

I am picky.

"We might add a description to the individual checkboxes, but I think the flags are pretty self-explanatory. If the user doesn't understand "Promoted to front page" or "Sticky on top of lists", it's because s/he doesn't understand the underlying concepts."

Hmmwell yes and no.
Where does it explain that the default Drupal home page is a feed of recently posted nodes, from those content types that are set to appear there automatically, and from those nodes that have been set as such by users with that permission? Because last time I looked at the Getting Started handbook, it didn't explain any of that.

The designer at my firm thought it meant "make this node BE the front page" (ie, the same as putting node/xx into the front page setting) and then got really confused because things weren't behaving at all as he expected. But the behaviour he expected is a perfectly valid interpretation of "promote to front page".

I think that "List this @type at the node-overview page" is a bit ugly though. Firstly, AFAIK there's a policy to avoid the term 'node' for end-users.
"Show in default front page"?

(The site is telling me I have to pick a component... what's happened to the Usability component?)

I had the exact same with a client as #21.

Beside renaming the link, I think a option to disable the option completely would be a good idea as there are sites which don't use that flag at all.

Re #21: Perhaps the label should be made dynamic?

The label would be "Show on front page" only if the front page is set to /node. If not the label would be set to something generic like "Show on posts page". (Posts page is what Wordpress calls such a page.)

I have created an issue and patch for the "Published to front page" misnomer: #404300: "Promote to front page" is a misnomer. It seems like this discussion isn't getting traction as a conglomeration of smaller issues, so maybe it would be best to break it up a bit.

Most of the options were already revised in the meantime.

Hence, marking as won't fix. Feel free to re-open this issue if you disagree and you cannot find another issue in the queue that tackles a particular option already.