UI Improvements for Workbench Suite of Modules

Very slick. I like.

good work + sub

Looking really good! I especially like the Toolbar integration, lots of possibilities there.

- When I first saw 'Favorites', I thought of 'Bookmarks', not of a series of links to frequent tasks. Perhaps 'Quick links' or something to that effect?
- Something I missed (or overlooked in the pdf) is a way to integrate a menu/form to 'do stuff with content' from the overview modal (publish/unpublish/change workflow states/...). This will come in handy especially once #1137262: Integrate with Views Bulk Operations gets in. Any plans for that?

This is great Carol!
I would like to see the graphics blown up a bit with examples though. It's a bit abstract for me to really envision the way it is. Anyway, might just be me. Your writeup is still an inspiration to making this shit non-nerd compliant.

Best,
J

The Favorite links are too "noisy" I think. I know that you'd like everything accessible in one place, but maybe it's too much. Not sure.

Perhaps it can be balanced with colors. I mean the arrange and delete icons on the left and right side for example should be faded out and should have an almost transparent state until the user hovers over one of them.

Subscribe

Impressive work. Looking forward to seeing how it turns out :)

Sub

I promised to give some feedback so here it goes. I do have some bias given that I was involved in the design of much of the current standards. It is a bit hard to comment on a full PDF in one issue, so let me know if I am missing something.

Toolbar interaction
1) I do not think the ability to toggle the overlay on and off from the toolbar is really something content editors are concerned about. It takes up quite some real estate, and probally is not really a concept that people grasp quickly.
3) I would imagine the whole user part triggers the dropdown.
4) Per user was always the intend, no idea why Drupal 7 ever went for "sets".

Favorites interaction
In general isnt the concept a bit overkill? Why not optimize an actual page dedicated to this, rather than trying to design tiny interactions in this space.

Action items: Writers Dashboard
2) Needs more detailed wireframes, action area's are favorable but it doesnt scale nicely to several content types, or file uploads. How are you intending to tackle this?
4) I am concerened about auto-magic of buttons showing up, ideally these buttons are displayed by default. You repeat this pattern for 5), I would generally try to avoid something like this and move by designs you can do on the actual page.

Content edit from dashboard: Writer
2) Great for trying out this interaction, for Drupal 8 we have been thinking about doing this as well.
5, 7) I wonder whether its not more favorable to have one column for the state an article is in, reviewed, published or else (perhaps even using colors) rather than requring the user to scan across the whole table for states. With some nice filtering and visual design, it should not impact effictiencty.

Content versioning: All users
1) Using checkmark for publishing actions is nice, however isnt it very visually distracting when people dont safe as draft too often - but do make a lot of published revisions?
7) Moving back to history makes sense, however do you create an consistent experience (going back) on all the occasions you create/edit content?

Site configuration Workflow: Admin
I have no idea what this "Configure" page is about, can you go more into detail what kind of functionality lives here. If it is to replace the current configuration page, it is unlikely to scale.

Not sure what to call this, so I'm labeling it a "task."

At Drupalcon's Workbench sprint, we spent some time working through a few different publishing flows/use cases, and we decided to focus specifically on issues of approval, moderation and the like. While we initially thought about how the moderation panel would be built into the Revision History for a node, we realized that, in terms of the actual flow of production, it made more sense to include the moderation elements in the actual node content, which would allow content editors to proofread and take action on a node within the same screen, rather than making them hop around.

The result of our discussions is the following wireframe. The annotations (numbered 1-8) are as follows:

1. Status Message below the node image shows which revision the user is looking at and provides a link to view revision history.
2. Progress Bar: shows current node status, and where in the publishing pipeline the current revision is, along with associated deadlines for each step of the phase. This helps content editors quickly see the publishing workflow, and keep on top of important deadlines (critical for media companies). Suggest setting up as a ul with a distinct class, e.g. "workbench_progress," and setting up some default styles (including an .active class for the current status) which can be overridden in the theme CSS. See http://www.openideo.com/open/web-start-up/inspiration/ for an example of this concept in action.
3. Moderation panel at the bottom of node content: forces the user to give the article one last proofread before hitting "Publish," and keeps user in the context of the node content.
4. List of Approvals: Many media and marketing departments require a series of approvals or "signoffs" prior to publishing; giving a list of the approvals received vs. the ones stil needed gives user an action step, i.e. call/email the folks who still need to give approval, or schedule for publishing.
5. Change status dropdown: Since a document can only have one status, using a Dropdown for options here saves space on the form. Default Options (see Progress Bar): Draft, Needs Review, Ready for Approval, Ready to Publish, Published. Question: if someone chooses "Published," can/should an action be set to publish the node within Drupal?
6. Job Scheduler: Publishing cycles often have specific dates when content is to be published; however, the time the content is reviewed and set to publish could be several days before the actual deadline. Users should have a way of setting the publish date as soon as they mark the node as "Ready to Publish."
7. Publishing Deadlines: This is a repeat of the deadline information in the Progress Bar. By the time the user gets down to the bottom of the node, they may have forgotten the deadlines, so this gives them a quick reference for decision-making. It should be noted that deadline information (for when a node is "due" to have a specific status) is important for several types of publishing schedules; however, it doesn't need to be required.
8. Review Revision History: Gives editor another chance to look at all the revisions of the content. Styled as a button alongside the "Update" and "Cancel" buttons. Question: do we need an option here to just publish the node? Will that cause confusion?

I'm also working on user flows for a few different publishing use cases. I have to organize them a bit today, but I'll publish them separately.

Attached is a user flow for a typical Corporate Marketing use case. The data was collected during the Workbench sprint, using HP's current production flow.

Key Needs:
• Accommodate multiple authors and author types (roles)
• Assign content to specific individual(s)
• Assign specific date/time for review, content moderation and publishing
• Notify assigned users that new content is available for them to process.
• See what someone has changed and why they've made the changes (inline commenting and visible text changes)

Flow:
1. Once the draft is created, it is assigned to the designer, who reviews it for images, design issues, etc. (Status change: Needs Design)
2. Once the draft is updated with images, it is proofread by the editor and returned for second draft. (Status change: needs review) Iteration happens.
3. Once the draft is approved by the editor, it is assigned to both the marketing team and the legal team for review. (Status change: ready for approval) This happens concurrently.
4. Once approvals have been completed and signed off, the article is ready to publish (Status change: Ready to Publish). If new information occurs mid-cycle or approval is not given, the draft is returned to the content author for changes.

Attached is a user flow for a typical Technical/API Documentation use case. The data was also collected from HP's production cycle.

Key Needs:
• Have multiple people "sign off" on content before it gets published.
• See that something has been signed off and who signed off on it (can be just a checkbox), and who needs to sign off on it still
• Set publish date for content once it's been approved to publish
• Mark something as a "rough draft" and have it remain private until user chooses to mark it for review (perhaps two states: "private draft" and "public draft?"

Flow:
1. Developer creates rough draft; this draft is personal to the developer, and only visible to him/her until sent to the technical writer for proofreading.
2. Once the draft is created, it is proofread and edited by the technical writer and returned for second draft.
3. Once the draft has been iterated, it goes to the tech team lead for review, and on to sign off phase. If something changes during writing (for example, a new release), it gets kicked back to the original author. If the draft still needs other work (copy edits, proofreading, etc.) it gets kicked back to the technical writer/editor.
4. When the draft is considered ready for final approval, it gets sent to three people for official signoff: the tech lead, the original author and the site admin.
5. Once the draft is marked ready for publishing, the site admin publishes the node.

These are awesome, thanks for writing (and wiring :) these up.

With the number of people touching the document in these workflows, a in-line content change tracking addition is becoming more important. I am thinking of something in the line of ICE by New York Times.

Dashboard Editor: the "To review" table doesn't need a status field, does it? They should all be in "needs review" status. It would make more sense if it had specific feedback ("needs references").

So, I just realized that this was assigned to me, and I didn't even realize it. I hadn't heard anything about moving forward. Caroltron, do you still need help with this?