Illustration by

Training the CMS

by
Published in Content Strategy, Workflow & Tools, Writing

Nothing brings content modeling to life like launching a shiny new site: teasers fit neatly without any awkward ellipses, images are cropped perfectly for different screen sizes, related content is wonderfully relevant. The content strategy comes to life, and all is right with the world.

Article Continues Below
Article Continues Below

But for years, my joy was short lived—because it would only take a couple weeks for things to begin to fall apart: teasers would stop teasing, an image would get scaled oddly, and—I won’t lie—I’d even start seeing “click here” links.

“Why are you messing this up?” I’d wonder. The content was perfectly modeled. The CMS was carefully built to reflect that model. I even wrote a detailed training document!

In my mind, I saw authors printing out my instructions and lovingly taping them to the side of their screen. In the real world, they skimmed the document once, then never opened it again. When new staff was hired, no one remembered to tell them a content guide even existed.

The problem? I’d spent months neck-deep in the content model, and knew exactly how important those guidelines were. But the authors didn’t. For most of them, it was their first time breaking content into its component parts and building it for reuse. It’s not surprising they were fumbling their way through the CMS: misusing fields, putting formatting where they shouldn’t, and uploading images that clashed with the design.

Maybe you’re like me: you know what needs to happen in the CMS to create the experience everyone’s bought into on the front end, but you’ve found there’s a big difference between having a plan and actually getting people to execute it in their daily work. The results are frustrating and demoralizing—both for you and for the authors you’re trying to help.

Don’t despair. There’s a better way to get your content guidelines adopted in the real world: put them right where they’re needed, in the CMS itself.

Getting the team together#section2

If you’ve made a content template or page table before, the idea of an instructional content strategy document will sound familiar. Content templates act as a guide to a content model, explaining the purpose of each field and section, including information like intended audience, style reminders, and example copy. The problem is that these guidelines typically live independently of the CMS; the closest they ever come to integration is including a few screenshots of the editing interface.

Content guides are generally owned and created by whoever is in charge of content in a team. But actually gathering the guidelines is a collaborative effort: a designer contributes information about ideal photo caption length, art direction, and image sizing. A developer knows all the different places a particular field will be displayed, which file formats are accepted for upload, and how many blog posts can be promoted to the front page at once. A project owner or manager knows whom the author should contact with attribution questions, which audience a product description should target, and which voice and tone documents are relevant for each content type.

Getting content guidelines into the CMS itself requires connecting all these disciplines, which means it doesn’t fit neatly into most teams’ processes. In this article, I’ll show you how to bring all the pieces together to create guidelines that provide help when an author needs it, and make it easier for them to do their job well. We’ll do this by following three principles.

Good labels and guidelines:

  • provide context, explaining what a field is for and how it will be used;
  • are specific, encouraging accuracy and uniformity while eliminating guesswork; and
  • are positive and helpful, rather than hostile and prohibitive.

Let’s walk through how we can apply these principles to each piece of the CMS, using specific examples and addressing common challenges.

Content types#section3

Before throwing an author into the endless fields of an edit form, we want to give them an introduction to the overall content type: what it is, where and how it will be displayed, and who it’s for.

Let’s say authors used to create new pages for each event, and then remove them (when they remembered!) after the event ended. We’re replacing that with a specific Event content type. To help authors transition, I might include text like:

Events are displayed in the Calendar page and in a block on the homepage, and will be automatically archived after their date has passed. The calendar is mainly used by members who are already familiar with our work and internal terms.

Where and how this works varies by CMS. For example, Drupal has an “Explanation or submission guidelines” field for each content type that displays at the top of every entry’s edit page. WordPress allows you to add meta boxes to edit screens with custom code or plugins like Advanced Custom Fields, which makes the information more accessible than hiding it in the contextual help tab. If you’re not sure how to do this in your CMS, talk to your developers—chances are, they can make it possible once they understand the goal.

Field names#section4

