10 Tips for Creating Easy-to-Update Websites

Websites are most effective if they are kept up-to-date. While this may seem almost too obvious to state, the harsh reality is that most sites aren’t updated nearly as often as they should be.

Unless a website needs to change very infrequently, it is essential that managers and staff be able to update the website without having to go through a web designer or technical staffer.

This is what a content management system (CMS) is supposed to do for you. Unfortunately, many CMS-based sites are sufficiently confusing to update that the content owners don’t want to touch it, and the web designer or webmaster still has to be involved in every update.

If you are building a new website, make sure you (and your staff) are going to be able to add and edit content, without technical knowledge.

We’ve built hundreds of content-rich websites, and every one of them is routinely updated by non-technical people. Along the way, we’ve learned a thing or two about what’s needed to deliver a great experience for content editors and marketing staff.

Here’s our top 10 tips for building easy-to-update, content-rich websites.

1. Don’t use static HTML pages.

If your web designer suggests building a static site, run the other way!

There was a time when building pages in Dreamweaver was a reasonable way to construct a website, but that time is past. All but the very simplest sites should be built in some kind of CMS.

The CMS you choose will have an enormous impact on the ease of editing the site. Some things to look for:

• Clean separation of content (typically text and images) from styling and layout. The styling and layout should be automatic once the site is built.
• The ability to edit content "in-place", while looking at the website, rather than always having to find the corresponding content in the control panel.
• The ability to support whatever content structure you need, and to relate one type of content to another (such as authors and articles, or performers and events).

There is, of course, much more to choosing a CMS, which we’ll cover in more detail in an upcoming article.

2. Use as much structured content as possible.

With unstructured content, you’re just placing text and images on a page. The content lives on the page, and there’s no easy way to use it anywhere else.

Since this approach is the most natural for people accustomed to creating content for print, it is very commonly used. But it is not the best way to create content for the web.

On an unstructured page, it is up to the person entering content to provide all the markup. Even if you are using a wysiwyg editor, you still need to mark which headlines are h1, which are h2, whether a list is ordered or unordered, etc. Images need to be sized appropriately and be styled to position them relative to the surrounding text.

The unstructured approach makes consistency and polish hard to achieve and even harder to maintain. It also makes automatic content reuse almost impossible.

When using structured content, each piece of information is put in a different field of a database. The example above shows a very simple database that makes it much easier to maintain a list of restoration organizations, with can then be automatically displayed in a nicely formatted list. The code on the list page never needs to be touched; it pulls the unstyled content from the database and constructs the HTML to display it.

Structured content simplifies life for people adding content, and it keeps all the site’s pages consistently styled. It also allows information to be easily reused in apps, feeds, and more.

3. Don’t overuse the wysiwyg editor.

For simple content entry, a wysiwyg (what you see is what you get) editor can be great. It lets you just enter text without needing to know a thing about HTML.

Most wysiwyg editors will automatically wrap raw text in paragraph (p) tags, but you’ll need to apply h1, h2, or h3 tags to your headings, identify lists, etc. So don’t expect that a wysiwyg editor eliminates all need to understand the rudiments of HTML elements.

It’s fine to apply bold and italic with a wysiwyg editor, but you shouldn’t do much more. Type size, font, color, alignment, and line spacing should all be set by the site’s CSS styles. The wysiwyg editor should provide an easy way to apply one of a handful of styles. Using styles is the only realistic way to keep the site consistent throughout.

Wysiwyg editors should be used only for sections of text, not for page layout. When you have multiple content areas on a page, the page template should set the structure, so the wysiwyg editor is simply placing content into a single area.

Be sure you have the option to switch to an HTML view and check the code that the wysiwyg editor generates. There are times when there’s no other way to clean things up.

4. Don’t paste formatted content from Word

Many people write content in Word, and then paste it their website. This is the source of much grief.

Left to its own devices, content from Word will be pasted in as a huge, ugly block of HTML that tries to style the HTML to fully match the Word document.

Alas, that is not what you want. Fonts, sizes, line spacing, colors, and so forth should all be determined by the site’s CSS stylesheet, not embedded in the HTML.

Using Word-generated HTML also bloats the markup (there’s hundreds of lines of useless code for a single line of text) and makes it harder to edit.

Most wysiwyg editors have some sort of "paste from Word" function, or at least "paste as plain text". That’s what you should use if you must use content from Word. The goal is to strip out all the styling that you don’t want, while possibly preserving some structural elements (such as lists), so the website’s styling can rule.

