- All organizations should focus on easy, day-to-day publishing.
- Publishing should be streamlined for common tasks (and not for unusual situations).
- Easy publishing should always be a priority, on an ongoing basis and with big redesigns.
Fundamentally we need to have strong, end-to-end publishing. This should be highly prioritized in any implementation, and also for ongoing improvements.
What is easy, day-to-day publishing?
Easy, day-to-day publishing is:
- Streamlined publishing of...
- the content your organization most frequently needs to publish...
- in a way that makes it easy to publish at high quality.
To accomplish this we need to:
- Reduce steps in the publishing process
- Reduce cognitive load
- Make it easy for the publisher to publish high quality content
- Focus on the day-to-day publishing rather than the obscure power user cases
Selling the importance of improving publishing
Part of our problem is that publishing difficulties can be somewhat invisible to everyone not affected. After all, the publishing process is a behind-the-scenes problem. A good approach to convince teams of the need to improve publishing is to emphasize how this ends up affecting the site itself. In other words, sell:
- Better consistency
- Better quality
- More frequent publishing
- Ability to better optimize
If you do high volume publishing, then a key selling point will be:
- Staff spend less time publishing.
This is difficult but achievable
We have two key times to improve the publishing process:
- During big change. If you are considering replacing your CMS, then the publishing process should be front and center. But seeing how easy it is to publish default content types in the CMS isn't very useful, unless they meet your needs. You need to look at how your common content would be published. For instance, if you have a news site then you need to see how easily and quickly you can publish a news story. Then of course during execution you need to keep a focus on this.
- During ongoing change. Whenever someone asks for a change on the front end is a good time to talk about the publishing process. Basically, you want to always be asking "how will people publish the content to make this type of change in the future, not just now?"
The basic steps of content publishing
Obviously the steps need to be developed that are specific to your organization's needs — as a starter:
- Start from a blank slate (the content publisher isn’t already logged into the CMS).
- Content publisher logs into the CMS.
- Content publisher initiates publishing a new piece of content, preferably indicating the content type (product update, webinar, research report, etc) — not file type (PDF, Excel file, image, movie, etc) or some technical type of how your CMS will render the content. The way the content publisher thinks about the content, not how the CMS forces the publisher to think about it.
- Content publisher enters information to publish content.
- Content publisher previews, preferably across multiple representative device screen sizes, what the entire page / other common representations
- Content publisher either publishes the content or submits to workflow (in the case of workflow then it should flow through all approvals leading to publish)
- Content appears
Is your content publishing streamlined?
The publisher is only presented with a form for the information they need to enter (no extraneous or duplicative fields)
Requires a minimum of formatting, especially any HTML (like explicitly applying certain classes)
Not allow any formatting that will be stripped out anyway or that is not desirable
Be as natural a way of entering each field (dates should be entered as dates with perhaps a calendar option for example, references to other content should be managed, images should allow whatever processes are routine, taxonomy fields should be constrained)
Should streamline day-to-day publishing and not edge (or gee-whiz) cases
If assets need to be added to the page, the assets can be managed as part of the flow (rather than breaking the flow)
There often does need to be an education process with content publishers to think in terms of structured content types rather than pages, and sometimes it makes sense to continue with a very page-based approach. But nonetheless there is a logical way of talking about content (people don’t walk down the hallway talking about creating a static web page but about publishing a press release).
The most concrete measure is how long it takes to publish, from end-to-end (all the steps listed above), a piece of common content. When considering different tools and implementation teams this could be a core part of your selection process. Other measures of success are softer to measure but equally important: mental burden on the content publisher and how well the system steers the publisher toward high quality publishing.
The amount of effort to expend on implementing this use case is mitigated by two factors: the number of publishers (the smaller the number, the less urgent this is) and the frequency of publishing (the less frequent, the less urgent this use case is.