Think Content→

Think Content-first When Designing for a Component-based Web Site

 by Beth Bader

Components are not a new idea to content strategists. The idea of a component-based authoring system is central to building a “write-once, use many times” content set. These systems are usually XML-based and can author across mediums, both print and web, for example.

This same re-usable approach is the way major CMS platforms like Adobe CQ, Sitecore — or even open-source platforms like Drupal and Wordpress – function, by building sites with reusable “chunks” of functionality. These design components are then assembled to build a “page.” Like a set of Legos, you can combine these different building blocks to create different pages. Your only limitation is the set of building blocks you start with.

The big win here is flexibility to define pages from multiple combinations of components rather than a limited set of fixed page templates. You can also create the functionality once for a set of sites, but then alter the CSS style to allow for multiple brand sites sharing the platform to reuse the same component set.

A component approach to the site development also allows for the team to test and approve smaller chunks of site functionality throughout the project lifecycle. The approach makes sense on a lot of levels.

The challenge is changing the thought process for us as content strategists, content authors, clients, designers, and information architects who are accustomed to thinking in “pages.”  This is where a content-first approach can save your sanity and your project.

Component-based Design Still Begins with Good Strategy

You need a clear road map for the project that defines goals and success. This doesn’t change whether you are using waterfall or agile, page templates or components.

You still need stakeholder interviews, user personas, a review of site and search analytics, and a thorough content inventory and content audit. The content gap analysis and a keep/kill/modify content exercise should also be in the mix before you begin design.

Understand Your Content to Define the Right Set of Components

The information architect still creates a site map for the top levels of the site. This is still based on working with the content strategist who will organize the deeper levels of content.

Where the work changes is that instead of building around 12 to 15 page templates for a large web effort, then fitting all the site’s content into one of these fixed shells, you now have to define about 30-40 components that all have to work together. Smaller projects require fewer components, of course.

How do you know what makes a component? The answer is in your site content and the content strategy. By looking at across all the content that will be migrating in, you can begin to identify types of content elements needed for the site. What is the best way to present each content element on the site and what would a component need to do to present it effectively? Just like enterprise content strategy, you are looking for the elements that can be repurposed and reused.

Define the Components for the Optimized Content, Not Just the Existing Content

The content audit is key here because this document explains how the content set needs to be optimized. This, plus the gap analysis, focuses your work on the ideal future content state rather than just referencing how the existing content is displayed, which may not be optimal.

For example, a current site page you are keeping may be a long page of only body text. Review the content and identify what the purpose and value of this content is. What are the elements that provide value and how can these be optimized? How does the content compare to your content review checklist?

By reviewing the content like this, your long content page may become five components: hero image and page title, text area with columns and images, author bio, supporting content like a video asset or an infographic, related content links, or an associated call-to-action.

Your long text page is now designed to help the user get more value, read the page more easily, quickly engage with more content or respond to a call-to-action. Because you’ve taken the time to identify what components make for a good user experience against your actual content — and because these building blocks are reused throughout the site — you’re creating a more consistent and valuable site experience that delivers better for both your users and your business goals.

The content strategy work may also define unique or new content items needed; brand stories, interactive experiences, how-to or training modules. These have to be identified as part of the component set as well.

Not every page in your content set will use all of the components. The goal is to define the whole set of components that are needed for all of the content types the site has to display. This is thinking content-first. This requires having the content strategist work closely with the UX resource and the project team throughout the design and development phases.

If you fail to base the component set on the actual content the site needs to display, you are setting the project up for failure before it begins. Designing the site first, then considering the content later may make for a nice looking site, but you won’t be able to use it to deliver the right content.

Pages Still Matter

Throughout the process of identifying the components, you will still need to think in “pages” because your end user still views your site as pages. You’ll need to look at how the components work together (or don’t) on a given page.

Imagine designing a house room-by-room without considering how the entire structure should work. If you design component-by-component, your project, like the house, won’t be structurally sound. Cobbling together components without a larger sense of context and interaction between them creates a chaotic experience. You will need to evaluate the design of the components in pages for the same reason.