The most reliable approach is to paste as plain text, and then apply all the formatting (identifying headings, lists, etc.) using the editor’s tools. Or, even bettter, use a writer-oriented markup language, such as Textile or Markdown, and a system that automatically converts that markup into HTML.

5. Consider Writing in Textile or Markdown

Any way you slice it, authoring quality HTML content can be tricky. The best approach, when you’re creating lots of web-focused content, is to use a different markup language—one that is designed to be automatically translated into HTML.

You may have encountered such markup in the context of a wiki or other online publishing system. The two most popular markup languages are Markdown and Textile.

The advantage of these markup languages for writers is that they are much easier to write than HTML, and they can be automatically translated to HTML with high reliability. The idea is to provide a minimal way to provide just enough structural information to specify the HTML that should be generated.

For example, with Textile you’d write a level-two headline as:

h2. This is my level-two headline

And a bullet list is written as:

>* Item one<br /> * Item two<br /> * Item three<br />

There’s a small investment of time needed to make one of these markup styles second nature, and then you have a way to generate high-quality HTML markup without having to write it yourself.

6. Automate image sizing

I cringe every time I see a giant image file being slowing loaded, when the browser is sizing it down to a much smaller size before displaying it. This is perhaps the most common cause of pages being dramatically slower than necessary.

It is very convenient to be able to just upload whatever source image you have. It may be vastly larger than you need, however. For example, an image from a 12-Mpixel camera is about 4000 pixels across. On a web site, you’re likely to be using images from 200 to 1000 pixels wide, with file sizes of perhaps 20K to 500K, whereas images from a camera may be many megabytes.

Don’t make your visitors download these huge files, just to have them resized by the browser to a much smaller size for viewing.

Your content management system may handle resizing for you automatically—but many don’t. Be sure that the CMS you choose makes your common image-handling workflows easy, and also provides the proper markup for images to be resized responsively.

7. Avoid fixed-height areas

On the web, content areas have an inherently variable and unpredictable size and shape. Designers coming from a print background, however, often want to control the aspect ratio and the relative size of text and graphical elements.

This sort of control is possible on the web, by using fixed-height content areas, but it is rarely a good choice. The design should accommodate an arbitrary text length wherever possible. When height is fixed, content must be trimmed to fit, unless internal scrollbars are used (not recommended).

In cases where content editors need to stick to certain character counts, the editing interface should provide feedback to help editors hit the right length.

8. Build a customized control panel

A generic CMS control panel may be fine for simple sites, but as your content becomes more complex, it makes life a lot easier for content editors if the control panel is customized to match your particular site.

You might go weeks or months without editing a certain type of content, and if you have to hunt around through menus to figure out where to make a change, it can be very frustrating.

Customizing the control panel makes life easier for content editors by putting everything in the language of the site and making very conspicuous the most commonly used functions for the site.

A poor-quality content editor experience is the downfall of many CMS-based sites. Providing a good experience requires not just a good CMS, but thoughtful customization.

9. Train content editors

No matter how easy the developers may try to make everything, a content-rich website is not something that content editors should be expected to manage without training.

Often, just an hour or two of one-on-one training makes a huge difference in the effectiveness of content editors.

We find that it’s always best to divide the training time into two sessions. In the first session, we explain the concepts and show how to make common edits.

New content editors then spend some time making changes and additions on their own. During this time, they inevitably stumble across a few things they don’t quite understand.

In the second training session, content editors then have a better idea of what questions to ask, and they can learn about more complex tasks.

10. Get customized documentation

For a complex website, the standard documentation for the CMS is not adequate. Content editors need documentation that speaks directly to the way the particular site works—if it is well built, its content structures will be customized, and the documentation should be as well.

It’s also important not to bury content editors with documentation intended for site builders. Developers need to know many things about a CMS that content editors should never need to be aware of.

If a CMS does not treat developers and content editors differently, the chances of sites built with it being easy to edit are greatly reduced.

The key: make ease of updating a priority

Many sites are built using a CMS, with the intent that the site owners will be able to add and edit content themselves. All too often, even though they theoretically can make changes themselves, content folks end up going back to the designer or developer for most, if not all, changes.

This situation makes it very unlikely that the site will be kept up-to-date, and it will therefore be less valuable than it could be. With a bit of extra effort and attention on the part of the developer, it is possible to build sites that are easily maintained by non-technical staff, while preserving the polish and design integrity of the site.