Recently, I was asked to work a group of academics who wanted to create a website to showcase their research. I work at a University and we have many constraints when it comes to the web. Because of this we have a bunch of rules and documentation to cover the technical side of things, but we don’t have the same rigour when it comes to the content that will populate that site and of this project, that meant tons of words and images and videos that I don’t know anything about. I don’t know where it is, or who looks after it. That’s what the academics know, and there were a lot of them on this project.
One of the biggest challenges for any website development is getting the content ready to launch. The text, images, media, meta data, alt text, calls to action, micro copy – it’s slippery stuff and can seem to be everywhere and nowhere at the same time.
What do we need? Who has it? When we get hold of is it it appropriate? Who knows enough about the content to be able to edit it? Who has the authority to approve it before we go live?
Keeping track of content is a big enough job for one person, but throw programmers, project managers, designers and clients into the mix and it starts looking so complicated no one is in a hurry to volunteer for that kind of responsibility.
After meeting with the Research team, it became apparent my challenge was to gather content and use that process it to bridge the gap between:
..the researchers knowledge and what they wanted to showcase on the site
..the developers and designers who would build and populate the new website
..the people who would look after the site once it launched
..the site’s intended audience.
It was time to turn to my trusty friend the Page Table.
I’m not pretending that one tool can make this process perfect. In fact, this is a very messy process no matter how you do it; but I am suggesting that a very useful tool in your arsenal may involve a good old fashioned stack of papers with tables of information on them.
Content Kit to the rescue
Page Tables come in all sorts of flavours depending on the need. Generally, they’re templated information corresponding with every page of a website. I have based my page table template on what I knew we needed for every page in our CMS – so yours may differ but the idea is the same. In this case, I rebranded my Page Tables to “Content Kit” to make more sense to the project team and shared it via Google Drive so it was accessible to everyone on the project who needed it.
The Content Kit was a set of pages on Google Drive that ended up looking something like this:
First page: name of the project, website, brief context around what the site was about and why, list of project contributors Second Page: a site map or architecture of the new site including a unique ID for each page
Page Table templates
– one for every page on the site (identified from the site map)
- Page ID
- Subject Matter Expert (SME) – who’s the person who knows this content?
- Approver – who’s the person with the authority to sign off on this content?
- Objective – why is this page part of this website?
- Title – what is the H1 title of this page
- Sub heading – supporting the title of the page
- Description – short blurb to support objective of the page
- Tags/keyword – any meta data required by CMS
- Share/Content reuse – will this content be shared or reused
- Body copy – type in the content or provide a link to where the content can be found e.g.: on a shared drive or file system (best to have a local copy with the Kit)
- Images – information about what image to use and where to find it; include filename, alt and caption text, meta data needed to support file in digital asset manager of the CMS
- Media – information about which media and where it is; include filename, type, alt and caption text, transcript, meta data etc. Call to action – which ties to the objective of the page.
The great thing about keeping this kit on a service like Google Drive is that anyone in the team who can contribute content to the website can work on it in one place. Everyone has better visibility over the scope and progress of the content development and it is a lot easier to see where there are gaps in the content or structure of the site.
- Designers can see and use real content when developing templates
- Programmers can understand what functionality they need to develop to support the content
- Project Managers have a ‘base of operations’ for content gathering
I’ve found that this centralised approach also spreads up the content population and QA phases as most of the questions that arise during the process of completing the Page Tables have already been raised and answered.
It’s a beautiful mess
Describing this process here makes it seem organised and foolproof. Unfortunately, like many things where people are involved, it is neither of those things. It is a heck of a lot better than trying to keep track of content with post it notes, emails, and memory, though, so next time you’re needing to wrangle a group of people to gather content for a project, consider the humble page table. I’ve found it to punch above its weight, especially if brought into the process early.