Analysis Tools Used in User-Centered Design

There are few tools that are used in user centered design. They are persona, scenarios, and essential use cases.

Persona

During the UCD process, a persona of the user's need may be created. It is a fictional character with all the characteristics of the user. Personas are created after the field research process, which typically consists of members of the primary stakeholder (user) group being observed on their behaviour, and additionaly answering questionnaires or participating in interviews, or a mixture of both.

After results are gathered from the field research, they are used to create personas of the primary stakeholder group. Often, there may be several personas concerning the same group of individuals, since it is almost impossible to apply all the characteristics of the stakeholder group onto one character. The character depicts the a "typical" stakeholder, not an "average" individual in the primary stakeholder group, and is referred to throughout the entire design process.

There are also what's called a secondary persona, where the character is not a member of the primary stakeholder group and is not the main target of the design, but their needs should be met and problems solved if possible. They exist to help account for further possible problems and difficulties that may occur even though the primary stakeholder group is satisfied with their solution.

There is also an anti-persona, which is the character which the design process is not made for. Personas usually include a name and picture, demographics, roles and responsibilities, goals and tasks, motivations and needs, environment and context, and a quote that can represent the character's personality.

Personas are useful in the sense that they create a common shared understanding of the user group for which the design process is built around. Also, they help to prioritize the design considerations by providing a context of what the user needs and what functions are simply nice to add and have. They can also provide a human face and existence to a diversified and scattered user group, and can also create some empathy and add emotions when referring to the users.

However, since personas are a generalized perception of the primary stakeholder group from collected data, the characteristics may be too broad and typical, or too much of an "average joe". Sometimes, personas can have stereotypical properties also. Overall, personas are a useful tool that can be used since designers in the design process can have an actual person to make design measure around other than referring to a set of data or a wide range of individuals.

Scenario

A scenario created in the UCD process is a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story. The story should be specific of the events happening that relate to the problems of the primary stakeholder group, and normally the main research questions the design process is built upon.

These may turn out to be a simple story about the daily life of an individual, but small details from the events should imply details about the users, and may include emotional or physical characteristics. There can be the "best case scenario", where everything works out best for the main character, the "worst case scenario", where the main character experiences everything going wrong around him or her, and an "average case scenario", which is the typical life of the individual, where nothing really special or really depressing occurs, and the day just moves on.

Scenarios create a social context to which the personas exist in, and also create an actual physical world, instead of imagining a character with internal characteristics from gathered data an nothing else; there is more action involved in the persona's existence. A scenario is also more easily understood by people, since it is in the form of a story, and is easier to follow.

Use case

In short, a use case describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world.

It is represented as a series of simple steps for the character to achieve his or her goal, in the form of a cause-and effect scheme. A use case should:

• Describe what the system shall do for the actor to achieve a particular goal. 
• Include no implementation-specific language. 
• Be at the appropriate level of detail. 
• Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.

Use cases are useful because they help identify useful levels of design work. They allow the designers to see the actual low level processes that are involved for a certain problem, which makes the problem easier to handle, since certain minor steps and details the user makes are exposed. They also convey useful and important tasks where the designer can see which one are of higher importance than others.

Tomorrow: tools of information architecture.

User-Centered Design

User-centered design (UCD) is a design philosophy and a process in which the needs, wants, and limitations of end users of a product are given attention at each stage of the design process. 

User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to use a product, but also to test the validity of their assumptions with regards to user behaviour in real world tests with actual users. 

Such testing is necessary as it is often very difficult for the designers of a product to understand intuitively what a user of their design experiences, and what each user's learning curve may look like. The main difference from other product design philosophies is that user-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product. 

For example, the user-centered design process can help software designers to fulfill the goal of a product engineered for their users. User requirements are considered right from the beginning and included into the whole product cycle. These requirements are noted and refined through investigative methods including: ethnographic study, contextual inquiry, prototype testing, usability testing and other methods. 

Generative methods may also be used including: card sorting, affinity diagraming and participatory design sessions. In addition, user requirements can be understood by careful analysis of usable products similar to the product being designed. 

