When do these node submit buttons appear and how?

good pick up - actually this is something that Mark & I were talking about yesterday and we plan remove the checkbox 'publishing options' and use the button area for all of this. I'll nudge Mark to send a new screenshot for this.

re: your definitions of the various states, those definitions sound about right to me.

I'd like the "published"-checkbox to (finally) go away. What that means for unpublishing, I don't know. Good question. :-)

I think it might be OK to have unpublish only available from the content admin overview?

I'm also attaching some Wordpress screenshots for competitive analysis. ;-)

Note that they have a 'delete' link. Their states are 'Published', 'Draft' and 'Pending review'.

By the way, I recommend that we proceed with an 'Unpublished' button. I don't think we need to block on this issue as it is fairly easy to undo/change. We can make progress and implement a better solution once we have an elegant solution. As long as we track it as a TODO, I don't think we should be blocked on the number of buttons -- it sounds aesthetic to me.

Note that in the original issue (way back in July 2008), Nick Lewis had defined a series of buttons that seemed to make a fair amount of sense: http://drupal.org/node/282122#comment-921740

He got the "unpublish" button in there but still kept it so that there were never more than 3 buttons showing at once (well, 4 if you count the Delete button, but that button has its own usability issues and will hopefully go away soon...)

There are some workflows that aren't covered by his button scheme, but it seems like it gets the ones that are by far the most important.

Copying his list here for reference, and also modifying it slightly and adding one to it based on Gabor's definitions above:

On a new node:
[Save as Draft][Publish] [Preview]

On a draft node:
[Save as Draft][Publish] [Preview]

On an unpublished node:
[Save changes] [Publish] [Preview]

On a published node:
[Save changes] [Unpublish] [Preview]

From http://drupal.org/node/282122#comment-1636930, written by David: This issue starts with adding the buttons, but there will need to be other visual indicators added too eventually (so that when you are viewing a node you can see a clear indication of whether it is currently published, unpublished, etc - this is already shown in the mockups, as can be seen from the "Status: Draft" text near the top of that page). This obviously makes sense, but it seems like the point here is that if core's "workflow" features are going to move front-and-center like this, the features themselves ought to be more broadly useful. Now at least they are hidden away in a fieldset where it's OK if they suck because they're easy to ignore or remove :)

The challenge, of course, if that we're (still) using Garland instead of a dedicated administration theme. So how do we communicate this using the existing themes? Do we add the 'Status: Draft' somewhere to the existing form?

Two options: (1) we figure out the theme issue first or (2) we try to fit it into Garland.

To solve (1), we need to figure out what to do with non-admin users that can submit content.

Also related to #474168: D7UX and Garland don't match. Could we add a prototyping theme to head?, it seems ...

hey

some thoughts.

here is the current mockup of the Add Content page complete with buttons and no check box
http://www.flickr.com/photos/mboulton/3570130480/sizes/o/in/pool-903403@N22/

our thinking is:

- for a published node the 'Publish' button would change to 'Update' and the 'Save Draft' button would go away.
- auto save can still continue for Published nodes but would only ever become apparently if the user exited a node without 'updating' so that the latest 'draft/autosaved version/revision' (what should I call it?) is different to the current saved version. I'd suggest that there may be a dashboard widget to report these perhaps, but that there should definitely be a user notification if the user opens the node and there is a more recent revision than the currently published node... does that make sense?
- to unpublish the user changes the current status of the page by selecting the link next to 'status' (which in the mockup above is the blue 'Draft' link) - this would present the user with the full range of states available, so they could select 'unpublish' from that list to change state.
- publication date could be changed in the same way (although now that I say it, that would be a duplication, so we might actually remove that and just stick with the 'dates' row in on the meta page.... or perhaps add a 'more dates' link next to the published date)
- we were thinking that the Publication Options is where users could go to make the page sticky or promote to homepage (research to date has shown that useage of these quasi states is in decline and will continue to decline)

how does that all sound? what did I miss? :)

Hm, the Flickr link seems to be taking me to a login screen - can you also attach the file here for reference, as well as for posterity? :)

But from the description it certainly sounds like it makes sense.... So basically the idea is that buttons would be used for the most common workflow transitions (like Draft -> Published), whereas the widget would be used for the less common ones (like Draft -> Unpublished or Published -> Draft), and that way there is no conflict? That seems to make sense, and seems like it would be extensible to more complicated workflows also.

Makes sense to me too. I've also attached the image from Flickr per David's request.

"to unpublish the user changes the current status of the page by selecting the link next to 'status' (which in the mockup above is the blue 'Draft' link) - this would present the user with the full range of states available, so they could select 'unpublish' from that list to change state."

I'm not sure I'd think to click "draft" in "draft last saved 6th May 2009" to unpublish the node. Instead of having the save Draft go away, maybe change that button to unpublish. Or, maybe remove the link from the word "draft" and instead put an edit link next to it that explodes into all options.

As I see this is fixed in D8