To quickly test your component set, “assemble” the components you have identified into quick whiteboard sketches to try and produce the different types of pages the site will need. You can also do this in a list format if you don’t need to think visually.

Take for example the page formula header+text+video+related links=article page. You can use just the list of your components to quickly identify if you have the complete set you need. Do this first, before you prioritize and begin designing the components. This is a quick way to check your component set to see if it supports all of the new site’s content needs.

You may even need to create more polished page-type guides or formulas for how to use the components in order to give your content creators a guide on how to best use the component set for the site content. Page guides may also have to be created if the content is going to be produced in parallel with the site development.

These assets are also useful as an ongoing tool for site maintenance and governance, by documenting each component, it’s style rules, and the how/where/when it should be used in the site as you go, you build a useful guide for training and maintenance.

In Summary 

The transition to component-based CMS platforms is an evolution of the current approach that offers a lot of flexibility, functionality re-use, and efficiencies for a web project. The same best practices, an informed discovery, and a solid content strategy are even more critical. Keys to successful projects focus on a content-first approach:

• Component-based sites support the flexibility to define pages from multiple combinations of components rather than a limited set of fixed page templates.

• All web site projects should be content-first, especially component-based projects.

• To do a content-first approach, your project must include content strategy as a foundation.

• Determine your components not just from the current content, but also from the recommendations from the content strategist.

• The content strategist is a mandatory team member throughout the lifecycle of the project.

• Designing the site first, then considering the content later, results in a site that won’t support the content strategy or the business and user goals.

• Test your component set and your site design by “thinking in pages.”

• All the pieces have to work together as your end user still experiences the site in pages.

• Leverage your component definition work as you go to build documentation and training materials.

Beth Bader is a User Experience Director who works closely with content strategists to design and deliver content-first site experiences.

Migrating Content: Challenges and Opportunities→

I do a lot of content management system migration projects. As the content person on the team, my role is to shepherd the content through the process with the goal of it coming through if not improved, at least not degraded. Often that means arguing against automation. Here’s why.

Migration: It Isn’t Just for Developers

CMS projects are often scoped and staffed as technical projects that can be handled by developers creating automated solutions to move data from one system to another. After all, an enterprise CMS is essentially a database. And so it should be possible to approach it as though it were a database to database migration—map the data fields to one another, do some data normalization, run a script, test and refine the scripts, and you’re done. That’s all well and good if you’re working with highly structured data. Structured data has characteristics that can be programmed against.

But web sites are made up of all kinds of data—some structured, like product data on an e-commerce site; some not, like articles, blog posts, or user-generated content like reviews. Karen McGrane refers to this problem as the war of the “blobs” (unstructured) vs. “chunks” (structured data). 

These incredibly valuable but unstructured blobs of content present a few problems: they’re hard to find in the CMS (think, for example, of an author name that exists only as part of an article), they’re hard to manage, and they’re hard to migrate—particularly in an automated way. These blobs of content are also often the result of years of organic growth of a site, with multiple authors, multiple authoring environments, and no uniformity even within their lack of structure. Theoretically, it should be possible to program against a blob of well-formed HTML, but depending on the all the aforementioned potentialities, that HTML may vary from one article to another even within a similar content set. Perhaps one author is more technically savvy than another and has done a little creative programming to make his or her article look a certain way. Another has used old-style markup or built the entire article as a table. Another has copied and pasted text in from Word and didn't strip out the styles. Writing a script to handle all the possible issues in legacy code and the subsequent cleanup when it doesn't work perfectly can often take as long as it would take to simply recreate the content from scratch, using considerably less expensive resources that your developers.

Even if automated migration was feasible, is it desirable? For one thing, you lose the opportunity to improve the content along the way. You seldom want to migrate a site as-is to as-is, particularly since the reason you’re migrating to begin with is that the old system isn't supporting current needs. And there’s that issue with messy old code to deal with—migrating it without taking advantage of the chance to clean it is like moving into a new house and taking the contents of the old house without doing any organizing or winnowing of your stuff.