UCD answers questions about users and their tasks and goals, then uses the findings to make decisions about development and design. UCD of a web site, for instance, seeks to answer the following questions:

• Who are the users of the document? 
• What are the users’ tasks and goals? 
• What are the users’ experience levels with the document, and documents like it? 
• What functions do the users need from the document? 
• What information might the users need, and in what form do they need it? 
• How do users think the document should work? 

As examples of UCD viewpoints, the essential elements of UCD of a web site are considerations of visibility, accessibility, legibility and language. 

Visibility 

Visibility helps the user construct a mental model of the document. Models help the user predict the effect(s) of their actions while using the document. Important elements (such as those that aid navigation) should be emphatic. Users should be able to tell from a glance what they can and cannot do with the document. 

Accessibility 

Users should be able to find information quickly and easily throughout the document, regardless of its length. Users should be offered various ways to find information (such as navigational elements, search functions, table of contents, clearly labeled sections, page numbers, color coding, etc). Navigational elements should be consistent with the genre of the document. 

"Chunking" is a useful strategy that involves breaking information into small pieces that can be organized into some type meaningful order or hierarchy. The ability to skim the document allows users to find their piece of information by scanning rather than reading. Bold and italic words are often used. 

Legibility 

Text should be easy to read: Through analysis of the rhetorical situation, the designer should be able to determine a useful font style. Ornamental fonts and text in all capital letters are hard to read, but italics and bolding can be helpful when used correctly. Large or small body text is also hard to read. (Screen size of 10-12 pixel sans serif and 12-16 pixel serif is recommended.) High figure-ground contrast between text and background increases legibility. Dark text against a light background is most legible. 

Language 

Depending on the rhetorical situation, certain types of language are needed. Short sentences are helpful, as well as short, well-written texts used in explanations and similar bulk-text situations. Unless the situation calls for it, do not use jargon or technical terms. Many writers will choose to use active voice, verbs (instead of noun strings or nominals), and simple sentence structure. 

A user-centered design is focused around the rhetorical situation. The rhetorical situation shapes the design of an information medium. There are three elements to consider in a rhetorical situation: audience, purpose, and context. 

Audience 

The audience is the people who will be using the document. The designer must consider their age, geographical location, ethnicity, gender, education, etc. 

Purpose 

The purpose is what the document is targeting to or what problem is the document trying to address. 

Context 

The context is the circumstances surrounding the situation. The context often answers the question: What situation has prompted the need for this document? Context also includes any social or cultural issues that may surround the situation. 

User-centered design involves simplifying the structure of tasks, making things visible, getting the mapping right, exploiting the powers of constraint, and designing for error.

Tomorrow, I will talk about analysis tools used in user-centered design.

Information Architecture and Usability

The distinction between information architecture and usability may seem like semantics, but there are significant differences between the two disciplines.

Though they are often discussed interchangeably, and practitioners are often well-versed in both, information architecture and usability differ in their scope and areas of focus.

The difference between information architecture and usability is important to understand because information architecture is more than just understanding what users want and need. A usability-only approach to information architecture is only one piece of the puzzle.

Information architecture problems often account for a large percentage of usability problems, but there are many other things unrelated to information architecture that have an impact on usability.

Usability encompasses two related concepts:

• Usability is an attribute of the quality of a system: "we need to create a usable intranet". 
• Usability is a process or set of techniques used during a design and development project: "we need to include usability activities in this project". 

In both cases usability is a broader concept, whereas information architecture is far more specific.

Usability is a detailed subject, taking into account things like font size, colors, visual proximity, usage context, search, error messages, navigation, form design, and labeling. Of these, only a few are true information architecture issues. Navigation, labeling, site architecture and search results all have an impact on the usability of a site, but they are not the only things that affect usability.

An effective information architecture is one of a number of attributes of a usable system. Other factors involving the usability of a system include:

• visual design 
• interaction design 
• functionality 
• content writing 

The process for creating an effective information architecture is a sub-set of the usability activities involved in a project. Although weighted to the beginning of the project, usability activities should continue throughout a project and evaluate issues beyond simply the information architecture.

