While working on a new section for the website I’m in charge of, it occurred to me that this task could be compared to filing paper documents, and should be achieved in five steps.

Gathering documents

This first step is about gathering all information you want to publish in the new section. It includes making sure all information you get belongs to the same set of boxes. You also have to make sure each piece of content appears only once. Find a native location for each of them, reuse will be dealt with later (but you can already take notes of what will be reused). It is also the right time to exclude information already showing in any other section of the website. You want to gather only core documentation for the topic you’re interested in.

Opening boxes

Content now needs to be organised into sub-topics. Think of them as if they were the boxes to which you break down documentation. Content generally can be broken down using these useful questions: what, who, how, when, where. Depending on the amount of content, you will end up with one or more pages for each “box”. The challenge is to have not too much and not too few boxes.

Writing the labels

Deciding on what each sub part should be named may seem a not so important matter. Indeed it is one of the most crucial decisions you have to make when setting up your new section. Because such a label should be meaningful for all users and should reflect the efficient information organisation you came up with in the previous phase. If you can’t find a harmonious and efficient set of labels to put on your boxes, it may mean you have to reconsider your set of boxes or repartition among them.

Filling boxes

It is now time to proceed to actual filing: put each document in a box. A document should go in one box and only one. You will deal with reuse and links later on. If you find one box is over packed compared to others, you may have to review your boxes or labels to reach a good balance. Once you’re done, have a look at your filled and labelled boxes. Do you reckon it is easy to find where any topic belongs? Ask a friend to do the same exercise, and make any adjustment they would suggest.

Finalising organisation

You now have a well balanced set of information. At that stage you will want to optimise your content inserting links between pages and displaying some information in more than one place. It is now time to tag, highlight and comment content properly to use your CMS re use facilities in full.

Remember that what you’re looking to achieve is a meaningful, complete and well balanced section that allows users to find what they are looking for. That’s why I recommend this 5 steps approach: gathering, breaking down, labelling, filing, linking.

- Are folksonomies any good?

- What are microformats?

- Text editor: 10 points to check when choosing a CMS

- Is your hidden content worth seeing?

- What is content quality?

- Website housekeeping: 4 golden rules

- Why are CMS not magic?

- Enter Content Here is Seth Gottlieb’s blog about content management market and trends, with a strong flavour of open source.

- CMS Report is the blog to read to follow CMS news and announcements. You can also submit a post you think of interest.

- Column Two is edited by James Robertson, an expert in web content management and intranet, with interesting views on knowledge management.

- The CMS Matrix features a powerful facility allowing to compare more than 800 CMS!

- CMS Wire News section is another great source of information about what’s going on in CMS world.

- On Content Management category of Gadgetopia, you will find Deane ’s thoughts about CMS technology and best practices.

Typing path

Whenever contributors have to type in image or page URL to insert them in their text, there are 1 chance out of 4 they make a mistake. This can raise up to 3 out of 4 if they have to type in a different domain name than the one hosting application they are currently logged in. Paths and URLs should not be of users business, it is enough they have to type external site URL when linking to them. Images and internal links should always be inserted using a visual browsing facility.

Default content

Default content is great because it is a way to ensure no page goes live with empty content elements. But sometimes I wonder what is worse: no content or irrelevant content? Let’s face it: average users can’t be asked to remember to check every default content field to see if it needs to be adapted. They often contribute to website as part of their jobs, because they are expert of a given field and so are not specialised in web content. The solution is to explicitly extend their contribution to hidden content such as META or alt attribute, and to make it mandatory on a system point of view. And also to make the system take care as much as possible of things such as pages title or navigation links.

Externally formatted text

Users love pasting text they have previously edited in their favorite word processor. This is probably because lots of WYSIWYG editors featured in CMS are not that user friendly. But this is a nightmare because it imports all sorts of formatting bits that CMS can deal with more or less easily. If there is no easy way to integrate word processor in the CMS interface (or just because it is not a good idea), make sure this kind of error can be handled correctly by the system. It should always block saving or warn user when an unacceptable piece of content has been inserted. Another good work around is to feature a ‘clean formatted text’ button: it transforms any formatted text to pure text. It is almost magic, so make sure you let users know about this.

Hacks

The most important is not what a system can do but what it has been designed to do. Whenever users have the technical possibility to hack what the CMS is supposed to let them do, there is a potential error on its way. A good rule of thumb is that there is danger if code can be inserted (and interpreted as is by the system) on a visual interface. Access to code view in WYSIWYG editor should always be restricted to really expert users. And wild formatting using weapons such as b or u in pure text fields should not be accepted.

Conclusion

To sum-up, first steps to user friendliness of a CMS interface are:

• Browsing computer files and system facility whenever a path to a resource is needed
• Educating users about necessity of good hidden content
• Making the CMS handling site structure and navigation automatically
• Offering a ‘clean formatted text’ facility
• Restricting access to source code
• Forbidding html tags anywhere outside of the code view facility

To end on a positive note, I found out that observing how errors happen gave me a better understanding of what a CMS basic features should be.

The good thing with Jennifer’s book is that it goes further than basic knowledge. It dives deep in accessibility and multi browser support, with plenty of practical examples. The book encompasses all you need to know to set up a quality web page: XHTML/CSS, JavaScript, graphics, other media such as audio and video. Appendixes are also a precious resource: beside HTML and CSS reference lists, they provide codes for special characters and colours. It even mentions microformats in an Appendix signed by Tantek Çelik himself.