Getting Structured

The hot topic in content strategy now is about semantic markup and how to structure content—which has benefits beyond migration, of course. See, for example, Sara Wachter-Boettcher’s book “Content Everywhere” or Cleve Gibbon’s excellent series on content modeling.

As a forward-looking practice, particularly when setting up a new content management system, developing a content model and doing the careful planning of how content needs to be managed for reuse and multi-channel, multi-device publishing, this is unquestionably best practice. But that doesn't address the issue of how we get there from here.

Here, of course, being the legion of legacy websites that are full of unstructured blobs of content desperately in need of review, clean-up, and a strategy for reuse and retention. How do we tackle these metaphorical Augean stables?

Seldom do web teams and content strategists have the resources they need to carefully tend each and every piece of content. And not all of that content may even warrant that type of resource-intensive, high-touch effort. So we need to think about how to be smart and strategic about where to focus. Prior to any migration or cleanup effort, we should be determining the highest value content. Getting to that list may require juggling user needs (determined by metrics and customer feedback) and business needs (content that is critical for conversion or content that has to be retained for legal or regulatory reasons). Some content may be valuable for both user and business reasons but because of its ephemeral nature, such as some types of user-generated content, may not be worth devoting much time to.

Know What You Have to Know What to Do

Any migration project should begin with a content inventory. If you’ve gotten to the point of planning a migration without doing an inventory and audit, stop. Back up and take the time to tackle that all-important step. Before you can make any decisions about what you’re going to migrate and how, you need to know what you have, what format it’s in, how much of it there is. Once you know what you have to work with, the next step is to do a qualitative audit to determine which content, as mentioned above, is worth the effort of migrating to begin with, let alone which should warrants spending time and effort to structure properly.

Once you've determined what you’re migrating and your CMS has been designed to support content modeling (based on your business requirements for management and reuse), what can’t be automated still needs to be migrated. The reality is that that unstructured content will probably have to be done manually. See David Hobbs’ article on what content can be automated and what must be manual. The list for manual migration may be smaller than you think. And even if there is enough structure to enable automation, if the content set is small, it may still be a better investment of time and resources to recreate it manually.

Turning Challenge into Opportunity

If the content audit turned up other issues in your content, such as inconsistent branding or voice or other stylistic issues, take the opportunity to address those in the process of recreating the pages—after all, it’s likely that the most unstructured pages are also the ones most vulnerable to variation, as discussed above. This is why it’s critical that the project was scoped from the beginning to include enough time and resources for the content team. 

Read more on the role of the content strategist in a CMS project.

Putting the C in CMS→

Previously I’ve written about how a content strategist can play many roles in a project. This is never more true than in a content management system (CMS) implementation project.

Although I once worked on a project in which we combined two corporate sites into one and moved the site onto a new content management system in eight  weeks, that was a rare exception (and a small content set).  In my experience, a content management system implementation project—end to end—can take well over a year and even up to two. And in my experience, the content strategist is present and involved from the first day to the final launch. Or should be, anyway.

A lot happens in that span of time and much of what the content strategist does falls outside what you may think of as typical CS tasks. To illustrate my point, here are just some of the activities that I led or participated in on a recent CMS project: stakeholder interviews, organizational change management, communications planning, content standards development, training, documentation, typical content strategy activities such as content inventory and audit, template and component inventory, tool inventory and audit, content source inventory, content flow diagrams (current and future state), template design, workflow design and implementation, governance strategies for content (including digital asset management), user roles and permissions in the CMS, auto-migration analysis, manual page build, content tagging, URL rewrite strategy, QA, UAT.

If you are part of or are planning a CMS implementation project, advocate for the inclusion of a content strategist to ensure that the content requirements and user needs—both internal stakeholders and external users—are reflected in the project scoping, design, and implementation decisions.

Read more about the content strategy role in a CMS project.