In terms of great usability information architecture, it is the information architecture that makes it easy for users to find desired information or functionality. On a website, the information architecture can also add important context to the current page (for example when a user begins their visit deep within the website, having come directly from a search engine).

A "bricks and mortar" architect must balance the demands of aesthetics, structural integrity, heating, lighting, water supply and drainage when creating building blueprints. Similarly, an information architect must create navigation schemes for web sites, content management systems, etc. that are at once concise, descriptive, mutually-exclusive, and intuitive. Both types of architects seek to create spaces for humans that are safe, predictable, enjoyable, and inspiring.

Usable navigation systems should: 

• Be easy to learn. 
• Be consistent throughout the web site, CMS, etc. 
• Provide feedback, such as the use of breadcrumbs to indicate how to navigate back to where the user started. 
• Use the minimum number of clicks to arrive at the next destination. 
• Use clear and intuitive labels, based on the user’s perspective and terminology. 
• Support user tasks. 
• Have each link distinct from other links. 
• Group navigation into logical units. 
• Avoid making the user scroll to get to important navigation or submit buttons. 
• Not disable the browser’s back button. 

Steps to develop an intuitive information architecture: 

1. Find out what the mission or purpose of the website is: why will people come to your site?

2. Determine the immediate and long-range goals of the site: are they different?

3. Pinpoint the intended audiences and conduct a requirements analysis for each group.

4. Collect site content and develop a content inventory.

5. Determine the website’s organizational structure, which can include:

• hierarchical
• narrow and deep 
• broad and shallow 
• sequential  
• tag-based 

6. Create an outline of the site, which can include:

• Content Inventory: a hierarchical view of the site content, typically in a spreadsheet format, which briefly describes the content that should appear on each page and indicates where pages belong in terms of global and local navigation. 
• Site Maps: visual diagrams that reflect site navigation and main content areas. They are usually constructed to look like flowcharts and show how users will navigate from one section to another. Other formats may also indicate the relationships between pages on the site. 

7. Create a visual blueprint of the site, which can include:

• Wireframes: rough illustrations of page content and structure, which may also indicate how users will interact with the website. These diagrams get handed off to a visual designer, who will establish page layout and visual design. Wireframes are useful for communicating early design ideas and inform the designer and the client of exactly what information, links, content, promotional space, and navigation will be on every page of the site. Wireframes may illustrate design priorities in cases where various types of information appear to be competing. 

8. Define the navigation systems:

• Global navigation: Global navigation is the primary means of navigation through a website. Global navigation links appear on every page of the site, typically as a menu located at the top or side of each web page. 
• Local navigation: Local links may appear as text links within the content of a page or as a submenu for a section of the website. Local navigation generally appears in the left-hand margin of a web page and sometimes is placed below the global navigation. 
• Utility links: Utility links appear in the header or footer of every page. These may include infrequently used links such as: Contact Us, About Us, Customer Support, Customer Feedback, Privacy Policy, Terms of Use, Site Map, Press Room, etc. Search boxes often appear in the header of the site as well, so the Search feature is available on every page of the site. 

9. Conduct user research. Once you have a draft navigation structure, conduct appropriate usability research to collect feedback from the target audience. Methods may include: card sorting, cognitive walkthroughs, contextual task analyses, and usability testing.

Information Architecture Styles

There are two main approaches to defining an information architecture. They are:

Top-down information architecture

This involves developing a broad understanding of the business strategies and user needs, before defining the high level structure of site, and finally the detailed relationships between content.

Bottom-up information architecture 

This involves understanding the detailed relationships between content, creating walkthroughs (or storyboards) to show how the system could support specific user requirements and then considering the higher level structure that will be required to support these requirements.

Both of these techniques are important in a project. A project that ignores top-down approach may result in well-organized, findable content that does not meet the needs of users or the business. A project that ignores bottom-up approach may result in a site that allows people to find information but does not allow them the opportunity to explore related content. Take a structured approach to creating an effective information architecture.

The following steps define a process for creating an effective information architecture:

1. Understand the business/contextual requirements and the proposed content for the system. Read all existing documentation, interview stakeholders and conduct a content inventory.
2. Conduct cards sorting exercises with a number of representative users.
3. Evaluate the output of the card sorting exercises. Look for trends in grouping and labeling.
4. Develop a draft information architecture (i.e. information groupings and hierarchy).
5. Evaluate the draft information architecture using the card-based classification evaluation technique.
6. Don’t expect to get the information architecture right first time. Capturing the right terminology and hierarchy may take several iterations.
7. Document the information architecture in a site map. This is not the final site map, the site map will only be finalized after page layouts have been defined.
8. Define a number of common user tasks, such as finding out about how to request holiday leave. On paper sketch page layouts to define how the user will step through the site. This technique is known as storyboarding.
9. Walk other members of the project team through the storyboards and leave them in shared workspaces for comments.
10. If possible within the constraints of the project, it is good to conduct task-based usability tests on paper prototypes as it provides valuable feedback without going to the expense of creating higher quality designs. Create detailed page layouts to support key user tasks. Page layouts should be annotated with guidance for visual designers and developers.

Developing an information architecture in this way enables you to design and build a system confident that it will be successful. It simply isn’t good enough for organizations to build functionality or write content, put it on their computer systems and expect people to be able to find it.

Developing an effective information architecture is an essential step in the development of all computer systems. Effective information architectures enable people to quickly, easily and intuitively find content. This avoids frustration and increases the chance that the user will return to the system the next time they require similar information.

Remember: people can only appreciate what they can actually find.

Information Architecture

Information architecture is defined by the Information Architecture Institute as the art and science of organizing and labeling web sites, intranets, online communities, and software to support findability and usability.

Information architecture is the term used to describe the structure of a system, i.e the way information is grouped, the navigation methods and terminology used within the system. An effective information architecture enables people to step logically through a system confident they are getting closer to the information they require. Information architecture is most commonly associated with websites and intranets, content management systems, but it can be used in the context of any information structures or computer systems.

Information architecture involves the categorization of information into a coherent structure, preferably one that the intended audience can understand quickly, if not inherently, and then easily retrieve the information for which they are searching. The organization structure is usually hierarchical.

Organizing functionality and content into a structure that people are able to navigate intuitively doesn’t happen by chance. Organizations must recognize the importance of information architecture or else they run the risk of creating great content and functionality that no one can ever find. Most people only notice information architecture when it is poor and stops them from finding the information they require.

An effective information architecture comes from understanding business objectives and constraints, the content, and the requirements of the people that will use the site.

Information architecture is often described using the following diagram:

Business/Context 

Understanding an organization's business objectives, politics, culture, technology, resources and constraints is essential before considering development of the information architecture. Techniques for understanding context include:

• reading existing documentation;
• mission statements, organization charts, previous research and vision documents are a quick way of building up an understanding of the context in which the system must work;
• stakeholder interviews;
• speaking to stakeholders provides valuable insight into business context and can unearth previously unknown objectives and issues. 

Content

The most effective method for understanding the quantity and quality of content (i.e. functionality and information) proposed for a system is to conduct a content inventory. Content inventories identify all of the proposed content for a system, where the content currently resides, who owns it and any existing relationships between content. Content inventories are also commonly used to aid the process of migrating content between the old and new systems.

Users 

An effective information architecture must reflect the way people think about the subject matter. Techniques for getting users involved in the creation of an information architecture include card sorting and card-based classification evaluation.

Card sorting involves representative users sorting a series of cards, each labelled with a piece of content or functionality, into groups that make sense to them. Card sorting generates ideas for how information could be grouped and labelled.

Card-based classification evaluation is a technique for testing an information architecture before it has been implemented. The technique involves writing each level of an information architecture on a large card, and developing a set of information-seeking tasks for people to perform using the architecture.

More about information architecture next time...

Engineering Change Process

Let's look at the engineering change process and how Engineering Change Order (ECO) is used in this process.

The stages of the engineering change process are:

1. Issue identification & scoping:

Someone identifies a problem or issue and determines that it may require a change. The scope of the issue and its possible impact are estimated.

2. ECR creation:

An engineering change request (ECR) is created to examine the necessity and feasibility of the change, to identify parts, components and documentation that might be affected, to estimate costs and to list the resources required to implement the change.

