Content previews let you see how your content will look before it’s published. CMSs have long offered previews, but preview capabilities are becoming more varied as content management is increasingly decoupled from UI design and channel delivery. Preview functionality can introduce unmanaged complexity to content and design development processes.
Discussions about previews can spark stong opinions.
Are content previews:
Helpful?
Unnecessary?
A crutch used to avoid fixing existing problems?
A source of follow-on problems?
All of the above?
Many people would answer previews are helpful because they personally like seeing previews. Yet whether previews are helpful depends on more than individual preferences. In practice, all of the above can be true.
It may seem paradoxical that a feature like previews can be good and bad. The contradiction exists only if one assumes all users and preview functionality are the same. Users have distinct needs and diverging expectations depending on their role and experience. How previews are used and who is impacted by them can vary widely.
Many people assume previews can solve major problems authors face. Previews are popular because they promise to bring closure to one’s efforts. Authors can see how their content will look just before publishing it. Previews offer tangible evidence of one’s work. They bring a psychic reward.
Yet many factors beyond psychic rewards shape the value of content previews.
What you see while developing content and how you see it can be complicated. Writers are accustomed to word processing applications where they control both the words and their styling. But in enterprise content publishing, many people and systems become involved with wording and presentation. How content appears involves various perspectives.
Content teams should understand the many sides of previews, from the helpful to the problematic. These issues are becoming more important as content becomes uncoupled from templated UI design.
Previews can be helpful
Previews help when they highlight an unanticipated problem with how the content will be rendered when it is published. Consider situations that introduce unanticipated elements. Often, these will be people who are either new to the content team or who interact with the team infrequently. Employees less familiar with the CMS can be encouraged to view the preview to confirm everything is as expected. Such encouragement allows the summer intern, who may not realize the need to add an image to an article, to check the preview to spot a gap.
Remember that previews should never be your first line of defense against quality problems. Unfortunately, that’s often how previews are used: to catch problems that were invisible authors and designers when developing the content or the design.
Previews can be unnecessary
Previews aren’t really necessary when writers create routine content that’s presented the same way each time. Writers shouldn’t need to do a visual check of their writing and won’t feel the need to do so provided their systems are set up properly to support them. They should be able to see and correct issues in their immediate work environment rather than seesaw to a preview. Content should align with the design automatically. It should just work.
In most cases, it’s a red flag if writers must check the visual appearance of their work to determine if they have written things correctly. The visual design should accommodate the information and messages rather than expect them to adapt to the design. Any constraints on available space should be predefined rather than having writers discover in a preview that the design doesn’t permit enough space. Writers shouldn’t be responsible to ensuring the design can display their content properly.
The one notable exception is UX writing, where the context in which discrete text strings appear can sometimes shape how the wording needs to be written. UX writing is unique because the content is highly structured but infrequently written and revised, meaning that writers are less familiar with how the content will display. For less common editorial design patterns, previews help ensure the alignment of text and widgets. However, authors shouldn’t need previews routinely for highly repetitive designs, such as those used in e-commerce.
None of the above is to say a preview shouldn’t be available; only that standard processes shouldn’t rely on checking the preview. If standard content tasks require writers to check the preview, the CMS setup is not adequate.
Previews can be a crutch
Previews are a crutch when writers rely on them to catch routine problems with how the content is rendered. They become a risk management tool and force writers to play the role of risk manager.
Many CMSs have clunky, admin-like interfaces that authors have trouble using. Vendors, after all, win tenders by adding features to address the RFP checklist, and enterprise software is notorious for its bad usability (conferences are devoted to this problem). The authoring UI becomes cluttered with distracting widgets and alerts. Because of all the functionality, vendors use “ghost menus” to keep the interface looking clean, which is important for customer demos. Many features are hidden and thus easy for users to miss, or they’ll pop up and cover over text that users need to read.
The answer to the cluttered UI or the phantom menus is to offer previews. No matter how confusing the experience of defining the content may be within the authoring environment, a preview will provide a pristine view of how the content will look when published. If any problems exist, writers can catch them before publication. If problems keep happening, it becomes the writer’s fault for not checking the preview thoroughly and spotting the issue.
At its worst, vendors promote previews as the solution to problems in the authoring environment. They conclude writers, unlike their uncomplaining admin colleagues, aren’t quite capable enough to use UIs and need to see the visual appearance. They avoid addressing the limitations of the authoring environment, such as:
Why simple tasks take so many clicks
Why the UI is so distracting that it is hard to notice basic writing problems
Why it’s hard to know how long text or what dimensions images should be
Writers deserve a “focus” mode in which secondary functionality is placed in the background while writers do essential writing and editing tasks. But previews don’t offer a focus mode – they take writers away from their core tasks.
Previews can cause follow-on problems
Previews can become a can of worms when authors use them to change things that impact other teams. The preview becomes the editor and sometimes a design tool. Unfortunately, vendors are embracing this trend.
Potential problems compound when the preview is used not simply to check for mistakes but as the basis for deciding writing, which can happen when:
Major revisions happen in previews
Writers rely on previews to change text in UI components
Writers expect previews to guide how to write content appearing in different devices and channels
Writers use previews to change content that appears in multiple renderings
Writers use previews to change the core design substantially and undermine the governance of the user experience
Pushing users to revise content in previews. Many vendors rely on previews to hide usability problems with the findability and navigation of their content inventory. Users complain they have difficulty finding the source content that’s been published and want to navigate to the published page to make edits. Instead of fixing the content inventory, vendors encourage writers to directly edit in the preview.
Editing in a preview can support small corrections and updates. But editing in previews creates a host of problems when used for extensive revisions, or multi-party edits because the authoring interface functionality is bypassed. The practices change the context of the task. Revisions are no longer part of a managed workflow. Previews don’t display field validation or contextual cues about versioning and traceability. It’s hard to see what changes have been made, who has made them, or where assets or text items have come from. Editing in context undermines content governance.
Relying on previews to change text in UI components. Previews become a problem when they don’t map to the underlying content. More vendors are promoting what they call “hybrid” CMSs (a multi-headed hydra) that mix visual UI components with content-only components – confusingly, both are often called “blocks.” Users don’t understand the rendering differences in these different kinds of components. They check the preview because they can’t understand the behavior of blocks within the authoring tool.
When some blocks have special stylings and layouts while others don’t, it’s unsurprising that writers wonder if their writing needs to appear in a specific rendering. Their words become secondary to the layout, and the message becomes less important than how it looks.
Expecting previews to guide how to write content appearing in different devices and channels. A major limitation of previews occurs when they are relied upon to control content appearing in different channels or sites.
In the simplest case, the preview shows how content appears on different devices. It may offer a suggestive approximation of the appearance but won’t necessarily be a faithful rendering of the delivered experience to customers. No one, writers especially, can rely on these previews to check the quality of the designs or how content might need to change to work with the design.
Make no mistake: how content appears in context in various channels matters. But the place to define and check this fit is early in the design process, not on the fly, just before publishing the content. Multi-channel real-time previews can promote a range of bad practices for design operations.
Using previews to change content that appears in multiple renderings. One of the benefits of a decoupled design is that content can appear in multiple renderings. Structured writing interfaces allow authors to plan how content will be used in various channels.
We’ve touched on the limitations of previews of multiple channels already. But consider how multi-channel previews work with in-context editing scenarios. Editing within a preview will focus on a single device or channel and won’t highlight that the content supports multiple scenarios. But any editing of content in one preview will influence the content that appears in different sites or devices. This situation can unleash pandemonium.
When an author edits content in a preview but that content is delivered to multiple channels, the author has no way of knowing how their changes to content will impact the overall design. Authors are separated from the contextual information in the authoring environment about the content’s role in various channels. They can’t see how their changes will impact other channels.
Colleagues may find content that appears in a product or website they support has been changed without warning by another author who was editing the content in a preview of a different rendering, unaware of the knock-on impact. They may be tempted to use the same preview editing functionality to revert to the prior wording. Because editing in previews undermines content governance, staff face an endless cycle of “who moved my cheese” problems.
Using previews to substantially change the core design. Some vendors have extended previews to allow not just the editing of content but also the changing of UI layout and design. The preview becomes a “page builder” where writers can decide the layout and styling themselves.
Unfortunately, this “enhancement“ is another example of “kicking the can” so that purported benefits become someone else’s problem. It represents the triumph of adding features over improving usability.
Writers wrestle control over layout and styling decisions that they dislike. And developers celebrate not having to deal with writers requesting changes. But page building tries to fix problems after the fact. If the design isn’t adequate, why isn’t it getting fixed in the core layout? Why are writers trying to fix design problems?
Previews as page builders can generate many idiosyncratic designs that undermine UX teams. UI designs should be defined in a tool like Figma, incorporated in a design system, and implemented in reusable code libraries available to all. Instead of enabling maturing design systems and promoting design consistency, page builders hurt brand consistency and generate long term technical debt.
Writers may have legitimate concerns about how the layout has been set up and want to change it. Page builders aren’t the solution. Instead, vendors must improve how content structure and UI components interoperate in a genuinely decoupled fashion. Every vendor needs to work on this problem.
Some rules of thumb
Previews won’t fix significant quality problems.
Previews can be useful when the content involves complex visual layouts in certain situations where content is infrequently edited. They are less necessary for loosely structured webpages or frequently repeated structured content.
The desire for previews can indicate that the front-end design needs to be more mature. Many design systems don’t address detailed scenarios; they only cover superficial, generic ones. If content routinely breaks the design, then the design needs refinement.
Previews won’t solve problems that arise when mixing a complex visual design with highly variable content. They will merely highlight them. Both the content model and design system need to become more precisely defined.
Previews are least risky when limited to viewing content and most risky when used to change content.
Preview issues aren’t new, but their role and behavior are changing. WYSIWYG desktop publishing metaphors that web CMS products adopted don’t scale. Don’t assume what seems most familiar is necessarily the most appropriate solution.
– Michael Andrews
The post What’s the value of content previews? appeared first on Story Needle.