When naming fields:

  • Be specific and descriptive. For example, in an artist profile, you might replace the default of “Title” and “Body” with “Artist Name” and “Biography.” Even when they feel redundant, field names like “Event Name” and “Event Description” help orient the author and remind them which content belongs where.
  • Describe the content in the field, not the format of the field. An image field named “Image” doesn’t tell an author what kind of image. Something like “Featured Photo” is better, and best is a specific description like “Venue or Speaker Photo.”
  • Be consistent. For example, don’t phrase a label as a question (“Open to the public?”) unless you consistently use questions across all your fields and content types.
CMS form using three generic field names: Title, Type, and Body.
Before: Generic field names on a CMS entry form.
CMS form using three specific field names: Artist Name, Preferred Medium, and Full Biography.
After: Specific field names give context to the entry, and help authors avoid mistakes.

Help text and instructions#section5

Where a field name describes what content is, help text describes what it does. The goal is to help authors meet the site’s strategic, format, and style needs, and answer questions like the ones in these four categories:

Messaging and information#section6

  • What’s the underlying message of this copy?
  • What does this content do, in the context of the site? Is the point of this field to inform a user, drive them to action, or provide metadata for the site structure?
  • Are there things this field must include, or shouldn’t include?
  • Should the alt text describe, caption, or explain the function of this image?
  • Who’s the audience? Are they new to our work or familiar with our internal jargon?

Style, voice, and tone#section7

  • What grammatical structure should this text take (e.g., full sentence, sentence fragment, Three. Word. Tagline.)?
  • Should the title be straightforward, or written as clickbait? (Hint: NO.)
  • Should there be ending punctuation?
  • Character count can be enforced by the CMS, but is there an ideal length the author should aim for?
  • Are there style rules, such as acronym or capitalization usage, that are likely to come into play?
  • Are you trying to change authors’ current writing habits? For example, do they need reminders not to write “click here” or reference page location like “the list to the left”?

Technical#section8

  • Which formats are allowed for an image or file upload?
  • Do uploads have a size limitation?
  • Should the filename follow a specific pattern (e.g., OrpingtonPoster-August2014.pdf)?
  • If a field uses HTML, which tags are accepted?
  • For a checkbox or select list, is there an upper or lower limit to the number of selections?

Design and display#section9

  • Does the value of this field change how or where the content is displayed? For example, does a checkbox control whether an article will be pushed to the homepage?
  • Does this field display alongside other fields (and so shouldn’t be duplicative), or appear alone (like teaser text)?
  • Will the CMS scale and resize images automatically, or does the author need to upload multiple versions?
  • Where will this image be displayed? Will different sizes (like thumbnails) show in different places around the site?
  • Are there art-direction requirements for this image? For example, does it need dark negative space in the left for an overlaid headline? Should it show a person looking directly at the camera?
CMS event entry form with specific help text like “Spell out your acronyms!” and “When possible, use place names over street addresses” for each field.
A CMS form with a mix of technical and editorial guidelines helps authors create consistent content entries.

Making every word count#section10

You can’t answer all of those questions at once—no one is going to read three paragraphs of instructions for a single text field. Your goal is to highlight the most valuable—and most often forgotten—information. For example, a company that long-ago settled on PNGs for its product images doesn’t need reminders of appropriate file types. You might remind users to write in second person in a “Subtitle” field, then link off to a full voice and tone document for more guidance.

Whatever you do, use space wisely—if the field label is “Featured Photo,” don’t write “This is where you upload the featured photo.”

Special considerations#section11

Beware the big WYSIWYG#section12

Even the most well-meaning authors can be overwhelmed by a big blank box and a million WYSIWYG buttons, and the results aren’t pretty. Editorial guidelines help remind users what these long text fields should and shouldn’t be used for.

If authors will be doing any formatting, it can be helpful to customize the WYSIWYG and provide explicit styling instructions to keep them on track.

WYSIWYG editor with a very limited selection of formatting buttons, and help text including advice like “Remember that date-specific events should be made into Timeline entries rather than tucked into this field.”
WYSIWYG field with a limited selection of buttons, including editorial and formatting guidelines.

Be wary of endless “DO NOT” instructions. Positive reminders and examples of good content can be just as effective—and feel much friendlier—than prohibitions.

Making lists contextual and clear#section13