3. ECR review:

The ECR is circulated for review and discussion among key stakeholders and is modified as needed.

4. ECO creation:

Once the ECR is approved, an engineering change order (ECO) is generated, which lists the items, assemblies and documentation being changed and includes any updated drawings, CAD files, standard operating procedures (SOPs) or manufacturing work instructions (MWIs) required to make a decision about the change.

5. ECO review: The ECO is then circulated to a change review board made up of all stakeholders (including external partners when appropriate) who need to approve the change.

6. ECN circulation:

Once the ECO has been approved, an engineering change notification/notice (ECN) is sent to affected individuals to let them know that the ECO has been approved and the change should now be implemented.

7. Change implementation:

Those responsible for implementation use the information in the ECO and ECN to make the requested change. While an engineering change order is used for changes that are executed by engineering, other types of change orders may be used by other departments. These include the:

• Manufacturing change order (MCO) — A change order describing modifications to the manufacturing process or equipment.

• Document change order (DCO) — A change order detailing modifications to documents, specifications or SOPs.

ECO benefits

While you may groan at the prospect of pulling together another set of documentation, an ECO is a critical part of keeping product development on track and making sure product information is accurate. A good ECO contains the full description, analysis, cost and impact of a change, and a good ECO process ensures that all stakeholders have bought in to the change. Having an organized method of handling product changes reduces potential design, manufacturing and inventory errors, minimizes development delays and makes it easy to get input from different departments, key suppliers and contract manufacturers.

Following good ECO practices also makes it easy to document a full history of what changes have been made to a product and when they occurred. In industries with regulatory requirements, like the medical device industry, having a full history of every change to a product is mandatory. Depending on the industry, change orders and even the change process itself may be audited by a regulatory body. Keeping a record of product changes will also help you debug any problems that occur after your product launches. The task of identifying and fixing the root cause of any problem is easier when you have a complete product change history.

Without a clear ECO process in place, making a change to a product can set off a chain of costly, time-consuming and avoidable events. Take a part switch that happens late in the development process. Engineering may tell manufacturing to be aware of the new part, but if that information is never conveyed to the purchasing department, the old part will be ordered. When the components arrive, manufacturing will not be able to assemble the product, and its launch will be delayed until the new part is obtained (most likely with some rush charges incurred along the way).

Engineering change orders make it possible to accurately identify, address and implement product changes while keeping all key stakeholders in the loop and maintaining a historical record of your product. Without them, miscommunications occur that lead to delays, incorrect purchase orders and improper product builds.

Companies need to be able to adapt quickly in today’s constantly changing environment, and often that means making changes to their products. Engineers make modifications during development and production with the intent of adding functionality, improving manufacturing performance or addressing the availability of a particular part.

To make sure proposed changes are appropriately reviewed, a solid process is critical, especially if members of your product team are scattered across multiple locations (for instance, design engineers in Boston, the manufacturing team in St. Louis and component manufacturers all over the world). At the heart of a solid change process is the engineering change order.

Engineering Change Orders: Paper-Based vs. Electronic Documentation Systems

	Managing Paper ECO	Managing Electronic ECO
Cycle Time	·         ECO is generally reviewed one person at a time. ·         If multiple copies are distributed, edits must be consolidated and reviewed again. ·         Paper ECO can be misplaced ECO review can be a long process (weeks).	·         ECO can be reviewed by many people  at  once. ·         All edits are made to a single version, so no consolidation is needed. ·         ECO is always available online.ECO review is significantly shorter process (days).
Signature Process	·         Early approvers won’t be aware of edits, necessitating additional rounds of review. ·         Official approval disappears if the ECO file is lost. ·         Harder to maintain clean, complete history of changes.	·         All approvers sign off on the same set of documentation. ·         Electronic signature is 21 CFR part 11 compliant, a requirement for the medical device industry. ·         Automatic maintenance of clean history for audits.
Issue Resolution	·         Individuals need to be tracked down to resolve problems. ·         May need to wait for change control review board meeting to connect with other approvers.	·         People’s comments can be viewed, so hold-ups can be quickly resolved ·         Can easily see who hasn’t signed and request approval electronically.
Package Format	·         Large paper file of documents and drawings must be printed. ·         Tedious and labor-intensive to pull together information from many locations.	·         Electronic documentation is environmentally friendly. ·         Easy to create and access ECO when managed in the same system as underlying product information.

