Anytime you redesign your website or migrate to a new content management system (CMS), you get an opportunity to rethink your content and its organization for the new site. What can you improve? How can you increase the return on investment?
Many people use content modeling to help them create this new structure. And, since you already have a website, it’s tempting to start out by mapping your existing sitemap to your new content model (and auditing your content, of course). But this approach has some serious limitations.
Using your sitemap as a starting point for a content model will capture what content you have right now in its current format. This is fine if all you want to do is inventory what you have.
However, it’s not so good for making your content future-friendly so it can be used across multiple channels and presentations. This is because your content ends up being mapped to how it appears on a webpage, rather than what concept the content represents.
When you try to organize these content types into a new sitemap or menu, the choices are limited to the same options you started with. But what if you want to expand or change how you talk about your offerings? Frustrating, right?
The problem at the heart of all of this is that when you base your content model on what’s on a website, the content types lack meaning outside of the website. That can be a problem when your website’s information architecture doesn’t match the mental model visitors bring with them to the site.
This is because sitemaps and content models are not equivalent artifacts.
A sitemap is a hierarchical listing of pages on a single website.
A content model is documentation of an organization’s types of content and their relationships. It represents all the content that your company needs to have to meet the needs of your audience.
How successful you are at meeting these needs—in the short term and long term—depends on whether or not you’re thinking about content before considering how it shows up on a website, or any other digital product or app.
Turning web content into entities that can be used as a whole (for example, a webpage) or broken into pieces (as components to create multiple different outputs) will create new opportunities for a longer-lasting website, as well as for more efficient content operations and governance.
Instead of starting with a spreadsheet inventory of web content, start by thinking about all the types of content your company has. Put those on a board. These are your potential content types.
Go ahead and start with a web content inventory, if that feels like an easy place to start. But instead of recreating the sitemap, think about what the webpages represent. Some of the pages will be content types. Looking at our sitemap-based model above, we can discern the difference.
These are entities that can stand alone, whether or not they appear on a website.
These are collections of a content type pulled together as a webpage. Break them into entities, or content types, instead. (Content types in bold.)
These are part of other content types.
Now we get a content model that could look like this.
To get a more complete overview of your content, go hunting for content types in other places: This will help you think about what you could potentially offer in the future, rather than just what you have now.
Stakeholder interviews. Talk to others in the organization to find out what kinds of content they share with their primary audiences. Content could be hiding in plain sight!
Competitors’ or partners’ websites and applications. What are they offering that you could also offer?
User or audience research.What do you hear people asking for?
Remember when we talked about future-proofing for content reuse? Using the entity-based content model, we could create multiple different sitemaps or menus—for example, for a marketing website and a client portal—while using the same set of content.
Think of the content types as cards that can be sorted and categorized. The menu for the marketing website could be sorted like this:
While the client portal could have this menu, using the same set of content types:
Each page on the site draws from the list of content types.
You’ll notice that the content types in the model get you about 80%-90% of the way to each menu. For context and usability, you’ll need some webpages that provide wayfinding and information that is only applicable to that property.
Sitemaps and content models both provide a representation of content. They feed off each other, but have different purposes.
You can learn more about how to think about content modeling, lay the groundwork for a project, and create a content model. There's even a workbook for a Sanity Studio build!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。