IA Summit 2015 Main Conference Talk
Topic(s): content modeling
With the rise of responsive design, a content model and a CMS are necessities for any content-rich web presence. Once you’ve designed the front-end user experience, it’s important to consider the content structure that will support your design. Content models define:
- the underlying structure of each type of content
- the user experience for content authors and editors within the CMS
Luckily, designing a content model is a natural extension of IA for a front-end user experience. In this talk, we’ll get into the details of HOW to content model. We’ll dissect the content model for a single content type for a nonprofit website. The goals for this content model were:
- to be adaptive and portable for any device or context
- to contain a lot of content, yet display it in a simple way
- a successful user experience for administrators creating and editing the content
- a delightful user experience for end users of the content
In content modeling, there are often multiple approaches you could take so I’ll also cover the alternate models we explored and describe the process that led us to our end result.
- Define a content model
- Evaluate a content item and create a content model based on that item
- Learn best practices for adaptive content models
About the speaker(s)
Lacey Kruger, principal information architect for Blackbaud, works with nonprofit clients to design online properties that work. In her 9+ years at Blackbaud, she has developed a deep understanding of nonprofit web presences and the technology powering them.
Lacey’s article titled “Designing Nonprofit Experiences: Building a UX Toolkit” was published in User Experience magazine. She also co-authored a whitepaper titled “A Guide to the Mobile Web: Best Practices for Nonprofits” and has worked with many nonprofit organizations including Juvenile Diabetes Research Foundation, Susan G. Komen for the Cure, Project on Government Oversight and Central Park Conservancy.
Lacey Kruger: Welcome, everyone, to the Anatomy of a Content Model. I am Lacey. Today, in the next 20 minutes, you are going to learn how to create content models.
Let’s start just by defining a content model. A content model is, for the purposes of this talk, a document defining the structure of each content type and the user experience for content authors and editors within a CMS or content management system.
Why is this important? It’s the backend technical side of the website, which a lot of times we as designers don’t think a ton about. It’s really important because we’ve all had the experience in our lifetime as designers where we’ve designed a beautiful website, we’ve launched it, and three or six months later we go to the website and it looks a little bit more like this.
This is a problem with the structure of the content. You can really minimize the risk of this happening, of a client mucking up your website, through the process of content modeling and by integrating it into your design process.
This is another reason it’s important to content model. This is a WYSIWYG editor, which we all probably know. This is a great tool to allow non-technical website administrators to build web pages, but the challenge with this tool is that it’s focused on a web page. It’s focused on a desktop experience, especially when you’ve got the WYSIWYG to control the entire page.
When a person puts content into a WYSIWYG like this, all of that information resides in a single field. In the data side of it, we can’t really manipulate it much, because it just all is clamored into one field.
With content modeling, we change from this one field approach by splitting this into multiple chunks. We have more control over how these chunks display in different channels and different devices. We can hide images. We can move images around. We can hide and show different pieces of information. The content modeling really allows us to structure the content and have more design control.
The case studies. This is the anatomy of a content model. We’re going to look at an in-depth content model, probably the most complex one I’ve ever created, and pick it apart today.
Just a little bit of background on the project. This is a website redesign for the National Military Family Association. They are a non-profit organization that provides resources for military families. They provide healthcare information. They provide spouse employment information. They provide childcare and camps for children, so all sorts of great resources for military families.
We approach this redesign, and a few key things about the project to keep in mind. We’re moving them to a brand new CMS or content management system. We had a blank slate to start from, which was really nice. We were moving them from a non-responsive design to a responsive design.
They had to really rethink their content, and they rewrote almost all of it. The client was responsible for developing the site map. Some of you in the room might think that is a bad idea and you’d be right.
Lacey: I will show you a little bit later in the presentation why that ended up being a problem.
Looking at the design. We went through. We started the project with stakeholder interviews, did some user research. We got the site map from the client, and then we delivered wireframes. Ultimately, the design for the single page we’re looking at today came out looking like this.
This is a deeper content page for their website. A few things to note about the design. We’ve got the tabs that go across here. Under each tab is a series of sections that hold different pieces of content. Those sections have varying layouts, so they all look a little bit different. Not all of them, they have a few different layout choices.
This is the top half of the page and then this is the bottom half of the page, just so you can get a sense of how the layouts tend to vary. Even during the wire framing process, I was thinking ahead about the content model.
This morning, we heard about systems thinking. I was thinking about the larger system and that’s very important with content modeling that you’re thinking ahead about how this content is going to be arranged.
I was thinking these sections could get really unwieldy. If we’ve got 10 different layouts, it could be really hard to control the content. What I wanted to avoid was having each section be an open WYSIWYG, so that we would have that problem like I showed you earlier. All that would be in one field, and I couldn’t control where the image displays and so forth.
I wanted to create discrete pieces of content for each section, so I limited the number of options that the client would have for those section layouts. That’s just thinking ahead about it.
Moving into the proposed solutions we thought about. We had the design. I sat down with the web developer and said, “OK, this is the most complex design I’ve ever looked at. So, let’s think about how we’re going to content model this for our CMS.”
The first solution that she came up with was a three content type approach. The grandparent content type would be the healthcare page, the entire page. The parent content type would be each tab. Then the child content type would be each section. You would have a different content item for each of those sections.
That was the one solution she proposed. The other solution is where the parent is the healthcare page, then the child is the content within each tab. This is a two content type approach.
An eye chart slide here, but these were the pros and cons we presented to the client on which approach we were going to take. The grandparent-parent-child was ideal in the developer’s mind, because the authoring form would be simpler because you’re only authoring one section at a time, and that you’d have more flexibility within each section.
That’s a little bit specific to our CMS. I’ll share a little more about that later.
The big con to this, and why we decided not to go this route, was that it was going to result in a lot of content items to maintain. If you went in to edit section three of the tab on the healthcare page, you’d have to navigate to the healthcare folder, and then to the Tricare folder, and then to section three. There’s just a lot of individual content items to maintain, and the client really hated that idea.
We ended up going with the two content type approach, where each tab is a single content item. There’s fewer content items to manage, but the authoring forms are a lot longer and more complex. The authoring forms can take a little bit of time to load, too, is one of the reason the developer was going for option one.
Ultimately, we landed on option two, talked through that with the client, and that’s what we built. Let’s look a little bit closer at the content model.
The first thing you want to do when you’re building a content model is to take your design and extract all the different metadata that you’ll want to store in discrete fields. For this specific design, we had the parent metadata, the title, and the description. That intro text will belong to the parent content type, because it’s consistent across each tab.
The child titles reside within the tabs, so it was important to convey that to the client. They can’t have a really long title for anything that’s going to show in a tab. Then the sections each have their own pieces of metadata. They have a title. They have possibly several sections of text within that section, and then perhaps an image or maybe four.
That’s the beginning process of developing the content model. You also have to keep in mind some of the backend data that you want to support the content, so categorization to relate this piece of content to other pages. Then things like promos that you want to show or hide, depending on this section or page of the page of the website.
These are some screenshots from my content model. This is a document where I document the whole content model. This document is used by the web developer to build the CMS. It’s also used to vet the requirements with the client.
We sit down with the client and go through this in excruciating detail before we build it. This is their point of approval as well. We do this for every content type on the site. This is just to closer glimpse at the single content type, which is actually the child content type I was talking about earlier.
We start by defining the content type and writing a little description of it. Then we define what we call the single display template for that content type, and that’s the template for a single item of that content type.
For a single section page, we have a variety of different layout choices they can choose. I’ve written the document here, so that the developer can use it to write some conditional codes. If the layout is half with image on the right, I show these fields. If it’s something else, I show these fields. There’s five options the client has to choose layouts.
The most complex of the five options is this small image plus text callouts right here. For this specific layout, the client can have up to four images and up to four textboxes. We had to add all those fields to every section, in case the client wants to use that specific layout choice.
The second thing we defined for each content type is what we call a list display template, which is a list of multiple items of that content type. In this case, it’s the tabs, so it’s the tabs you saw across the page. That’s a list of multiple section content pages, basically.
Then we get into the fields, all the different pieces of metadata for this content type. We define the field name. We define the type of field it is, so what kind of data are you putting in this field? Then this description column is really important, because this is what winds up as the authoring instructions on the form.
We get to design out the whole user experience the authors are having by going through this process. You’ll see in the specific example that I’ve got the title of the item. I have some text here warning them that they have to keep it really short, because it’s going to go in a tab, possibly. Then you’ll see these include items or fields for global design elements that might exist at the bottom of the page.
Then we get into the content sections. There’s five sections and they all have the same fields. You select a layout first, and then you enter the fields.
This deliverable was approved by the client and built. This is a screenshot from the actual authoring form. This is the section content page. You’ll see the authoring instructions are over here below the field name, and then the field types correspond to what I had in the plan.
This is a screenshot from my company’s proprietary CMS. You can do the same process and implement this on a CMS like Drupal. Any CMS that allows you to customize the authoring experience, you can have the say and design the content model, which is really great.
There’s toggle for get involved, donate, the sponsors, the global page elements are at the top. Then we get into the content sections. There’s a layout selector first, then the title, the images, then four text fields. You’ll notice that all the fields are optional. It allows for some flexibility within each layout.
There’s the rest of the four text sections. You’ll see these are WYSIWYGs. A WYSIWYG is OK, but it’s just keeping it to just a chunk of content and not putting a lot of other data in there is what’s key. This is content section two. I won’t show you the rest.
The challenges that we encountered when we worked through this project. The first one was that our rich text fields that I was just showing you have a 4,000 character limit, which is about 500 words. The client run up against that a few times when they were publishing content.
That was one of the reasons the developer suggested the grandparent-parent-child model, because if the section was its own content item, we would not run up against that limit. That was just specific to our system and the client ended up just curating and editing their content to bring it down more concise, which was probably a good idea for their responsive site anyway.
The next challenge we ran into was that they asked us to add two additional sections. They had so much content that they needed more sections on several pages.
Our developer pushed back on this because she was worried that the load time would get unwieldy for them, that it would take too long for that authoring form to load when they had the two extra sections. We just pushed back on that and they were able to work around it by editing their content.
The third challenge we ran into was that they asked for the ability to insert videos, which is not in and of itself a problem, but we just hadn’t planned for that with this specific content model. Looking at this tab here, this is the mission tab, they wanted to have a video, perhaps, in each tab.
The way we worked around this was by modifying the image content type and adding a URL field to it, so that they could add a URL for an image. If the URL starts with YouTube or Vimeo, then it launches that little player. If it’s just a basic URL, it just links like normal behavior. That was a pretty simple workaround.
The next challenge that we had was that they asked us to put tabs within tabs, which was just really scary from a UX perspective, especially because the tabs stick to the top of the page, under this bar.
I just got on a WebEx and demonstrated to them, “If these tabs are stuck to the top of the page, what happens to these tabs down here?” They cringed as well, so they were able to edit their content again to get around that challenge.
Then the last challenge, this was the result of them providing their site maps. They didn’t know that they were going to need eight tabs on a page and we had agreed to a limit of five tabs, and they had been diehard that that was enough. Sure enough, they end up with eight tabs.
We just designed a discrete page for this with two rows of tabs, which is showing as three here. Not ideal, but this is a resources page, so it works for that one use case. We were able to get around that.
The client is really happy, which is great. They’ve been live for a few months and I got a quick quote from them. “The feedback from our staff, volunteers and users has been great. It definitely was a learning curve the first week, but overall it has been a major improvement to the organization of our content.”
The client is really happy. Again, I said this was the most complex content model I’ve designed and I’m really glad it’s working out for them.
That’s the end. I think we have four minutes for questions. If anybody has any questions, you can go for it. I also, quickly, have a resources slide at the back if you want more content.
Karen McGrane is an excellent speaker and writer about adaptive content. Then there’s this great book, “Content Everywhere,” about adaptive content as well.
Lacey: Thank you.
Audience Member: I’m curious about naming conventions of all those discrete chunked content pieces. Did you get into that? Is that someone else’s job? Part of the idea is to store them for reuse later. Is that true, or is it all just about the design end of things?
Lacey: Are you talking about naming conventions for the sections, or for each piece of metadata?
Audience Member: For each piece of text in each photo. Did you get into a specific naming conventions, so that later someone could look at all those pieces of content and know what they were, in a database or something?
Lacey: We set up a folder structure for the client. We tried to organize folders for them and train them on how to name images in a way that they’ll be able to find them later.
CMS has a really powerful search tool. We rely on that a lot for them to go back and edit images and such. We usually don’t have enough hours to get into the details of naming conventions, and the clients typically manage it fine with the search tools.
Audience Member: Did you have to go through multiple revisions of this model? Was there an iterative process to make sure it actually fit all of the content and stuff like that?
Lacey: Yes. Our weed web developer vetted this approach with me, and then someone else was assigned to build it. He was new to the company, so as he was building it, he ran into all of these questions about requirements and came back to me. I actually changed the model a little bit.
I have a separate content type for the healthcare page, so I had to add that in later. I was like, “Oh, I didn’t think about how you were going to drop this on to the other page.” It wound up being that separate content type. That was something I discovered through the process, for sure. Then as the client started using it, we had to make a few modifications as well.
Audience Member: I was a little bit confused when you were talking about, the way that it was designed, there was a layout selection, and then you built out the fields based on the layout selection. When you say layout, are you talking about responsive design layout like mobile, tablet, desktop, or is that something else? Intuitively, I was thinking, “Oh, you should just fill out the fields and that should be kind of layout agnostic.”
Lacey: That’s a good question. The layout selections are specifically what drive how the content lays out in each section. One of them is the image on the right and one of them is the images on left. They’re all responsive. The website is responsive.
We have a design that shows how that layout works in responsive. We have a model for that. When the client selects the layout, it’s like, “This is the content I have for this section, what layout will work best for me? Do I need an image? Do I need four images?”
Audience Member: It’s more like a template.
Lacey: It’s more like a template selection. I think we’re at time. I’ll be out in the hallway if anybody else wants to grab me for questions. Thank you so much.