Document Control

The primary purpose of document control is to ensure that only current documents and not documents that have been superseded are used to perform work and that obsolete versions are removed. Document control also ensures that current documents are approved by the competent and responsible for the specific job persons and are distributed to the places where they are used. In regulated industries, this function is mandatory.

If a company is ISO 9001 compliant, it has document control it place. Document control is a part of ISO 9001 and GMP/GxP requirements.

There are four steps in the document control system:

1. Define the scope of the document control system (which documents must be controlled).

2. Develop a document authorization or approval system.

3. Ensure that only current versions of documents are used at the work places where they are used.

4. Out of date documents that need to be archived must be suitably identified.

Let's look at these steps more closely.

1. Identify which documents need to be controlled

The first task is to identify which documents need to be controlled.

The most important rule of document control is that only current documents must be used for work. You may find that other documents are less vital and it may not be worth the effort of controlling them.

You may even decide to have different levels of document control for different types of documents, e.g. formal approval and controlled distribution for procedures and work instructions, controlled distribution for your list of legal requirements, etc.

2. Define a document approval system

An approval/authorization system ensures that distributed documents are appropriate for persons receiving them. A responsible person must approve these documents. This approval can be in two different forms: on paper documents it will be a signature, on electronic documents it will be either electronic signature or they may only be published when they are approved. If there is no electronic signature, the approval usually can be verified through electronic workflow the document went through to get approved.

When a new document is created or a document is going through a change, Engineering Change Order (ECO) is used to document and approve the document creation or changes. It can also be called Engineering Change Notice (ECN) or Document Change Notice (DCN). ECO outlines the proposed change, lists the product or part(s) that would be affected and requests review and approval from the individuals who would be impacted or charged with implementing the change. ECOs are used to make modifications to components, assemblies, associated documentation and other types of product information.

The change process starts when someone identifies an issue that may need to be addressed with a change to the product. It ends when the agreed-upon change is implemented. ECOs are used in between to summarize the modifications, finalize the details, and obtain all necessary approvals.

3. Assure appropriate distribution

During this step, you need to make sure that everyone who needs the document gets a copy.

Distribution may be physical (paper documents) or electronic. When posting the document on intranet or other electronic systems, ensure that everybody who needs to have the new document knows about the posting (e.g. through an email or workflow notifications). When distribution is physical (paper documents), documents need to be stamped to identify that this is a controlled document and that a user of this document needs to verify that this is the most current version before starting work.

An inventory of controlled documents should be created with the exact location of each controlled document.

4. Remove old and obsolete documents

This is easy if you use an electronic documentation management system but is more complicated with paper documents.

You may request the receiver of new documents to send back obsolete ones. If for some reason you need to retain obsolete versions of documents, they need to be marked to avoid unintended use. Many organisations use a stamp: "obsolete document".

Next time: I am going to talk more about ECO and engineering change process.

CMS Types

There are three major types of CMS: offline processing, online processing, and hybrid systems. These terms describe the deployment pattern for the CMS in terms of when presentation templates are applied to render content output from structured content.

Offline processing

These systems pre-process all content, applying templates before publication to generate Web pages. Since pre-processing systems do not require a server to apply the templates at request time, they may also exist purely as design-time tools.

Online processing

These systems apply templates on-demand. HTML may be generated when a user visits the page or pulled from a cache. Most open source CMS have the capability to support add-ons, which provide extended capabilities including forums, blog, wiki, web stores, photo galleries, contact management, etc. These are often called modules, nodes, widgets, add-ons, or extensions. Add-ons may be based on an open-source or paid license model. Different CMS have significantly different feature sets and target audiences.

Hybrid systems

Some systems combine the offline and online approaches. Some systems write out executable code (e.g., JSP, ASP, PHP, ColdFusion, or Perl pages) rather than just static HTML, so that the CMS itself does not need to be deployed on every web server. Other hybrids operate in either an online or offline mode.

