Content management system
From Digipedia
| How useful is this article to you? 1 (not useful) - 5 (very useful) |
| Current average rating: 0 |
| Please login or create an account to rate this article |
OVERVIEW
This article is based on the UKOLN Good Practice Guide, it explains what a content management system is (and is not!), and why you need one. It also explains how to set about finding the best one for your purposes, including some tips on questions to ask potential suppliers.
What is a content management system?
A content management system (CMS) is a database which organises and provides access to all types of digital content - files containing images, graphics, animation, sound, video or text. It contains information about these files (known as 'digital assets'), and may also contain links to the files themselves in order to allow them to be located or accessed individually. A content management system is usually used to manage digital assets during the development of a digital resource, such as a Web site or multimedia production. It might be used by staff digitising images, authors and editors, or those responsible for the management of the content development process (content managers). Content management systems range from very basic databases, to sophisticated tailor-made applications. These more complex systems can be integrated with the eventual digital resource in order to enable access to digital assets and to allow regular updating. Content management systems can be used to carry out a wide range of tasks, including those described below.
What isn't a content management system?
A content management system is not any of the following:
- a library, archive or museum management or cataloguing system (although some of these types of system include certain aspects of content management systems, and can be integrated with a content management system);
- a picture library system;
- a word processing or other text file containing lists of digital resources;
- a presentation file (e.g. a PowerPoint file);
- a multimedia application
Content management systems do not contain information about the presentation of the digital content (e.g. end-user interface, navigation, design or layout). Content management systems are not aimed at ordinary users; they require training and may have different interfaces depending on the type of user (e.g. editor, system manager, image manager etc.).
Why your programme will benefit from a content management system
Content management systems are essential for large or even small-scale projects which involve the capture or creation of digital assets. They also are increasingly useful for the creation of any but the most basic Web sites.
Managing the capture or creation of digital images requires metadata to be recorded which documents the capture, ownership, location and licensing conditions relating to each image. Even for a few dozen images, this may add up to hundreds of different pieces of information, the management of which would not be possible without some automated assistance. For a learning resource containing hundreds or even thousands of images, the job is larger still.
Similarly, managing a Web site with even a few pages is a time-consuming task when updates are required, perhaps when a page is added which requires the navigation menu to be updated on other pages, or when a logo changes which then needs to be reflected on all pages. For this reason, the use of templates which draw on content held in a database, is a vital management tool. Without this type of application, the Web site would either fall out of date very quickly, or would require ever greater staff resources to retain its currency.
What do content management systems do - and how do they work?
Holding information about digital content
Content management systems hold information describing digital assets. This information is known as metadata (information about other information). The metadata held in a content management system can be used to manage and provide access to, digital resources. Metadata held in a content management system might include:
- capture and creation information (e.g. author, editor, date captured, image resolution, type of scanner used, etc.).
- descriptive information (e.g. subject, caption, reference to the original document or object, associated people, places or events, etc.);
- rights ownership (e.g. copyright owner, licensing information, etc.)
Metadata held should support local management processes and should also allow access and resource location functions, by complying with the Dublin Core. Metadata should also comply with domain-specific standards as required, including AACR2 and MARC (for libraries), SPECTRUM (for museums) and ISAD (for archives).
Holding digital content
Content management systems may store narrative text for publication on the web. Text can be recorded together with author, version and currency information, which enables the publication of information online to be managed more effectively. Systems may also provide direct links to digital assets, enabling users to browse through images, sound or video clips as part of the authoring process.
Process management
The system should enable content managers and editors to keep a close eye on the digitisation process, including monitoring the capture of images, or tracking the authoring and editing of narrative text. This can be done using simple checkboxes or by completing data fields which document progress. Some systems allow the pre-publication process to be tracked more visually, using workflow management tools which represent the progress of a piece of text through the authoring process - for example, using coloured 'traffic lights' to indicate when a piece is ready to be published online, or alternatively by displaying a 'route-map' with milestones indicating how far an article has progressed down the editorial route.
Publishing online
Any content management system should have a mechanism allowing it to make this content available to a Web site. Depending on the complexity of the system, this might be done in different ways.
At a basic level, the system might export the content in a pre-defined format, to a separate database used to run a Web site. This would require regular exports to be made as content was updated, and is an effective, if labour-intensive means of enabling the online publishing of digital content.
An alternative would be to use a content management system able to be integrated with a Web site. In this type of arrangement, a web manager would create templates for different types of web page. Layouts for different types of page could be set up, pre-defining the type of content which would be displayed in each template. For example, an organisation's logo might always be displayed, as well as a navigation bar, and a special template might be designed to hold information about an items held in a collection.
This template might then be selected to create a page containing, for instance, an image of an illuminated manuscript, together with a caption and a transcription. This could be done by hand - for instance an image or text could be copied from the content management system and inserted into the correct place in the template. However this would mean that whenever the text was updated, the web page would need to be recreated by hand. For this reason, it is better to create a web page by linking the database directly to a template.
This could be done by selecting the template to be used for a specific page, then instead of adding in the image or text by hand, inserting a database query for each component of the page which includes a digital asset to be drawn from the database. Immediately before the web page is 'published' (i.e. copied to the live Web site), a programme is run which ensures that the web pages are updated by running their database queries on the content management system. The image of the manuscript, the transcription and the caption are retrieved directly from the database, copied to the web page and displayed whenever the page is called up. When content is changed (for example, the caption might be updated, or a better quality image created), the Web page is re-published using a single command - i.e. one or more database queries are re-run - and updated images or text are automatically uploaded, replacing the previous versions. In this type of system, the database is held within the organisation's security firewall and the newly-published web pages are mounted externally.
Publishing on-the-fly
More sophisticated content management systems can deliver digital content direct to web pages which are constructed 'on-the-fly' as users browse through a Web site. For example, a user might wish to select items from a collection by searching on a keyword. The relevant items would be retrieved directly from the content management system, based on the metadata describing the subject of each digital record. A web page is then created to display details of each item online, using a template designed for that specific purpose. As before, the template places the relevant content for each item within a pre-defined layout as it is displayed on the screen. The web 'page' however, only exists at the time of display, and is effectively a temporary composite of design, layout, text and images. The benefit of this type of system is that it allows updated content to be constantly updated, rather than published in batches which may take time to upload. It also makes the management of the Web site much easier.
Clearly security and access for this type of system need to be more sophisticated. In some applications a 'source' database is held within the organisation's firewall and extracts automatically copied to the external version whenever content is updated. Alternatively, additional security measures may be built into the content management system to prevent unauthorised access.
How to select a content management system
The process of selecting a content management system is the same as for any other computer system. It may be governed by local rules, prescribed by European law, government or local authorities for example. The process of procurement will normally include the steps described below, although depending on the size of your project, you may wish to simplify the process, or you may be required to include certain formal stages. If in doubt as to the process you should follow, contact your organisation's Finance officer. The steps to procurement include the following:
Develop a business case
Based on the size and complexity of the planned project, decide from the outset the scale and scope of the system which is required to support the development and delivery of the project. Take into account existing systems and skills. One issue for many museums, archives and libraries will be that they already have integrated collections management systems which enable the recording of metadata relating to digital assets. They may be able to extend the use of existing systems to encompass some additional functions, in which case their requirement for a content management system is restricted to a database to run the Web site which will allow content to be drawn from the existing collections management system. Once it has been decided to proceed, it may be useful to set up a Project Committee (if one does not exist already) to act as a decision-making body throughout the procurement process.
Draft Operational requirement
Based on the business case, draw up a list of the functions and the recording capabilities which the system will require. If the business case and your knowledge of the market suggest that a simple, off-the-shelf package is required which will not cost a large amount, then it may simply be necessary to follow your organisation's internal rules for purchasing software and demonstrating value for money. However larger projects will almost certainly require more complex systems which require the project to go out to tender, using an Operational Requirement to invite responses from vendors and developers. If this is the case, the Operational Requirement should include the following components:
- Introduction and background to the project
- Procurement and project implementation timetable
- Functional requirements
- Technical requirements and operating environment
- Contractual requirements
- Form of response to the requirement
The functional and technical sections will contain some requirements which are 'mandatory' (i.e. any system must deliver these in order to be considered). Other requirements may be assigned different levels of importance. Try and restrict the mandatory requirements to those areas which you really could not do without - otherwise you may find yourself without a system - or with one which is beyond your budget.
Obtain approval and funding
The draft Operational Requirement alongside demonstrations and initial discussions with suppliers, may be used as a basis for establishing the likely cost of the content management system. Approval to proceed will normally be required from the Project Committee, who may suggest that the Operational Requirement is refined to the point where it can reasonably be expected that the eventual system will fall within budget.
Refine and issue Operational Requirement
A minimum of 28 days is normally required by suppliers to respond to the Operational Requirement. Try and be as helpful as possible - bear in mind that responding to requirements is an expensive and time-consuming process. Invite suppliers to ask questions during the response period - but ensure that any responses are copied to all those submitting tenders. Provide a template for responses - preferably in the form of a spreadsheet.
Evaluate and shortlist proposals
Make sure that you have decided on your evaluation model before opening tenders from suppliers. For larger projects, or those involving consortia, you may wish to set up two evaluating teams in parallel - remember that involvement in the evaluation will help ensure ownership of the selected system across your organisation(s). Assign a ranking of importance for each question (e.g. 3 for important or mandatory requirements; 2 or 1 for less important areas). You might also assign an overall rating to the different sections of the requirement which are being evaluated. For example there may be many more functional than technical requirements, but you may decide that each section is worth 40% of the overall score, with the remaining 20% based on your evaluation of a vendor's ability to deliver and track record. Once this evaluation model is agreed, then you can open the tenders and score the responses to each question, using the spreadsheet.
Finally - remember that the cost of a system is not what matters, so much as the value for money which it represents, and the cost of ownership over its lifetime - including the equipment and people needed to run it. If the ideal system is out of your budget, it might be an indicator that you have asked for too many mandatory requirements - or equally, that your organisation had not recognised the importance of the system to your planned operations. In either case, your Project Board may need to be consulted.
Select system, award contract and implement
Once the system has been selected you will need to notify the vendor and agree terms of delivery. For larger, more complex systems, you may need to keep a vendor in reserve in case the contractual process breaks down with the initial supplier. You should not begin the implementation process until the contract has been signed. It is sometimes possible to exchange formal letters of agreement as a temporary measure to allow initial stages of work to proceed, but in such circumstances approval should be obtained from the Project Committee and other formal sources as required by your organisation. Any work carried out in this way should be extremely closely defined and managed. It is normal to retain a proportion of the cost (5%-10%) until formal tests have been carried out on the system and the implementation has been carried out successfully. This is known as the acceptance process.
What should a content management system do?
The content management system you select will need to assist you in the management and/or delivery of digital resources, depending on the scale of your project and existing systems in place. Your business case will help you decide the scope of the system you need and the functions you require. You may need to consider the following areas when deciding on what your content management system should do:
- Scope of system (e.g. metadata recording, process management, online publishing, integration with other systems)
- Data structure (including the ability to record your required metadata, to hold links to digital assets and to hold text which can be edited and published)
- Templates (including design, layout and accessibility for different types of page; also your ability to update templates)
- Security and access (including access rights for different types of user, e.g. retrieval only, editors, publishers, web manager, administrator etc.)
- Workflow management and process control
- Ability to integrate databased information - either for publishing on-the-fly- or in batches
- Ability to generate navigation and links between pages automatically and consistently
- Ability to interoperate with existing systems and to comply with data standards
- Ability to run on your existing technical infrastructure
- Ability of database to search across metadata and narrative text content
- Ability to manage metadata across the database, e.g. update or assign values globally or across a selection
- Ability to archive data, and to output reports in digital and printed form
Unless specific terms are agreed, the IPR in any application developed specifically for your organisation, should normally be retained by your organisation, excluding the rights in any underlying or third-party software which will be owned by the developer or third party supplier respectively.
How to find a content management system
If you are a museum, library or archive with an existing collections management system, find out what content management functions can be undertaken by that system. Similarly, if you are a member of a consortium, find out who has existing systems within your group. Even if you don't use an existing one, you're going to have to ensure that everyone can either contribute content in a standard form, or share a common system at some level.
Fora for asking questions about content management systems can include:
- Posting questions to lists such as the Museums Computer Group (mcg@jiscmail.ac.uk).
- Visit the major trade shows which run each year - they all send flyers to libraries and archives as well as the information management sections in museums. Talk to systems vendors on their stands; similarly, attend professional conferences and review the trade stands there.
- An hour spent telephoning the managers of existing online projects will normally throw up a number of leading suppliers - as well as vital 'insider information' which people might be happier divulging on the telephone rather than on an email list.
- Contact professional organisations in this country and overseas - some, including the Collections Trust and the Canadian Heritage Information Network undertake regular reviews of software.
Making sure it's the right CMS for you
In order to decide whether a system is worth considering, try asking the following questions of yourself and of potential suppliers - but bear in mind that no supplier is likely to respond directly when asked 'how much does it cost' on a trade stand or on the phone - you may need to be a bit more subtle!
Find out...
- What's the budget? How much does it cost over its lifetime?
- What skills do we have in-house or in our consortium? What skills does it require to run it?
- What's our existing hardware and networked infrastructure like? What hardware and network will be needed to run it?
- How IT-literate are the staff who will be using it? How complicated is it to use?
- How many people & how much content do we have? How many users can it support - and how much content - while maintaining good performance?
- How tight is our timetable? How many people in the company - and how many other projects on the go?
- What other systems will it need to work with? Can it interoperate with our existing systems?
- What kinds of data will we want to record and access? Can it handle data in a wide range of standard formats?
- Do we have any special, or difficult problems and what do other organisations like us use? Have the suppliers dealt with your type or organisation/requirements before and can they provide reference sites for you to visit?
- What if the system goes wrong? What support and maintenance services are available?
Future-proofing your content management system
To ensure that your content management system will be useful in three or five years time, and that your content will be secure and accessible in perpetuity, there are a number of issues which you will need to consider including the following:
- Will it deal with existing standards for data - and do the suppliers take a pro-active approach to keeping their products up-to-date?
- Does the system use a standard, open operating environment and hardware?
- Is the system able to import and export data in formats understood by other systems?
- Does it allow data to be archived in standard formats using secure, stable storage media?
- Is the database extensible - for example, can new fields be added if you decide to extend the range of metadata you record?
- Are the specialist skills necessary to maintain the application and the underlying technology, both readily available and affordable?
- Is the system in widespread use in similar projects?
- Does the underlying technology fit with your organisation's IT strategy?
Lastly - but MOST important - how will your new system be maintained and supported? Do you have the necessary internal skills to run the system, and is your chosen supplier able to provide you with effective support? To ensure this, you should consider taking out a separate support services contract, particularly for larger, more complex systems.
Types of content management system
Examples of CMS systems available at the time of writing include:
Proprietary systems: (NOTE inclusion on this list is for illustration only and does not imply any endorsement of the product)
Open source systems:
Related Digipedia articles
Further information
JISC TechWatch report: Content Management systems (2001)
Collections Trust software survey
Harvested links to other resources
Failed to load RSS feed from http://www.collectionslink.org.uk/index.cfm?ct=ws.search/keywords/software/returnType/resource/format/rss/!
[[role::newcomer]] [[role::project manager]] [[role::content manager]] [[role::acquisitions manager]] [[role::technical support]] [[goal::managing]] [[goal::content]] [[goal::designing]] [[goal::usability]] [[level::basic]] [[level::medium]] [[level::deep]]