Select fields and lists of checkboxes are part of many content types, but they’re used for a variety of different functions: a “Category” field might control where an entry is shown on the site, how it relates to other content, or even which layout template will be used for display. Good instructions provide authors with this context.

Please remember to change your lowercase, underscore-ridden, concatenated, and abbreviated machine names, like “slvrLc_wynd,” to real words, like “Silver-Laced Wyandotte.” Key:label pairs exist so that your authors don’t have to speak database to be successful. Use them.

Ordering your fields#section14

Many CMSes will let you group fields—most commonly in fieldsets or tabs—to help authors make sense of what they’re seeing. In most CMSes, the front-end display order doesn’t need to match the backend form order, so you can organize fields to help the authors do their job without affecting how things look on the live site.

Usually, you’ll want to either group similar content fields together, or arrange fields in the order they’ll be entered.

For example, say that you need multiple versions of a single piece of information, like a short title and a long title. It’s helpful to see these side by side, with reminders about how specifically the versions should differ from one another.

Or, say that your content will be copied from another system, like a manufacturer’s specification or a legacy database. Matching your field order to the content source means that authors won’t have to skip around while creating an entry. Similarly, if your authors always enter the “Event Location” content in between the “Presenter Bio” and “Event Date” fields, the edit form should match that—even if it’s not the order that makes the most sense to you.

Two fieldsets showing fields organized in groups under Homepage slideshow and Open graph metadata.
Fieldsets help make sense of complex CMS entry forms, organizing fields into groups that help authors keep track of different types of content.

Getting specific#section15

The developer in me wants to create a library of reusable generic help snippets, but the best instructions I produce are the ones that are specific to a particular client’s internal organization and processes. Don’t shy away from including information like “Contact Ann Sebright (x8453) for photo attribution information,” or “Check the internal calendar for date conflicts before posting a new event.”

Making it real#section16

Every team’s workflow is different, so I can’t tell you exactly how to integrate the creation of these instructions into your projects. I can give you questions, though, so you can have productive conversations at the right times in your process.

Picking a CMS#section17

If you haven’t selected a CMS yet, consider the following questions when evaluating your options. If the CMS has already been chosen, be aware of the answers so you can adjust your instructions strategy accordingly.

  • What formats of field-level help text does the CMS support: single lines of text, paragraphs, pop-ups, hover text?
  • Can the instructions include HTML? A bit of simple formatting can go a long way toward readability.
  • How hard is it to update the help text? As needs change over time, will adjusting the instructions be a hassle?
  • Can you change custom field labels used in the admin interface without affecting the machine name used in queries and front-end display?

Content modeling#section18

Content strategists, developers, designers, and clients or subject-matter experts often work together to build content models. But it’s important to bring regular authors—not just the project leads, but the people who will actually be creating entries on the site—into the conversation as well, as early as possible.

  • Review content models and field names with authors before they are finalized. Do the field names you’re using make sense to them? Do they understand the relationships between fields, and what that means for connections between pieces of content?
  • Are there places where the new model differs significantly from the authors’ current conception of the content? Larger changes warrant more detailed reminders and help.
  • For fields that are subtly different from one another: what kind of information will authors need to distinguish between them and use them correctly?
  • If you’ve chosen a CMS with a limited ability to include help text, have you simplified your models accordingly? A model people can’t remember how to follow won’t do much for your content.

Content migration planning#section19

When you have significant legacy content, plan for migration to be its own phase of the project. Talk about what kinds of guidelines would make moving content to the new CMS smoother.

  • If blobs in the current site are being split into component chunks, position those field components near each other during migration, since they are all being derived from the same source.
  • Create a set of perfect example entries for authors to consult during migration. A set of real content—especially one showing how information from the old site fits into the new model—is a valuable reference tool.
  • Consider adding “migration phase” instructions and field groupings, with a separate set of “live site” guidelines to be put in place after migration is complete. The kind of reminders needed while content is being moved are not always the same as the help text for content being newly created.

Design and development#section20

