Content Staging Wireframes

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Attached are wireframes for the Content Staging Initiative. Be sure to see the definitions for information about the different areas.

Workflow Admin


Rather then creating a new workflow solution, we decided to provide rules to integrate any workflow solution (See Here). The workflow administration wireframes are now just a recommend structure for any new solution.


Collection Admin


The collection admin screens are used to create and administer the collection. These are for site Builders

Collection Content Admin


This is a possible mockup to see all of the changes that are attached to a collection. The main column of the screen represents the "preview" of a single node. The "regions" on the page could represent theme regions or panel regions. Try not to get stuck on the details of this page. It's one possible view.

The right sidebar contains some of the options for the collection. The Home page is currently being viewed. There are also blocks associated to this collection.

Bulk Revision Collection


This page is similar to the node content screen except it's by revisions. The "Status" column would respect the workflow solution that is currently in use. This screen gives the ability to filter by collections or workflow status, then perform bulk operations on the revisions.

Content Authoring

Content Edit


The content edit screens show a possible UI for scheduling revision transitions, adding a revision to a collection and transitioning the revision.

Review Preview


When a revision is being reviewed, the site is in review mode. Here you can view the revision in context of what it will look like with the rest of the page. You can transition the revision from this screen.

Content Moderation Tab


This is a possible content moderation tab for the node. It borrows heavily from Workbench Moderation.

Site Preview


The Site Preview mode is activated from the Site Preview Form. This form is populated by the Site Preview Conditions. When the site preview mode is active, there will be a toolbar on the screen informing the user of the state of the site.

Collection_admin.pdf335.44 KB
Content_edit.pdf528.26 KB
Content_Moderation_tab.pdf345.66 KB
Revision_content_admin.pdf178.49 KB
Revision_Preview.pdf748.6 KB
Site_Preview.pdf831.71 KB
Workflow_admin.pdf1.71 MB
collection-edit.jpg222.52 KB


I reviewed the PDF and have

moshe weitzman's picture

I reviewed the PDF and have some quick questions/comments. Feedback from more folks is most appreciated.

  1. I think I get it but want to be sure. Content changes are saved to the entities immediately as revisions. The only reason these revisions are not immediately visible is that workflow states manipulate entity loading so that older revisions are shown instead of latest? Is it performant for Field APi to consult old revisions on standard page requests?
  2. Conditional actions look like Rules module integration to me. We need to expose transitions to Rules events and expose workflow states as Rules actions (My Rules terminology is weak - sorry)
  3. Workflow configuration should definately be exportable. Not sure if collection info should be as well.
  4. Idea for Preview - integrate masquerade functionality so you can be a different user as well
  5. I keep wanting to use the term transition instead of transaction. Perhaps there is a reason you chose transaction? To me, transition describes moving between states better.

Regarding your first point, Moshe

jpklein's picture

I don't know what direction indytechcook intends to take (or how it is currently done in the Workflow/Workbench Moderation modules), but Revisioning takes advantage of the fact that the node table's vid value indicates a current revision that will be used during standard page requests.

So when new revisions are created, it hooks into the entity-save routine to create new rows in the node- & field-revision tables with the latest vid, but it ensures that the vid in the node table doesn't change unless the state into which it is transitioning alters the current status (e.g. when publishing).

@jpklein, The actually

indytechcook's picture


The actually modules we are going to integrate with have not been selected. State Flow, ERS and Workbench all resave the active revision to be the current revision.

We are currently looking at integrating State Machine with Revisioning as a possible strong solution but we don't want to have to force a certain module if we don't have to.

Thanks for your input!

Thanks for the review

indytechcook's picture

Thanks for the review moshe.

  1. That's correct. That's how State Flow, Revisioning, ERS and Workbench moderation all work.
  2. Conditional actions are going to be in phase 2. Phase 1 will just be actions. We are not looking to reinvent the wheel so the idea is to create more of a framework and integrate existing modules.
  3. Great idea.
  4. THe preview system will be plugable. We also have ideas for device, location and mulit lingual integration.
  5. I meant to use transition. I'll update it.

Wireframes have been updated

indytechcook's picture

Wireframes have been updated to reflect the transition name instead of transaction.

A couple more thoughts

