We are a Drupal shop and as such we deliver ready-to-use websites to our customers. We always tweak interfaces to deliver better user interface alongside our projects.
I'm following D7UX discussions and looking forward better and cooler and I've noticed that in the moment there's a focus on content type forms and other administration issues. Of course this is very important to Drupal World Domination, but when it comes to Drupal usability, I'm far more concerned with the underprivileged (i.e., without too much perms) content editor. How do we make a great node editing interface?
Here are my two cents on the "publishing options".
As we of today, Publish options comprises three checkboxes: Publish, Promote to frontpage, Stick at top of lists. They are actually loosely related.
It is quite common for CMSs to have a "publish" boolean in all its content. So has Drupal. But... why do we have to show to our users such a booleanish checkbox?
I like Wordpress approach better. There's a big blue Publish button. If we save (or better, "Save as draft"), we're just saving it, as an unpublished node for later editing. If we press the "Publish" button, we know for sure it's going live.
It is easier for our users to understand. "Being published" is not a characteristic of a node, like a taxonomy tag or an address. It's an action we inflict on it. "Publish it!", said the editor, not "make it with get the 'published' status".
The approach described above for publish would help a lot on drafts. Most people need some time to write a whole text. In Drupal, when we need to have a draft, we unmark the "Publish" checkbox and press "Save". But it is just too uninvinting for "drafters". If Drupal is uninvinting people to write drafts, it's not invinting people to use it as a text editor at all.
A simple change from a publish checkbox to a publish button would be very benefical and would allow people to easily save drafts.
But, what if we push it a little further? I'd love to see an automatic draft saving in core, just like - well - Wordpress. There are some issues, though: validation of mandatory fields. There are lots of fields that must be filed before puting a node on air: title, one or two obligatory taxonomy vocabularies. All of them waiting for completion, before getting the node on air. Imagine a complex node type with thirty CCK fields. How could we save a draft of it? Moreover, there always are pathauto URLs, triggered actions, etc., that depend upon node creation.
Draft Module circumvents this issue by saving the form, not the node. It works, but it is not ideal. It's too confusing to have two different entities: drafts and unpublished nodes. How could we tell them apart without confusing the heck out of our users with tables and internal Drupal structure? Perhaps we could relax validation on draft (unpublished node) saving, and enforce them on node publishing. But is still a topic open for discussion.
Promote and Sticky
In today's world of Views and Panels and custom ways to exhibit content in fronpage, these two options are quite meaningless for most sites we build. Consequence? We must get rid of them, in some node types, to avoid confusion by our users. Or give new meaning for those booleans in other node types. Not nice.
I propose that we allow admins to choose, for each node type, whether that node type is "promotable" or "styckiable". For instance, blog posts would be promotable, but pages would not -- even to overprivilege user!.
Moreover, in the same way as "publish" described above, we could convert those two options into buttons. "Promote to front page!" and "Make it sticky!". It would be very interesting to see implement in the edit on page form proposed by Mark & Leisa.
As we speak, our interface guy, Danillo is implementing these features in a module in Drupal 6 and we'll port it as one or more patches to Drupal 7. Stay tunned.