As the design and CMS take shape, designers and developers are in the perfect position to spot potential snags.

  • Are any pieces of content making your spidey sense tingle? Is there author-editable imagery that has particular art direction needs? Are there site functions (e.g., “only one piece of content can be promoted to the front page at a time, and promoting a new piece will un-promote the existing content”) that you feel like you’re the only person who understands? Make note of any piece of site content that makes you nervous, and share them with your team so the guidelines address the issue.
  • Who’s going to enter the help text into the CMS itself? If the instructions are more tactical, this may be something the development team can do as they’re building out the content models. The content strategist may take the lead for more editorial guidelines—in many CMSes, help text is entered through a GUI rather than in code, so its entry doesn’t necessarily need to be owned by a developer.
  • Help text deserves its own QA. It’s incredibly important to see the instructions in context—there’s no other way to realize that a particular piece of text is too long or lost in the clutter, or that the field order doesn’t make sense in the form. The development and client or business teams should both review the edit forms for every content type to make sure all the important information has been captured.

Ongoing adjustments#section21

Revisit your work regularly with both your team and your client or project sponsor. Adjusting the help text or rearranging the fields won’t take much ongoing time, but can make a huge difference to the quality of the author experience—and the resulting content.

  • Review live pages, especially any with complex layouts. If you find images that aren’t following art direction or text that isn’t providing needed information, add more specific help text around those issues.
  • Chat with the authors using the system and make adjustments based on their feedback. Is there anything annoying about the edit form? Are the fields in an order that works for them? Are there places where a link over to a style guide or intranet page would save them time? Small changes to the interface can make a big difference to the overall workflow for an author.

Setting authors up for success#section22

I used to think it was inevitable: that a few months after launch, I’d be guaranteed to find misused fields and confusing headlines littering a site—the particular kind of chaos that arises from combining a powerful CMS with untrained site administrators. But as I’ve moved the content guidelines into the CMS itself, my post-launch check-ins have shifted away from annoyed sighs and toward small improvements instead.

When we embed instructions where they’re most relevant and helpful, we help our authors build good habits and confidence. We allow them to maintain and expand a complex site without feeling overwhelmed. A website that looks perfect on launch day is a wonderful thing. But when we improve the author experience, we improve the content forever—and that’s a whole lot more satisfying.