In my daily practice, I will check this book at least one a week. That’s enough to say its subtitle “A Quick Desktop Reference” is not usurped.

• How many HTML elements can you name in 5 minutes?
• How many CSS properties can you name in 7 minutes?

I’ve taken the tests myself but won’t make my results public. Unless it turns out a reasonable amount of people get a lower score than mine.

Where is hidden content?

• Often overwhelmed, the URL can tell a lot about your content and should then be as meaningful as possible. Not to mention URL is also used in major search engines algorithm when determining what a website is about.

• Page title (html tag title) is what will appear in Google and other search tools when your site get listed. So make sure your title includes 1) the name of your website, 2) an explicit title of the page.

• Page description (html meta tag ‘description’ ) is what search engines will show under your website title on result page. That’s why it has to say briefly (no more than 250 characters) what the page is about. Though less important, other meta tags are worth considering.

• Regarding keywords, meta tag is not that important anymore. If you’re a blogger, keywords (also known as ‘tags’) are extremely important to ensure you page is correctly referenced in various social networking sites. They are also a good functionality to offer to your readers when displayed on your site as a tag cloud. So make sure you describe thoroughly the topic of your page, but be careful not to provide too much information. If you blog about sport cars, it is useless to add ’sport’ and ‘cars’ as keyword in each of your posts.

• Anyone concerned by accessibility know how important is image ‘alt‘ attribute. But what is the point of typing lines such as ‘image’ or to repeat what is said in the caption? What should show in the ‘alt’ attribute is a proper description of the image, to allow reader who don’t see it to get an accurate savour of the atmosphere of the website.

• As for ‘alt’ for images, link ‘title‘ should be really a description of the page to which it links. For instance ‘link to an external website’ is poor, ‘University of Berkeley undergraduate programmes 2008′ is good. On top of that each link ‘title’ needs to be unique to allow ones using screen readers to discriminate between each one.

• A table ‘summary‘ aims to tell what the table is about. It is good for accessibility, as most of its friends from Hidden Content Club. But it is also a good opportunity to make sure you actually needed a table. If you come up with a summary such as ‘annual income for Europe profit units’ you’re fine. But if your summary looks like ‘main content of my new post’, you should go back to your favorite web page editor.

How to take care of it?

Depending on your website management tools, pieces of hidden content are more or less automatically generated. For instance, title is taken from your post title in most blog authoring tools. There may be a specific field for description in user interface. Regarding image ‘alt’, link ‘title’ and table ’summary’, if your text editor is good it will include these fields in dialog boxes. Bear in mind that name of these fields may change from one tool to another.

URL may be a bit tricky to deal with. Lot of content management systems will generate non meaningful URL including numbers and special characters. The good thing is that they often come with a solution to set up user friendly URLs. When choosing you URL rewriting rules, make sure it includes words from the actual title of your post.

Anyway, when previewing a page to publish, have a close look at the source code to check this now famous hidden content is in order ⁽¹⁾. All this may seem a lot to had to average website management burden. The key point is to understand that hidden content should be part of the main content generation. Once you get used to it you will naturally include it in your pre-publication quality check.

Believe me and forget about default meta or meaningless ‘alt’ attributes. Taking care of hidden content is not only a basic accessibility requirement. It is a way to ensure everyone can access an optimised version of your content. It is good for your readers comfort and for your reputation, so don’t skip it.

(1): That is to say don’t follow the example of this blog. Description is currently not available but should be back soon.

1 - Organise folders

You should be able to find any file easily. If you need to google a page to find it, it may mean there is a problem in your folders hierarchy. First of all, it is easier if folder organisation reflects website structure. Create sub folders to organise files by types or by date. It is a good idea to follow the convention of having a folder to store images (it should be named ‘images’) and one for documents (’docs’).

2 - Set up a naming convention

At a folder level, nothing is worse than facing a list of indiscernible files. By using a naming convention, you make sure your files are showing the way you want. Do you want them organised by date or by name? Do you need the name to carry information about file size or the part of the site it will be used in? Give it a gook thought before you set up your folder, it worth it.

3 - Make nothing irreversible

Never assume a minor change is straight forward enough to allow you to go without a back up. Except when fixing typos, you should always keep a copy of a document before starting amending it. Then again, use your naming convention (see previous rule) so every back-up version will be named on the same model. Some usual choices are ‘file-name-old’ or ‘file-name.bak’.

4 - Clean as you go

Don’t leave anything out of date or inaccurate live. Mainly because it could be indexed by your website search engine, and users could potentially access to it via the search facility. But you also want to prevent anyone from loosing time editing the old version of a page. And the less oldies you keep on your server, the more disk space you save for good fresh content.

To sum it up, make sure your website folders are clean and organised in such a way that anyone could take up your position any day. This way you will spare precious time in your daily tasks. Is anyone aware of other rules I may have not mentioned in this post?

Among other data base driven web applications, Ruby on Rails can be used to develop content management systems. Ror is not a CMS but is full of goodness for anyone who wants to come up with a fully functional and highly customised CMS. Though this ‘anyone’ has to be a developer if he/she wants to take full advantage of the framework, of course. There is not official extensive list of CMS built with Ruby on Rails, there are some of them out there including Radiant or Slate. Lot of them are even not publicly released, developed for internal content management purpose only.

So, next time someone pops in your office asking if the new CMS will be Ruby on Rails, just say no. And then add that the new CMS could be developed with Ror if ’someone’ finds money to hire a good developer.

Any more questions?

• Where could I find 12 nice Ruby on Rails tutorials?
• Who is David Heinemeier Hansson?