There are literally thousands of content management systems available on the internet. Each one caters to different users offering a variety of features which are consistent across all sites.

There are four main types of content management systems that each of the thousands fall under. The systems include:

1) Homegrown

2) Commercial

3) High-end

4) Open Source

Homegrown content management systems are software created by a single development company for their own use of their own products. Consequently, every aspect of the system is catered to their specific needs since they are the only organization utilizing it. The main issue is the development company relies on a single vendor to fix the bugs and create patches.

The second type is commercial content management systems. This is the most widespread offering many different pricing options, plans and features. Unlike homegrown systems, these are rarely customizable.

The third type is high-end content management systems. One nice feature is their reliability as high-end content management systems deliver robust solutions.

The final content management system is open source. This essentially means that the software is available to anyone for free. The primary advantages are the price (free!) and that these systems are fully customizable since its open source code. The main limitation is the quality of the product. They often lack stability, security, and support of certain infrastructures as you would often expect from free software.

The selection of the type of content management system is based on a customer's need. If they are a company that needs customization and price is not an issue, a homegrown system or high-end system might be the most viable option.

On the other hand, if a price tag is problematic and customization is not important then a commercial content management system is the best choice. Finally, if the consumer is not concerned with stability, security and support and likes the price tag and customization options, open source is the way to go.

Like any type of product, you get what you pay for. Those that have the money will purchase the best content management system, those that do not will function with a potentially unreliable product. Either way, the selection is based on an individual need and due to the availability of thousands of content management systems, there are many options out there.

Content Management Systems (CMS)

In order to efficiently manage content, a content management system is required. A CMS is a tool that enables a variety of (centralised) technical and (de-centralised) non technical staff to create, edit, manage and finally publish (in a number of formats) a variety of content (such as text, graphics, video, documents etc), whilst being constrained by a centralised set of rules, process and workflows that ensure coherent, validated electronic content.

A Content Management System (CMS) has the following benefits:

1. allows for a large number of people to contribute to and share stored data;
2. increased ability for collaboration;
3. facilitates document control, auditing, editing, and timeline management;
4. controls access to data, based on user roles. User roles define what information each user can view or edit;
5. aids in easy storage and retrieval of data;
6. reduces repetitive duplicate input;
7. documents workflow tasks coupled with messaging which allow for formal review and approval of documents;
8. the ability to track and manage multiple versions of a single instance of content.

Content Management Systems come in all shapes and sizes. The most known and used CMS are: Microsoft SharePoint, Interwoven, Vignette, Documentum, Livelink, Oracle ECM suite. There are also open source CMS. The most known are Alfresco, Drupal, Joomla.

One of CMS types is web content management system WCMS. It can be used to control a dynamic collection of web material, including HTML documents, images, and other forms of media.

A CMS typically has the following features:

Automated templates

Create standard output templates (usually HTML and XML) that can be automatically applied to new and existing content, allowing the appearance of all content to be changed from one central place.

Access Control

CMS systems support user groups. User groups allow you to control how registered users interact with the site. A page on the site can be restricted to one or more groups. This means if an anonymous user (someone not logged on) or a logged on user who is not a member of the group a page is restricted to, the user will be denied access to the page.

Scalable expansion

Available in most modern CMSs is the ability to expand a single implementation (one installation on one server) across multiple domains, depending on the server's settings. CMS sites may be able to create microsites/web portals within a main site as well.

Easily editable content

Once content is separated from the visual presentation of a site, it usually becomes much easier and quicker to edit and manipulate. Most CMS software includes WYSIWYG editing tools allowing non-technical individuals to create and edit content.

Scalable feature sets

Most CMS software includes plug-ins or modules that can be easily installed to extend an existing site's functionality.

Web standards upgrades

Active CMS software usually receives regular updates that include new feature sets and keep the system up to current web standards.

Workflow management

Workflow is the process of creating cycles of sequential and parallel tasks that must be accomplished in the CMS. For example, one or many content creators can submit a story, but it is not published until the copy editor cleans it up and the editor-in-chief approves it.

