Over time, the goals and needs of a website change and the question of redeveloping or updating comes up. Using real estate as an analogy, the question can present itself as "reno or demo"? Website development and maintenance can often hold parallels to that of housing development and upkeep.
Another question often asked is "how long do websites last"? The answer to that is very subjective. Some factors which determine the shelf life of any given website can include the evolution of users interacting with the site, changes in technology over time and changes in ownership. There are many great resources out there to help understand why websites expire. One in particular that we like was given as a presentation at Twin Cities Drupal and is appropriately titled "How long do websites last?". The fact that it has Drupal context is a bonus.
It turns out, content is actually king!
Let's assume your website needs to be re-imagined in some way. In this case, small updates or tweaks won't suffice. In other words, we're going to demo, not reno. One of the first decisions to be made is the underlying technology that will run the new site. The usual choice is to redevelop using a modern Content Management System. There are a bunch out there, but the two leaders are Wordpress and Drupal. Choosing a system is a conversation in itself and is beyond the scope of this post, but let's assume Drupal has been chosen as the platform.
Having done many site redevelopments in Drupal, we've noticed how much content informs every aspect of the project. It dictates wireframing and design, information architecture, development, administrative workflow and user permissions. Whenever possible, it's invaluable to consider a full content audit on your existing website when moving to a new system. Having a good understanding of the existing content and how it will live on going forward will likely hold the answers to questions you haven't asked yet. We've even baked this into our process upfront on all new Drupal sites given the value it's demonstrated.
Planning the migration - the "then and now"
When moving to a new website, it can be easy to get caught up in how the content is displayed in the old website. This is something we try to avoid while strategizing on how content will live in Drupal. It is certainly important to consider how older content will continue to exist and a big part of the migration strategy involves configuring Drupal to do just that. The other part though, which is often the unasked question, is what the vision is for the content moving forward as well. Taking this opportunity to have foresight into how content should be structured going forward will definitely pay dividends. There are always better ways of doing things and taking advantage of how Drupal can store your content is something worthwhile to explore.
Getting more out of existing processes
Working this into Industrial's process has been interesting. We typically have always done a content audit exercise in the past coupled with a look at the information architecture. The trouble lies in bridging the knowledge gap from client, through UX, on to the development team. Knowing there are key knowledge holders about content, we're working to close that gap to help get clients on board with reviewing their content, and explaining the implications that are present for how their content will live and work for them once it's in Drupal.
Figuring out the "Content types"
“Content types” dictate the structure for how content will live in Drupal. Many content management systems use this term, and it's aptly named. It is just an abstract idea for how any content lives on the web, agnostic of technology. It's a direct reflection of a conversation you might have with a client asking about what the content is that makes up their site.
Similarly, taxonomy comes up in the same way. Drupal and Wordpress (and many other content management systems) have the concept of tagging content using different vocabularies of terms. These two structures work together to emulate real world organization of things, and can be used here too while auditing content with/for a client. Sometimes when trying to explain this process, we hear "Taxonomy? Oh like grade 7 biology!" Yes, that's exactly it. Just like scientific classification, you could imagine your websites content as entities living in separate groupings.
Having things stored in a structured manner makes so many things easier and possible
Often times we come across many familiar patterns when trying to define content types. Many of our clients will have news, events, resources, blog content, and maybe publications. There might be others too that aren't as clearly identifiable, but come up as part of a client roadmap. We take the time to suss out all possible types, then review them with the client to get them each signed off. Here's some points for why content types are important, and why they are the center of your Drupal site's universe:
- We can assign permissions to each content type. This is good for setting up admin workflows. An example being someone that runs events for an organization. Typically events is created as its own type for other reasons but we can take advantage of that here and set it to be the one thing the events person can add/edit. Assuming we assign that event admin a certain role in Drupal, we can then give them access based on their role to only create event content.
- We can assign different sets of fields on each content type. Events for example may warrant a date field, location, website link, etc. whereas a basic page would not have or need those fields. The point here is to provide structure to your content.
- Using the idea of separate fields to hold this extra meta for these different types, we can then wireframe/template out the individual pages to consistently use that information in a nice way, rather than being part of the body content which wouldn't provide a stylized or consistent representation of the content across all pages of that type.
- If we're using an advanced search as part of the project (such as elasticsearch), we can setup filters for each content type on the search page. On an average site, that list might contain news, events, publications, jobs, general content (these are your basic pages), and so on. Also, as mentioned earlier, knowing the information contained within each can help us stylize each result row. If you were to search for "advocacy", you might get a mixture of events, news, and basic pages all having to do with advocacy. It would be helpful to know what type of content each row was before clicking into it. Here's where showing a date, category and other meta can hint to that.
High level thought process. How we begin
An example might be to look at resource content. Many of the sites we work on have a section devoted to resources. Often this content isn't well structured to begin with. There might be some resources that have full pages to represent them, others that link off to PDFs and some as external links. It may also not be obvious to a user where to find all the resources. Given this example, we may set this up as a "Resource" content type in Drupal going forward. It could have its own landing page that lists all resources, perhaps with a filter for category if there is such meta associated with each. There could be fields setup for this content type that represent all the possible information a resource could be made up of. Things like a file upload, external web link, an abstract, a date, etc.
We also come up with a vision going forward for this type of content. Maybe in the new site, resources will have more content and warrant a full page to represent each, rather than a PDF or external link. Having that "then and now" conversation for each of these identifiable types of content is important so we can define the content structure (as best we can). The project can then move forward more smoothly with everything else built around this foundation of content.
Given this clarity, a thought process might be as follows using the above resources type as an example:
- We know there's resource content
- We know that there might be more content for each going forward, so we'll build them out more, giving them their own pages
- Knowing there is going to be a content of type "Resources", we can wireframe a page to represent what that would look like. Are these resources going to be tagged? Should we use those tags to build filters on the resources landing page?
- We also might want to put resource content on the homepage. This could take the form of featured resources that lead to the "all resources" page above.
- When we build the site search, users may want to filter by resources only. Given that, we could structure each result row to show the specific meta inline that we know is there for each resource. Things like a file upload, external link, abstract, date, category, etc. This would provide a better preview when coming across resource content in the search, rather than having each result blend into one another with just title and body.
Where taxonomy fits within content types
As mentioned earlier, content types can have their own fields. These would typically take the form of text or file related data that would live as part of that page. There is another kind of field though that can reference data living elsewhere in the system. Taxonomy is setup like this. You basically would have a bunch of related terms called a vocabulary. Then you would create a new field to reference that vocabulary of terms. An example would be if you had a blog content type and wanted a repository of terms to tag each post with. You'd likely then create a vocabulary called "blog terms" and start creating the terms that would be used for blog posts. Then when you are creating your blog posts, you'd reference in those terms.
Taxonomy does take a backseat to the rest of the content on a page, but can still be useful, typically in search and filtering applications. Using a blog again as an example, you often times find that you can click on tags and they bring you to a listing page of all other similarly tagged articles. Another example would be for a search page. We mentioned earlier that a search could have a filter for content types. Well there could be one for taxonomy terms as well. Lastly, we sometimes use tags to create "related content" sidebar boxes. An example of this would be if you were looking at a page that had certain tags assigned to it. You could setup a listing in the sidebar that would list a few other posts that also share those same tags.
Fields for content types
Choosing the content types is half the battle. Once those are decided though, we can go back through each and start to identify what makes up the content for each one. These don't need to be locked down and can change. Content types can change too but not as easily given there's much more built up around them. This is partly why having this discussion is better earlier on, when your're just changing things on paper/whiteboard/google sheets rather than after they've been setup in Drupal.
Usually this process of deciding fields comes from looking at existing content first. When looking at the below paragraph for example, we can decide that it could probably use 4 separate fields to make up this one entity, assuming that there's always going to be a date, title, presenter and body.
Once that content starts being filled out separately in Drupal, rather than as one monolithic block of content, we can start to see the following benefits:
- Content can be laid out consistently given this structured setup
- We can now search on field data separately if needed. Maybe you wanted to find all blog posts of a certain date range. Now that it's in its own field, that can be called on directly.
- It makes content entry easier. If it has been decided that a blog post should have a featured image, date, tags, and author, an editor can go in and easily fill in the pieces knowing where they need to go.
- If certain data is required, having it's own field can be helpful by setting a required flag on it. Then if someone fills out a blog post, they wouldn't be able to submit it without a date for example if that field was set to required.
- We can use fields to not only hold the content itself, but use fields to control where it should show up. A common thing we do is add a "featured" checkbox. This can be useful for transient content like news or events. Then we can build out feeds of this content on to the homepage for example, only pulling the ones that have been marked as featured.
In writing this post, one shining takeaway that presented itself over and over is that this all has to do with structure. Having things stored in a structured manner makes so many things easier and possible. Some of the things mentioned were permissions for editing and viewability, searchability, disambiguation through the creation of listing pages, consistent styling and layout.
You can think of the alternative, as most clients have been there in the past. This idea of having the equivalent of a word doc making up the structure of a webpage where everything is just either not in a database or setup within a body field in one big clump. This setup basically strips all the power out of your content, making almost all of the above mentioned less possible.
One other thing not mentioned here is that if the day came for your content to move systems, having structure in place can make migration much easier. The people involved in performing the migration the next time will have clarity built right in given the structured nature of the content.