jpklein's picture
  1. Where is the interaction between Collections and States (page 1)?

    If I'm not able to push all my content live the moment that Gingrich clinches the primary, what's the payoff for all the extra time I took to tag it in the first place? As an Editor, I want one interface to push my collection live now, instead of having to send off 3 people to hit publish simultaneously. (We may laugh, but I've seen it happen.)

    I realize this may cause difficulties when collections contain several entities, each having a different set of States. This might be resolved by assigning workflows to each bundle instance (node) instead of making them a property of the bundle (nodetype). So the Workflow Assignments on page 4 would become the Default Workflow Assignment for new Blocks/Nodes/etc. until it is overridden by a collection's workflow.

  2. I'm confused about Phases/Stages (page 10).

    As they're defined, Phases seem to confound the notion of a node's Status (published or draft) with Transitions and Actions. After all, updating a piece of content is functionally equivalent to transitioning from one state back to the same state. And publishing a node is the same as saying: "Set the value of the object's status in the node table to 1 when I enter the Published state".

    So, the Phases "Draft", "Published", and "Archived" are really just states defined by different chains of the following Actions (where "Current" == the revision whose vid appears in the Node table):

    • Update Current from contents of form
    • Update active revision from contents of form
    • Create new revision from contents of form
    • Assign active revision to Current
    • Assign latest revision to Current
    • Set Current to Published
    • Set Current to Unpublished

    Using just these - and, perhaps, a Trigger activated when the node's Current revision changes - we could recreate Drupal's native states with some defaults in this module (ala Views' greyed-out version of "/node").

    And for "In Review" and "Approved" - which we could also suggest by default - we would just need to add a Role based on the user's relationship to the piece of content (e.g: "creator") and set Permissions to restrict access to certain Transitions (like "Update").

    It would take some work to find the correct way of tapping into the core entity-operation hooks to decouple these primitive Actions from Drupal's core routines - I'm thinking along the lines of a reset.css for Drupal node operations - but once we've done so, and placed them in the right contextual framework, the flexibility afforded to site builders would be tremendous.

@jpklen One your first

indytechcook's picture

@jpklen One your first point, one screen that isn't included is the content admin screen for managing collections based upon revisions. We are planning a revision based administration UI similar to /admin/content where it would have operations and filters compatible with entity revisions.

You would be able to select all content in collection xyz and publish it using a bulk operations. You would also be able to use this move several node revision between states (fire transitions).

We are looking over other options for content administration. Thanks for the careful notice.

I need a little more time to think through the rest of your post. I'll comment again later. Phases are basically a more predictable state. Useful for coding. For example, you always know that the state "published" will have a published revision no matter what else is going on. I'll add more detail later.

User experience

tkoleary's picture

Hi Neil,

I have looked over the wireframes and talked a little about this with Moshe and Jeff Noyes here at Acquia. My concern is that from a user experience perspective it may be a little early to go to wireframes at this point.

I see that you are doing a lot of work trying to define the architecture of workflow but it all seems to be coming from the direction of integration with existing modules which, to me, seems like more like implementation than design.

To suggest a slightly different direction, the agile approach that we use starts with creating a set of user-centric stories eg:

-As a content editor I need to be able to organize sets of blocks and nodes and queue them for publication on a specific date.

-As a content creator I need to flag my content so that my editor knows that it is ready to review.

Then we prioritize the stories and begin to wireframe the ideal experience for the tasks the user needs to perform. Once that experience there then we look at the engineering dependencies and adjust the design where it's necessary.

I strongly feel that this approach would yield wireframes quite different from what you have now. A really awesome example of the type of UI that I think we should aim at is one Moshe just shared with me: Obviously the use case is different but there are a wealth of parallels that we could incorporate here.

Just one other thing that I wanted to mention is that, in the layouts initiative we are working on the concept of a "page layout" which incorporated concepts from panels, context and display suite. It is worth considering whether we should tackle moving these page layouts through workflow as well.

User experience

tkoleary's picture

Also just to clarify, the above are just my own opinions not necessarily those of Moshe, Jeff or Acquia. :)

The droid your looking for?

jpklein's picture

tkoleary -

I believe these wireframes were created as a response to the user stories compiled by chrisstrahl and webchick.

That said, since it has been a few months since their initial creation, it would be interesting to get your take.

I agree with tkoleary, it

Bojhan's picture

I agree with tkoleary, it looks like we should focus on discussing the concepts supported by the user stories and lay out a strategy. Before we jump into the process of making interface elements (the ones proposed, should merely be there to make the discussion more tangible).

I do not really get the role of Collections, it seems like a fairly abstract concept for content authors to grasp. Although I assume its there for bulk publishing of information, it seems one can achieve that in many other ways too (e.g. improvements to the content listing, allowing easy filtering). However I am happy to be wrong on this one, because it does seem promising.

These are the droids

tkoleary's picture

No, I did not see this. These stories are very instructive. I do think, though that Chris and Angie have written these after close consultation with high level people in the LSD group and as a result they feel more like project deliverables than agile user stories.

It's useful to change the syntax of the stories to the commonly used agile form " as a _____ I need to ______. Applying that to some of these stories illustrates the point.

For instance: "The system has no requirement to track revisions to files. Deleted or renamed files (including images) will simply not function when viewing the site history or the site future."

Becomes: As a content administrator I do not need to track revisions to files. I want my deleted or renamed files (including images) to not function when viewing the site history or the site future.


Clearly the user would want this if they could have it but it's not within the scope of the deliverable.

Thanks everyone for the

indytechcook's picture

Thanks everyone for the review so far. It's very exciting!

I'm in the process of updating these documents based upon the feedback here and from the meeting we had in NYC last week.

I'm focusing less on the admin screens and more on the content authoring experience.


indytechcook's picture

I have updated the wireframes and provided more descriptions to around each page. Please review.


Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week