Collaboration

CMS software may act as a collaboration platform allowing content to be retrieved and worked on by one or many authorized users. Changes can be tracked and authorized for publication or ignored reverting to old versions. Other advanced forms of collaboration allow multiple users to modify (or comment) a page at the same time in a collaboration session.

Delegation

Some CMS software allows for various user groups to have limited privileges over specific content on the website, spreading out the responsibility of content management.

Document management

CMS software may provide a means of collaboratively managing the life cycle of a document from initial creation time, through revisions, publication, archive, and document destruction.

Content virtualization

CMS software may provide a means of allowing each user to work within a virtual copy of the entire web site, document set, and/or code base. This enables changes to multiple interdependent resources to be viewed and/or executed in-context prior to submission.

Content syndication

CMS software often assists in content distribution by generating RSS and Atom data feeds to other systems. They may also e-mail users when updates are available as part of the workflow process.

Multilingual

Ability to display content in multiple languages.

Versioning

CMS allows the process of versioning by which documents are checked in or out of the CMS, allowing authorized editors to retrieve previous versions and to continue work from a selected point. Versioning is useful for content that changes over time and requires updating, but it may be necessary to go back to or reference a previous copy.

Next time: CMS Types

What is DITA?

The Darwin Information Typing Architecture (DITA) is an XML-based architecture for authoring, producing, and delivering information. Although its main applications have so far been in technical publications, DITA is also used for other types of documents such as policies and procedures. The DITA architecture and a related DTD and XML Schema were originally developed by IBM. The architecture incorporates ideas in XML architecture, such as modular information architecture, various features for content reuse, and specialization, that had been developed over previous decades. DITA is now an OASIS standard.

The first word in the name "Darwin Information Typing Architecture" is a reference to the naturalist Charles Darwin. The key concept of "specialization" in DITA is in some ways analogous to Darwin's concept of evolutionary adaptation, with a specialized element inheriting the properties of the base element from which it is specialized.

DITA content is written as modular topics, as opposed to long "book-oriented" files. A DITA map contains links to topics, organized in the sequence (which may be hierarchical) in which they are intended to appear in finished documents. A DITA map defines the table of contents for deliverables. Relationship tables in DITA maps can also specify which topics link to each other. Modular topics can be easily reused in different deliverables. However, the strict topic-orientation of DITA makes it an awkward fit for content that contains lengthy narratives that do not lend themselves to being broken into small, standalone chunks. Experts stress the importance of content analysis in the early stages of implementing structured authoring.

Fragments of content within topics (or less commonly, the topics themselves) can be reused through the use of content references (conref), a transclusion mechanism.

DITA includes extensive metadata elements and attributes, which make topics easier to find.

DITA specifies three basic topic types: Task, Concept and Reference. Each of the three basic topic types is a specialization of a generic Topic type, which contains a title element, a prolog element for metadata, and a body element. The body element contains paragraph, table, and list elements, similar to HTML.

A Task topic is intended for a procedure that describes how to accomplish a task. A Task topic lists a series of steps that users follow to produce an intended outcome. The steps are contained in a taskbody element, which is a specialization of the generic body element. The steps element is a specialization of an ordered list element. Concept information is more objective, containing definitions, rules, and guidelines.

A Reference topic is for topics that describe command syntax, programming instructions, and other reference material, and usually contains detailed, factual material. DITA allows adding new elements and attributes through specialization of base DITA elements and attributes. Through specialization, DITA can accommodate new topic types, element types, and attributes as needed for specific industries or companies.

The extensibility of DITA permits organizations to specialize DITA by defining specific information structures and still use standard tools to work with them. The ability to define company-specific information architectures enables companies to use DITA to enrich content with metadata that is meaningful to them, and to enforce company-specific rules on document structure. DITA map and topic documents are XML files. As with HTML, any images, video files, or other files which need to appear in output are inserted via reference. Any XML editor can therefore be used to write DITA content, with the exception of editors that support only a limited set of XML schemas (such as XHTML editors). Various editing tools have been developed that provide specific features to support DITA, such as visualization of conrefs.

Next time: technology for managing content.