42 Reader Comments

  1. @webmeadow, this is a stunningly insightful piece. Of course, include content authoring instructions in the CMS. Good common, practical advice. Danke, lady.

  2. Yes! I’ve been telling people to customise the CMS in this way for years, I’ve very rarely seen it done or even found anyone who wanted to face the issue! So strange in this age where so many social apps and websites are very usable CMS themselves.

  3. You nailed this article. We have our own custom CMS and have made it extremely easy for clients to update their site with very specific fields however we have also realized that there is no substitute for good help text that speaks directly to the people updating the website.

  5. Most CMS now have the ability to have the ability to have custom fields added quite easily.

    WordPress has probably one of the more clunky ways of achieving this but some CMS like Drupal, ExpressionEngine, ModX and Craft have some really fantastic interfaces to achieve what Eileen is saying pretty effortlessly.

    Craft has a particularly powerful feature called “Matrix” which allows the content editor to build a page from predefined content types which can include instructions Matrix as described by their developers

  6. In my own instructional writing, I’ve made a point of reminding people that when building an app of any kind, the developers should always remember that for the user, it’s all about the payoff.

    Priority expresses that in a CMS backend, but sometimes it helps too not only to explain inline how to Do It Right, but also to remind the content writer/producer briefly (space permitting) of the payoff they’ll get when they correctly populate this obscure field or that.

  7. I didn’t do this on the first few sites I built in ExpressionEngine but I eventually started using NSM Publish Hints and placed an Instructions field at the top of EVERY publish page. I included a thorough description of each field and what was expected. For the more important fields or fields I felt would cause more problems I added a brief description when I set them up. This made it hard to ignore and if you forgot what you were supposed to do you could always expand the Instructions field. I also made heavy use of Title Master to rename the default title fields and in some cases hide it altogether so I could concatenate multiple fields (i.e.{ First Name}, {Last Name} becomes {First Name Last Name} as far as the entry title is concerned) and clients didn’t have to repeat any information.

    For the couple of CraftCMS sites I’ve built I used the Instructions section for the field which places all helper text below the field title. I balance the need for instructions with keeping the publish page less cluttered here so only the fields I think will cause confusion get directions. I haven’t found a replacement for NSM Publish Hints for this CMS but perhaps one will become available eventually.

  8. Back in 2011 I wrote about using your CMS as curator of content, so it will come as no surprise to know that the CMS I am co-founder of – Perch – has structured content at the core.

    One of the things that has been part of the template language from the start has been the ability to add help next to fields and also at the top of the form in the CMS. The content blocks at the top can accept HTML so you could even record a little video to help an editor.

    I’m always really interested in talking about how to improve the CMS experience for editors. They often feel like the forgotten users. People worry about site visitors; they worry about the ease of development of the CMS and then forget about the poor soul who has to battle with the thing to update the site every day!

  9. Thanks everyone, I’m so glad you enjoyed the article!

    @ben, that’s a great point about obscure fields. Meta tags and taxonomy can seem so disconnected from the “actual” content; it’s really important to help everyone understand what functionality is enabled by their being filled out correctly.

    Everyone, please feel free to share any tools, modules, plugins, or tutorials you’ve come across for your favorite CMS that can help improve the authoring experience!

    For example: there’s a great little Drupal module called Label Help that adds help text between the label and the field (in addition to the default help, which displays after the field). It’s a tiny change that can make a big difference!

  10. Great article. The Kit CMS tries to walk a fine line between an edit-in-place philosophy, so that editors can see what they’re putting and how it will look, with a “prompt them to do it right” one, whereby they’re guided as to the nature of the content they’re adding. We also go to great lengths to strike a balance between giving editors all the formatting flexibility they need whilst allowing the designers to create whatever they want and limit editors ability to mess that up. The final piece of the puzzle is being able to view and edit not just in a Desktop view but a Tablet or Mobile one too. I’ll refer our clients to this article for why we did it this way, so thank you for that!

  11. Great set of tactics! Maybe it’s my clients, but they’ve never been able to follow instructions from me, AKA “Mister Cranky Web Designer”.

    The best thing is for me to monitor their posts and fix them. They would much rather pay for this (ludicrous) service than invest in interface modification.

  12. This is a great article. I have been going the “training document” route for a while, always realizing its limitations. I have held one training session after another with no significant improvement. So… I am looking into your suggestions for WordPress right now. I really appreciate this piece.

  13. Excellent. A lot of common sense but also made me think about ways I can improve my forms for clients a bit more. Must share this with other people in my outfit.

    The choice of CMS is really important to act on much of this stuff.

  14. This is good stuff. Anything that can make content authors’ lives easier is a huge win. But the most important piece of this puzzle is the Ongoing Adjustments section this article glosses over.

    Somebody at the organization—or even outside—needs to be responsible for what goes out on the web and hold content authors accountable… kind of the brand police if you will. Sounds like a no brainer for us but often draconian to the client.
    Oftentimes clients bring us into the fold because their in-house staff is inadequate. Over the years, we’ve preached the merits of what a good CMS can do—make changes to your own website, no need to call us on us!—and they’ve seen the light. But now that they can wield ultimate editing power on their websites, once the “job” is done, they feel they don’t need the original CMS/designer anymore. When we broach the subject, clients can feel it’s even a money grab since we already “did the job” even when the scope changes.
    Client: “We need to make this headline red and green for the holidays…” Designer: But it’ll clash with your orange and blue website. We can try and change the color scheme/template maybe for that page or section… “Well how much is that going to be?” Probably $xxx. “Forget it. Can’t we just make the headline green and red? How come other fields we can choose color but not this one?” Designer concedes and makes the headline field a WYSIWYG field. Barf. Not the optimal solution.
    Then, once the website gets beaten up over the years from multiple junior-level designers—or even great designers—often at the whims of their bosses who have zero web and sometimes design experience, rinse and repeat.
    I think a lot of clients still think of the web as print. We need to ultimately educate them and have them realize this “CMS/website thing” is an on-going process and it needs someone either within the organization or outside to step up and do great work. As we all know, a “small” change in their heads can often mean a “big” change for us when it comes to actually implementing the design.

  16. Eileen, love the article! You hit the nail right on the head!

    At Roundedcube, I work to increase the learnability and usability of our products in this way. Of course, a bulk of the work is rooted in good content strategy and user experience design, but we go beyond by integrating a module we made into the Sitecore CMS called Help Center for Sitecore. It extends Sitecore’s existing functionality of help text and field descriptions by linking the content model into knowledge articles, HTML-based style/branding guides, how-to videos, downloads and other solution deliverables, all within context to the particular template or component the content author is using. It really helps reduce the change management and training efforts of our clients.

  17. Eileen, fantastic piece. I am wondering if you have any specific tips on the best way one might approach a Drupal developer to buy in to Label Help? I have a hard time convincing developers of the merits of modules that they don’t think will help them with the backend but would be enormous help for designers and editors.

  18. @Chris Oh man, that’s a good question! My first path would be to encourage the developers to think of the team, and the success of the project. Yes, it’s a tiny bit of work for them (but not really, thanks Drush!), but it’s better for everyone in the long run.

    If that doesn’t work, then I’d go straight for the ego: those editors are going to ruin your beautiful work, unless you give them the tools and the knowledge to do it right. Aren’t you tired, poor beleaguered developer, of people breaking your stuff? Don’t you wish they would just do it right? Those designers and editors need your help. They need you to teach them. [Probably through the use of these tools and help text; please install these modules and read this article thank you very much.]

  19. Hi, I am working as Web Developer in SAG Infotech (SAGIPL). I am having the knowledge of WordPress, Drupal. But here after reading your post, a query originated in my mind. You mentioned that the description has to be written within the filed (textbox, lablebox, etc). but I am confused in the state when the textfield is of small size and I have to add a 2-3 lines of description. In that case what I have to consider.
    I am currently writing that type of description above the filed. So is it correct?

  20. @Rudra Sorry if I wasn’t clear – I don’t think it matters where exactly the description goes: above the field, below the field, or even in a tooltip or popup. Every CMS is different, so what’s easy in one may be hard to implement in another. As long as you’re giving your authors the information they need to fill in the field correctly, I think you’re doing alright!

  22. This is a great article. It happened many times that we delivered a site with a perfect crafted CMS, to find out only later that the client was totally misusing it. We ‘fixed’ this by adding little tooltips that would show up on hover. But still, even hovering over a tooltip wouldn’t educate our clients. I guess the ‘in your face’-approach is better suited. I agree that a CMS should only show the fields that matter and are descriptive and explaining about what they’re for.

    The only drawback is that most out-of-the-box CMS’s don’t allow extending the existing fields with tooltips, or it’s very hard to do so. Perhaps a great gap to create plugins for?

  23. Yes! There’s so much “someone-gets-it” validation in your post I wanted to respond and add notes from my CMS niche:

    http://www.createandbreak.net/2014/10/training-your-sdl-tridion-cms.html

    Tridion’s typically found in companies with lots of websites and multilingual needs. It has configurable descriptions, pop-up help, and even visual hints like previewing a page before creating it and icons for templates. But the challenge I see is getting the business, CMS editors, and technical teams to work together so the authoring side makes sense.

    Oh and there’s one more point I also see in CMS setups: “just in case” fields for “future use” that don’t actually get used. Maybe worse than unhelpful help are invalid options and fields that aren’t used? We don’t put “Under Construction” signs on websites but it’s okay in the back office. 😐

    Great article, thanks for the inspiration! I’m compelled to share this with my colleagues and future projects.

  24. I think half the battle is getting developers to care about how their clients will use the CMS platform. I was fortunate that early in my career I was responsible for training on the CMS. This gave me valuable insight into how clients use a CMS to update their site. The questions that they asked after the training and the problems that they ran into taught me a lot about what clients have trouble with and I began to see the CMS through the client’s eyes as I built out a site.

  25. This is great advice. I’ve done this with success when adding custom content types in WordPress. I’ve also found these are great ways to add human warmth to a sometimes off-putting CMS interface. You can remind an editor that somebody was thinking of them, there’s a person putting this together.

  26. Nice article and advices, thanks!

    Most of the time, we don’t call them CMS anymore (even if it is one 🙂 ), we prefer the expression “site manager”. Customers really enjoy them, they are more closer from their activities, so they’re more likely to use it (correctly).

    Be strict to be cool would be the key point 🙂

  27. Great article! We have been struggling with this a lot as an agency before, until we built a tool that provides inline help/tutorials right within the CMS. Then we were able to see what is happening with the CMS and editors if you had the tools to track it and see where they struggle or what kind of things they are inputing. Actionable metrics, that not many people care about, especially in web industry, web agencies build a CMS, but they don’t care much about the usability or the customer support behind, yet the customer support is essential part of our services – probably the most overlooked.

    ( Shameless plug – the service is http://inlinemanual.com )

  28. Good article. I am stuck with wordpress for good reasons 🙂 I always customize the cms for each of my client without touching the core.. you just need to know what to use.. e.g wp types plugin and some css/js code.. cool tips etc.

  29. The choice of CMS is, as you say, vital. From my point of view, the first thing to do is separate out the AMS – article management systems. By this I mean systems that are primarily aimed at the creation and management of articles using a single core field, but then have to be radically adapted to achieve anything more precise or detailed. Although these can be used to create the kind of site you describe, they are really not a very good starting point.

    To my mind, a true CMS out of the box makes no assumptions about what the content might be, how it might be presented or even much about how it might be managed beyond a basic logical structure.

    There are several powerful options that fit in this category like Modx, Expression Engine and the one I know, Processwire. All of them are highly customizable Content Management Frameworks that allow for very precise developmental control.

    With the Processwire blank profile, for instance, you only have one field – Title. From that point it is up to you to create what fields are required to fit the type of content being presented.

    That means that you can walk your author through what is required of them in stages. Fill a headline in here please. Add a start time here. Write 50 words here. Add an image here please. And so on. In theory, you could avoid a RTE completely, if you wanted to, reducing a lot of potential formatting headaches. Since you are designing the form from scratch rather than trying to adapt an existing system, you can add as much or as little hand-holding help as you wish. Though finding the balance between informative and patronising is something that no CMS can help with, however well conceived!

    Likewise, when it comes to presentation, the Blank profile doesn’t have any template files other than the needed home.php file. The system does not have any templating system or special templating language, so you effectively construct your theme in the same way you would a static website, and with the same tools and language.

    This allows you to present your very precise content in a very precise way, really nailing down those potential site busting problems like image sizes at the point of delivery, while being able to take advantage of any CMS framework, JQuery dancing sheep or anything else you like.

    I think it is vital that when approaching a business website for a company, that the system being used does not dictate or shape the message that the company needs to convey. The advantage of the old-fashioned static HTML website was that it could be moulded to fit the needs exactly.

    The modern CMS/CMF must give the developer the control and freedom of expression they have with a pure static site, while backing it up with powerful content management tools so that the continued growth of the website has the same sort of clear controls that was taken for granted in the print world.

    This is not only fair to the developer as their hands are not tied to one particular route to find a solution, but also fair to the client who can now worry about their business and their brand messaging without fear of breaking their website.

  30. Hi, great combination of all possible techniques which can be applied to a templating engine of cms.
    I do feel there should be a system in place to analyse the data input over a period of time and suggest back to content master and authors both what’s is going wrong and how to revert back to original guidelines.
    For new joiners there should be easy video tutorials to describe fields.

  31. Nice conclusions and references, @webmeadow, I have been working similarly with ProjectFork, a free joomla Project Management Software, for updating and creating new articles. Your views will guide us to produce content more efficiently.

  33. @webmeadow excellent article!
    We are just implementing instructions in our CMS and reading your insights helps a lot.

    Thank you Eileen!

  35. We did similar things in a previous team with SquizSuite, creating many forms to add content to make it easier and to ensure some consistency by using dropdown menus and embedded instructions for adding different content types which we modelled, but I’m currently working with SharePoint and it’s much harder. Sigh.

  36. Good article Eileen. I recently started adding instructions directly in the CMS I use and it’s proved incredibly more useful than in a separate stand along document.

  37. Excellent article Eileen! You have mentioned some really important points for incorporating content guidelines in a CMS. It is mandatory that one must provide the context, explaining what a field is for and how it will be used.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career