igx web cms buyers guide

8/13/2019 Igx Web CMS Buyers Guide

http://slidepdf.com/reader/full/igx-web-cms-buyers-guide 1/20

Web Experience Management

WHITE PAPER

Ingeniux Corporaon

Web CMS Buyer’s Guide

IntroduconThe amount of digital content and media managed by private

and public organizaons has grown exponenally in the last

few years. Websites have also become complex. For many

organizaons, managing the web requires opmizing online

markeng, delivering localized versions of content for country

sites, creang online communies, supporng a myriad of

mobile devices, and meeng key compliance requirements.

Enter the web content management system (web CMS). Web

CMS soware empowers organizaons to cost-eecvelymanage the web while maximizing results from online programs

and communicaons.

Web CMS soware is as business crical for most organizaons

as a customer relaonship management system (CRM),

enterprise resource planning system (ERP), or any other key

business applicaon. Yet most organizaons do not have an

eecve way to evaluate a web CMS. This is complicated by the

sheer number of web CMS soluons on the market, the industry

markeng hype, and the wide range of use cases web CMS

soware supports.

This buyer’s guide is aimed at helping organizaons understand

how to evaluate and buy a web CMS. It outlines the key use

cases, features, types of systems, and success factors in selecng

a web CMS. While not an end-all guide to the web CMS market,

it does provide a starng point in understanding web CMS

soware and a framework for evaluang the merits of dierent

types of systems.

What is a Web CMS?

A denion of web CMS may be summarized as, “Soware

that allows non-technical business users to manage content

throughout its enre life cycle.”

This denion is about the only thing that many web CMS

C O N T E N T S

Introducon . . . . . . . . . . . . . . . . . . . . . . . 1

What is a Web CMS? . . . . . . . . . . . . . . . . 1

How to Buy a Web CMS . . . . . . . . . . . . . 2

Success Factors . . . . . . . . . . . . . . . . . . . . 3

Web CMS Features . . . . . . . . . . . . . . . . . 4

Web CMS Use Cases . . . . . . . . . . . . . . . . 6

Types of Web CMS . . . . . . . . . . . . . . . . . . 8

Key Web CMS Capabilies . . . . . . . . . . . 10

Understanding Deployment . . . . . . . . . 16

Web CMS Implementaon . . . . . . . . . . 17

Web CMS Template Approaches . . . . . 17

Buying a Web CMS (Again) . . . . . . . . . . 18

Our Best Advice . . . . . . . . . . . . . . . . . . . 19

A B O U T I N G E N I U X

A leading provider of web content

management soware, Ingeniux

empowers organizaons to manage

world-class websites and vibrant

online communies across web,

mobile, and tablet plaorms.

Discover what Ingeniux can do for you.

Call (877) 445-8228

Email [email protected]

Visit www.ingeniux.com




WEB CMS BUYER’S GUIDE WHITE PAPER

2

soluons hold in common. As this buyer’s guide illustrates, there are a wide range of web CMS soluons

and use cases. There is also a wide range of terms and acronyms used to describe a web CMS – from

customer experience management (CXM), to web experience management (WEM), to content

management system (CMS). This buyer’s guide uses the term web CMS to encompass all of the soluons

named above.

How to Buy a Web CMS

First and foremost, buyers should understand that there

is no best web CMS. There is only a best web CMS relave

to buyers’ requirements. It is therefore important that

buyers thoroughly understand what their requirements

are, based on every user conngency within the company.

That understanding should then be mapped to an equally

well-dened understanding of currently available webCMS plaorms. This is more easily said than done since

companies oen have diculty understanding exactly what their users need, as well as what the

dierent web CMS plaorms actually oer. But the guiding principle in the purchase decision should be

as close as possible to a 1:1 match between what a buyer needs and what a product oers.

Use cases. A praccal approach to tesng the match between requirements and soluons is to dene

use cases. That is, how do those involved in the content life cycle interact with the web CMS. How do

they use it? What are their goals? Dening your key use cases is an essenal rst step in evaluang a

web CMS.

Budget. Before making a decision on what web CMS soluons are feasible, buyers must know whatpurchase resources are available. It makes no sense to test a $200,000 web CMS license if only $75,000

is available. Similarly, even when funds are available, it makes no sense to overspend. Once the web CMS

budget is known, buyers should build the business case both to jusfy the expense and to ensure that

money is not being wasted. In this acvity, it will be important to get an idea of what the total cost of

ownership (TCO) of any potenal web CMS will be over a three to ve year period.

Total cost of ownership (TCO). Included in the TCO are several components. The rst important

component is license cost. This is the amount buyers will pay to purchase the applicaon for its

parcular conguraon (number of servers, content editors, bandwidth, etc). Typically understood as the

“price” of a web CMS, the license cost over several years typically represents one quarter to one third

the TCO. The cost of implementaon is oen equal to or slightly greater than the cost of the license. For

a base license of $75,000, implementaon costs typically range from $60,000 to $90,000 – or roughly

80 percent to 120 percent of the license cost. Buyers should be aware that implementaon costs vary

widely between web CMS products.

Annual support and maintenance. For technical support and maintenance, which includes product

upgrades, buyers should expect to pay 20 percent of license costs annually. For a $75,000 license,

“First and foremost, buyers should

understand that there is no best web

CMS. There is only a best web CMS

relave to buyers’ requirements.”





3

$15,000 annually will be spent on support and maintenance.

Administraon and support. IT resources will be required to administer the system over me. Buyers

should aempt to esmate how many full-me employees will be required to do this, and they should

calculate the burdened cost of such resources as part of the TCO of the web CMS.

Product usability. While not commonly considered a factor in TCO, product usability correlates directly

to user adopon rates. When products are not easily learned and used by content contributors, a

common result is implementaon abandonment. This can result in a complete loss of all resources

invested in the project. A less dramac impact of poor usability is the increased me – and therefore

expense – required to create, manage, and re-use content.

Alternate pricing models. In addion to on-premise

soware licenses, some web CMS’ are available as a service

(SaaS). SaaS pricing is generally a recurring subscripon fee,

either monthly or annually, that includes soware licensing,

support and maintenance, and soware hosng. Because

SaaS includes all of the applicaon management and

hosng services, the TCO of SaaS oerings tends to be 50 to

60 percent less than on-premise costs.

Success Factors

Crical to the success of any web CMS purchase decision is buy-in throughout the organizaon.

Especially important is top-down support, where the crical nature of managing content eecvely is

understood throughout the company. Yet it is equally important for content contributors to make their

requirements known. In short, every level of the organizaon needs to buy into the crical nature of the

business case for a web CMS.

As an integral part of the business case, web CMS buyers should strive to arculate as clearly as possible

how the web CMS will allow them to engage customers online. The boom line always comes down

to how relaonships with customers can be improved. In the case of web CMS, this is normally the

online interacon. Improved branding, customer loyalty, content personalizaon, and mul-channel

management all contribute to a richer experience, and therefore to improved revenues – either directly

or indirectly.

The importance of web CMS usability cannot be overstated. With it, implementaons have a chance ofsuccess. Without it, they do not. Employees who depend on a web CMS to do their jobs simply will not

put up with applicaons that impede their eciency. If the web CMS slows them down or impedes their

progress, they will simply work around the system. This inevitably leads to implementaon failure.

Excellent customer support is essenal to the mely resoluon of crical issues, which can dramacally

impact company protability. To take but one example, system downme at the wrong me can

“The total cost of ownership (TCO) of

SaaS oerings tends to be 50 to 60percent less than on-premise. ”





4

dramacally compromise the web presence as a whole – think of the markeng campaign that can’t be

viewed for the rst several hours aer a press release, for example. If the web CMS vendor does not

oer 24/7 customer support, or if technical issues cannot be resolved quickly (within several hours),

markeng, sales, and corporate communicaons overall can be impacted. Competors will be happy to

take customers.

The me-to-market, or speed of execung sales and markeng campaigns, is also crical to success.

Gone are the days when one week was a sasfactory me-to-market for an online campaign, for

example. Now it’s more like 24 hours. For that to be a reality, the web CMS must perform well in a

number of categories, usability and web engagement foremost among them.

Finally, all of the consideraons above become moot points if the web CMS vendor you choose isn’t

fundamentally stable. Buyers should ask themselves how vendor strategies and market presence will

contribute to the vendor’s connued success in the market – or even existence – over the next few

years. However, it is important to note that tradionally the independent web CMS vendors have been

the most stable in the market, while larger porolio soware companies have waxed and waned on theirsupport of web CMS applicaons. A small company solely focused on web CMS may have much more

stability compared to a larger company that oers a web CMS as a subset of a larger soluon line.

Web CMS Features

Web CMS applicaons have been around for nearly 15 years. As such, the technology is relavely

mature. While web CMS has not yet become a commodity, it is true that many of the features and

funcons within web CMS’ are common in oerings throughout the industry. Such standard features

include WYSIWYG authoring, visual workow, and template creaon. So, what should buyers of a new

web CMS look for? In our opinion, the disnguishing features of current web CMS systems are in thevalue-added layers that some soluons provide, such as:

Product usability. The primary purpose of a web CMS is to empower non-technical users to manage

the web, removing IT resources from common usage scenarios to reduce costs, maximize resources,

and improve web content management operaons. The user-friendliness of the web CMS is therefore

essenal in the decision-making process. Consider the ease with which a marketer can create an online

promoonal campaign or a casual content contributor can create new, template-based web pages.

Technical foundaon. The languages and technologies with which a web CMS is developed is another

important consideraon in the evaluaon process. This will dene the toolset that can be used to

customize a web CMS to specic customer needs. It will also dene the capabilies you will need

to support the applicaon, the type of sta you need to hire and manage, and, to some extent, the

roadmap for your website and applicaons. If your web team has background in Java development, a

.NET soluon may not be a good t. If you do not have in-house technical capabilies you may be best

serve by a SaaS-based soluon that includes applicaon management.

Flexibility. Web CMS applicaons in the market vary widely in their architectural exibility. Most were





5

developed incrementally over the course of many years, and their development standards were not

consistent over me. Generally speaking, it is dicult to integrate a web CMS that evolved in this

manner with other enterprise applicaons, or even to extend their out-of-the-box feature funconality.

The most exible web CMS systems are those that were conceived as a whole, developed purely within

one language based on a well-arculated set of industry standards, and built in accordance with the

principles of services-oriented architecture (SOA), meaning the components of the plaorm are designed

to operate as self-contained units that can be added and removed from the system at will.

Addional value-added features. Beyond these widely-relevant consideraons is a set of user-specic

criteria that will be determined by the customers’ actual use case scenarios. For organizaons with

mission-crical web markeng iniaves, the quality and applicability of the markeng tools bundled

with the web CMS will be very important. Similarly, for online retail enterprises, the ability to analyze

user behavior and deliver personalized online experiences in support of overall online sales goals will be

crical. For those conducng business across mulple geographies, the ability to manage mulples sites,

in mulple languages, delivered via mulple channels will be a key success factor.

From an operaonal perspecve, scalability is important both as a web CMS is integrated throughout the

business and as seasonal spikes in user acvity put bandwidth/hardware strains on the system (during

holiday seasons, for example). From a technical perspecve, the robustness and quality of development

tools (oen an SDK) dramacally impact how easily and quickly IT can augment system funconality. And

nally, a web CMS’ ease-of-administraon – the resource intensity required to maintain the soware

over me – will dramacally aect the total cost of ownership. As an example, the ability to avoid adding

even one addional IT person can amount to well over $500,000 in savings over three to ve years.

Far more helpful than a feature-funconal checklist comparison, serious reecon on these evaluaon

criteria, as applied to specic use cases, will help buyers disnguish between the various web CMS

oerings on the market.

Web experience management. Recently, the goals of web CMS implementaons have focused on

managing a customer’s enre web experience. These goals commonly involve marshalling all channels

of customer communicaon – parcularly web and mobile – for the purpose of craing a stream of

engaging, interacve, user-specic, carefully coordinated customer communicaons. Web engagement

management (WEM), as we have begun to describe this capability, measures a web CMS’ ability to

deliver these opmized online experiences based on the interests of parcular website visitors. This is

done by assembling the right content and delivering it at the right me, in the right context, based on

the match between permutaons of available content items and the website visitor’s interests. Over

me, a good web CMS will help build detailed proles of users, based on pre-exisng explicit data and

dynamically-captured online behavioral paerns. Oen these user proles are managed in a separatesystem, such as a markeng automaon system, and then leveraged by the web CMS in delivering

targeted content. In this way, a web CMS can become quite good at managing not only the content and

the user, but the interacon between these two and, consequently, the experience itself.





6

Web CMS Use Cases

To delve more deeply into use cases for web CMS we will look at ve of the most common use case

scenarios: public websites, corporate intranets, extranets, community-based sites, and mobile sites.

Public websites, which commonly encompass:

Digital markeng and lead generaon. This feature of public websites is common to most

companies oering online goods, services, and informaon. How does an airline get web visitors

to purchase ckets from them versus a competor? Web CMS’ will commonly have digital markeng

and lead-generaon tools built in that allow marketers to increase the speed of creang markeng

campaigns, incorporang search engine opmizaon, lead-generaon capabilies, analycs

capabilies to monitor user acvity and determine what visitors are interested in, and so on.

Product-based sites. Crical to product-based sites is the ability to structure and categorize

content so that inventory can be eecvely merchandised and displayed in dierent secons of

the website (for example, an air-condioner sold in “Appliances” and “Heang and Cooling”), and

across channels. Also important on this type of site is the ability to combine elements of product

descripons. Here, informaon such as product SKUs, bar codes, descripons, user rangs, images,

availability, pricing, manufacturer informaon, warranty informaon, related products, shipping

informaon, availability in nearby stores, etc. become the crical funconal building blocks.

Member services-based sites. This contains a fairly broad range of use cases, but generally requires

users to log in for access to services based on ered service level agreements. Members may have

access to one part of the site but not others. Alternavely, they may be entled to certain benets

based on their status level or er level, and may not have access to certain informaon beyond that

level. The key for this funconal area of public websites is that services and access to content bebased on users’ membership levels.

E-commerce sites. This is a common use case scenario for public websites, but the complexity of

use cases varies greatly. At the simple end of the range are a limited number of goods or services,

available electronically, and delivered immediately at the me of purchase. The most complex

e-commerce sites maintain extraordinarily diverse inventories, user proles, content types, and

content analycs.

Federated websites. Large organizaons such as universies, government agencies, non-prots, and

corporaons oen manage a signicant number of loosely connected websites. These “federated”

sites are most easily understood as mulple instances of the four use cases described above, with

each department of the university or organizaon running one or more of the aforemenoned

scenarios.

Corporate intranets is the next use case for web CMS implementaons. While not necessarily dierent

from public-facing websites in terms of features or funcons, intranets do tend to share a common set of

unique features and funcons, which include:





7

Human resources service portals. The most common use case for the corporate intranet, the HR

service portal disseminates any and all relevant corporate informaon to internal constuents. This

includes corporate policies, benets, pay informaon, access to employee rerement accounts, stock

opons, payroll and tax informaon, medical benets, etc.

Employee enablement tools. Another typical use for the corporate intranet is the provision of

employee enablement tools, as demonstrated by an intranet sub-site for the sales force that includes

training materials, markeng collateral, price lists, compeve analysis, SLA direcves, etc. Generally

speaking, the goal of the corporate intranet is to expose all corporate informaon in order to enable

employees and disseminate that informaon.

Extranets are analogues to the corporate intranet that extend their funconality to partners and

customers. In this scenario, people outside of the company have log-ins that gain them access to certain

informaon within the content repository. Content access control is applied either at the repository or

database level. Extranets also allow individuals outside the rewall to join internal workows.

Taken together, public-facing sites, intranets, and extranets, are enabled by the core features of the web

CMS. They are simply dierent permutaons of the features exposed to dierent audiences.

Community websites encompass a wide range of features and requirements, including:

Social communies. Social community websites are designed to engage customers with social

features such as user-generated content, media, commenng and moderaon, forums, and social

networking capabilies. Social communies may be used to support brand engagement as well as

many business collaboraon scenarios.

Informaon portals. Primarily serve to disseminate informaon to constuents. Common examples

include state and local governments, nonprots, user groups and forums. Among the more complex

instances of such websites are state government services portals in which transaconal services are

provisioned to cizens.

Managing a community website oen requires soluons beyond a web CMS, although some web

CMS soluons do provide community management and moderaon capabilies, including member

management, acvity streaming and nocaons, forums and blogs, and business collaboraon for

documents and shared workspaces. If supporng communies is crical for your organizaon it will be

important to evaluate whether the web CMS can support the needs of the community or whether you

are beer served integrang a standalone community soware package.

Mobile websites, including mobile and other compung formats, such as tablets and kiosks, are a

disnct use case for many considering a web CMS implementaon. Mobile websites can support all

of the use cases listed above, as well as mobile applicaons. Generally, a mobile website will deliver a

task-based user experience, support opmal layout on a wide range of devices, and feature mul-touch

interacons for tapping and swiping elements of the websites. Mobile websites may also take advantage

of device capabilies, such as local storage, cameras, GPS, and other features.





8

Types of Web CMS

In considering the type of web CMS that is right for your business, ve key comparisons to keep in mind

are publishing systems vs. development frameworks, database vs. le-based systems, soware-as-a-

service (SaaS) vs. on-premise plaorms, and open source vs. commercial systems.

Publishing systems vs. development frameworks. In making a decision for a parcular web CMS,

perhaps the most important decision is whether you need a publishing system or a development

framework. Publishing systems are characterized by the ease with which they allow for the creaon,

management, and deployment of content. Ideally, publishing systems are ready to use out-of-the-box,

have short implementaon mes, and make managing the content life cycle simple at each stage. Much

of the heavy technical liing in publishing systems as we describe them here is handled by the web

CMS itself. Publishing systems are also characterized by the scope of requirements they address, which

typically begin with content authorship and connue through workow approvals, publishing, re-use,

deployment, and archiving.

Development frameworks, on the other hand, provide a toolbox with which companies can cra

their own soluons. These frameworks place the emphasis on the ability to create highly specic

customized soluons, which typically include a complex content staging topology, heavy involvement of

development resources for system extensions, and the associated need to manage the logic surrounding

content at each stage of system extension or integraon.

Simply put, publishing systems handle an organizaons’ need to create, develop and deploy websites,

whereas development plaorms provide an environment in which any number of soluons can be

created, publishing among them. We nd that most buyers seeking a web CMS are seeking a publishing

system rather than a development environment.

Database vs. le-based systems. The next consideraon in choosing a web CMS is whether a system is

database or le-based driven.

Database-driven web CMS’ require that content be stored in a highly structured way. Each piece of

content is essenally stored in a matrix, where each cell contains a “content chunk,” and may also

have related metadata. The content chunk becomes the most granular level at which content can

be processed. And the feature-funconality of the matrix itself represents the limit of what can be

done, not only with content within the matrix, but also with integraon in the overall technology

infrastructure.

In le-based systems, content managed by the web CMS can be stored at the le level within the

operang system, and can therefore be accessed freely by other modules and applicaons that run

within an operang system, rather than depending on a database. Content managed by le-based

systems can be both structured and unstructured, making it much easier to incorporate a wider variety

of content throughout the enterprise into the web CMS – whereas in database-driven applicaons, the

database becomes the funconal limit. For a le-based web CMS, the operang system itself represents

the limit, which really isn’t much of a limit at all.





9

We nd that le-based web CMS’ more accurately represent the way enterprises typically think about

their content – that is, Word documents, PowerPoint presentaons, Excel spreadsheets, PDFs, and the

like. Enterprises don’t typically think of their press releases and events in terms of columns and rows, as

such content would be stored within a database-driven applicaon. In a le-based web CMS, content is

stored in the applicaons with which they are the most familiar. Non-technical authors need never know

that their PowerPoint presentaon is being managed by a web CMS.

Soware-as-a-service (SaaS) vs. on-premise plaorms. The next key consideraon in choosing a web

CMS is whether it is installed on your premises or whether the applicaon is oered as a service, in

which actual installaon is remote.

Tradionally, buyers have thought of on-premise soware as oering a richer set of features and

funcons than soware oered as a service. Over the past few years, however, the feature-funconality

between these two types of web CMS’ has converged. So the purchase decision now focuses more

on the extent to which companies wish to customize their soware, which would favor on-premise

soluons, or the extent to which they value automac version upgrades and seamless systemadministraon, as in a SaaS plaorm. These are generalies, and they will not exactly describe every

prospecve buyer’s decision criteria, but as the need to control all of the minuae within a web CMS

soluon increases, the probability of favoring on-premise soware also increases.

The types of SaaS approaches have also changed. Tradionally, hosted applicaons have used a mul-

tenancy model where mulple customers are hosted on the same servers and applicaons. This model,

pioneered by companies like Salesforce.com, is a cost eecve way for soware vendors to add new

customers and provide a robust plaorm at a lower cost of ownership. However, not all SaaS companies

have the resources of Salesforce.com and not all applicaons t the same model as a web CMS.

With the advent of virtualizaon, web CMS buyers now have an opon of using a web CMS managedin the cloud with the same extensibility as an on-premise web CMS applicaon. Virtualizaon provides

a complete standalone network that can run a web CMS and integrate securely with other systems

and applicaons. As the cost of virtualizaon has fallen dramacally with the rise of cloud compung,

the costs between a dedicated virtualized environment and a tradional mul-tenancy web CMS have

become about equal. Virtualizaon also provides more exibility. With a web CMS applicaon and

website you can move to other hosng locaons or bring hosng in-house, have le-level access to

servers, open secure ports for other applicaons, perform upgrades when you want to rather than when

the vendor requires downme, and scale the service to oer beer performance.

Open source vs. commercial systems. The dierence between most commercial and open source web

CMS soluons goes beyond the license. While open source soware has come a long way in the last

few years, there are typically issues and costs associated with managing an open source web CMS, such

the necessity for the customer to develop and customize a plaorm, the lack of product support, and

the complex user experience and features that may be added to the soware without the same quality

assurance and product management oversight of a commercial soware vendor.

Organizaons using open source are oen dependent on a sta that is well versed in that plaorm.





10

When the sta leaves, the organizaon is faced with the challenge of supporng the system and

customizaons. While an open source license does provide some peace of mind in terms of ownership

of the soware source code, and in most cases the licensing cost for open source is “free,” the total

cost of ownership of an open source web CMS is oen much higher than its commercial counterparts.

Moreover, most commercial soware vendors provide some form of soware escrow service that covers

access to source code in the case of natural disaster or end of business operaons.

If you are deciding between and an open source or a commercial web CMS there are several key

quesons you need to ask: Do you have the capabilies to manage and extend the applicaon? How

crical is customer support to your success? What is the cost of downme and internal support costs? Is

open source soware development or management part of your core competency as a company? How

crical is source code ownership to your success?

Likewise, with a commercial system you need to consider the vendor longevity and viability, the depth of

their support services, and the availability of vendor resources to support your applicaon and projects.

Key Web CMS Features and Capabilies

While the features and capabilies vary widely between web CMS plaorms, there is a core set of

feature-funconality that all prospecve web CMS buyers should include in their requirements. This

secon is not intended to be a complete list of web CMS capabilies, but rather highlights many of the

essenal features of web CMS applicaons, the absence of which would be a deal-breaker.

Content authoring. Web CMS systems should

provide a content authoring environment

that is easy for everyone to use, technical and

non-technical. The web CMS should provide a

WYSIWYG content editor, which is essenally a

word processing-like applicaon that runs inside a

standard browser. The user interface of WYSIWYG

editors is very similar to word processing

applicaons in which users can select spacing,

alignment, text aributes, hypertext links, colors,

images, spell checking, etc. The web CMS should

also provide the ability to edit content in-context

of the page preview as well as in a forms-based

view that supports addional structure and

metadata.

Browser-based clients. Browser-based clients refers to an applicaon running inside a browser, as

opposed to an applicaon that needs to be installed. Using a web CMS with support for browser-based

clients is important in order to maximize the number of potenal content contributors. Assuming

that everyone has browser access, browser-based clients ensure that everyone can use the web CMS.

The content authoring environment within a webCMS should be easy for everyone to use, technicaland non-technical.





11

Whether a client is browser-based or not, it is important to understand which web browsers the

soware can run in (Microso Internet Explorer, Apple Safari, Mozilla Firefox, Google Chrome, etc.) as

well as the supported operang systems, such as Microso Windows or the current Apple OS.

Content re-use. Content re-use is oen considered the number one factor for return on investment of a

web CMS. Good web CMS’ ensure that source material is available centrally, and when changes are made

to the source, updates are disseminated to every instance where source material is used. For example,

if a company changes the locaon of its headquarters, updang the corporate address inside the web

CMS would ensure that every me the address is published on the website – or in printed materials, or

anywhere else – the updated address is used.

Some web CMS’ are based on XML, or similar technology, and developed to meet a wide range of

content re-use scenarios. This may include exports for elements such as tles, abstracts, and thumbnail

images in order to create content indexes and navigaons, the ability to support mul-channel content

deployment to desktop web, mobile, print, and kiosk “channels,”, and the ability to re-use content across

mulple websites.

Workow. All web CMS’ should provide for the

assignment of content authoring by individual

or role. That is, a supervisor may decide that Joe

Smith should author an arcle, in which case a task

is sent to Joe Smith’s email inbox. Alternavely,

the same supervisor may decide that anyone with

the tle of markeng manager should author the

arcle, in which case the workow would send

the assignment to anyone with the tle markeng

manager. Once the task is accepted and content

is authored by the appropriate individual, the

arcle is sent back to the supervisor for approval.

Workows may include any number of approval

stages and, once complete, content is published to

the appropriate desnaon. Workows may also

include individuals outside of a company, such as business partners or content translators. Non-technical

users should be able to set up workows without the involvement of IT. This means that workow tools

should be visually-based and should not require coding.

Versioning. As documents, web pages, and other les are updated over me, the web CMS shouldmaintain all previous versions, and allow for version restoraon, or “rollback,” at any me. In addion

to the simple maintenance of previous versions, the web CMS should indicate who was responsible for

every change. This ensures that previous versions are always available, and also allows for accountability.

Many web CMS soluons also provide red-lining or version comparison capabilies that highlight the

changes to each version of the page.

A web CMS should provide for the assignmentof content authoring by individual or role. Non-technical users should be able to set up workows.





12

Version history is crical in industries such as nancial services, health care, and life science that have

compliance and reporng requirements. These organizaons generally need more sophiscated audit

trail capabilies that show who made content changes and track which versions of the content have

been published.

Taxonomy. A web CMS should maintain a standardized taxonomy, which is essenally a lexicon that

denes what terms mean and their degree of relevance to other terms. Taxonomies allow you to

organize and deliver content by category and make it possible for users to search for specic content

without knowing the exact term used by the content author. For example, if a user searches for “lawsuit”

when the original author used “ligaon,” the taxonomy would establish relevance between the

two terms that would return content for “ligaon” based on a search for “lawsuit.” Taxonomies are

especially helpful in conjuncon with metadata and can be crical in managing customer experience

though segmentaon and targeng of key audiences, guided or faceted navigaon, and beer search

experiences.

Asset management. A web CMS should provide ameans of not simply storing and retrieving content

assets, but also a way of eding or modifying

them. For example, an image source le may be

quite large (greater than two megabytes). When

such images are used as thumbnails on a web

page, the web CMS should automacally re-size

them to a predetermined size. For images that

are not used as thumbnails with a predetermined

size, the web CMS should provide an image editor

to re-size an image without having to use a third-

party applicaon. This is only one example of

asset management, but it provides an analogy to

many other use cases.

The web CMS should also manage all types of

digital content, including images, video, and documents. An important queson is not only the type of

assets managed, but where they are managed. Many web CMS soluons require that assets be stored

in the CMS repository. While this may be a good soluon for many organizaons, oen large les like

video would be beer served on a media server. Documents may already originate out of a central

repository like Microso Sharepoint and it may not make sense to duplicate this content. Federated

asset management is the ability to store dierent types of assets in dierent locaons and is supportedby some web CMS soluons.

Templates. Since pages within a website typically follow similar structures, web CMS’ should provide the

ability for users to create a new page based on an exisng design. These designs are frequently called

“templates” or “page types” and they should be readily accessible by non-technical content authors and

editors. To learn more about templates, refer to the “Web CMS Template Approaches” secon.

A web CMS should provide a means of not simplystoring and retrieving content assets, but also a wayof eding or modifying them.





13

Analycs. A web CMS should provide a means of

tracking how website users interact with content

– how many mes they’ve accessed a page, the

clickstreams used to navigate content, the ads that

were most eecve, etc. Analycs modules are the

means of doing this.

Web CMS soware generally supports analycs

one of two ways: a built-in analycs module or

support for a third-party analycs provider. While

the integrated analycs of a built-in module is a

nice feature, analycs is a soware category of its

own and has a much broader features set than can

typically be supported by a web CMS.

In our opinion, the beer approach to suppornganalycs is the provider model. With this approach, customers connect their exisng analycs systems

with web CMS dashboards that provide context to the content. Providers for analycs may include

Google Analycs (usually free to use), WebTrends, Omniture, and other systems.

Search. A web CMS should provide search tools

for the content repository. Search tools should

oer opons for content retrieval, relevance,

and any number of other criteria appropriate for

faceted search (“facets” referring to criteria such

as le type, le size, color, date, region, price,

brand, etc.). A web CMS generally uses dierent

soluons for an internal content or repository

search and an external public web search. A

public web search is oen served by a third-

party search applicaon, such as Apache Lucene,

Microso Enterprise Search Server, Google Search

Appliance, or the like.

Reporng. A web CMS should provide reporng

tools that make understanding content

consumpon quick and easy. These are typically dashboards that display content usage summaries.Beyond a set of standard reports, such as audit trails, pages in workow, etc. the web CMS should

provide the ability to create custom reports. The ability to export a report as a Microso Excel or CSV le

is also important.

Mobile device opmizaon. Mobile may be the most important feature or set of capabilies in

evaluang a web CMS today. Mobile is outpacing desktop Internet growth by a wide margin.

A web CMS should provide a means of trackinghow website users interact with content. Analycsmodules are the means of doing this.

A web CMS should provide search tools for thecontent repository.





14

Since content will be delivered to a wide range of mobile devices, the web CMS should opmize content

for delivery to those devices. In order to do this, the web CMS must be able to detect which device

is making a request and deliver the right amount of content in the right screen format, checking for

possible content incompabilies, such as Adobe Flash content delivered to an iPad.

When planning for mobile it is also important to consider whether you need to develop a separate

website or app from your desktop website, or add another layer of presentaon to your exisng website

to support mobile users. While about 90 percent of mobile websites are deployed on a dierent domain

or sub-domain today, there is a cost associated with branching mobile because the inbound trac to

your website from outbound email campaigns, adversing, search, and social media is directed at your

desktop website URL. The web CMS should be able to forward users to the appropriate view of the

content based on the device user agent or to provide a mobile view of the web page using the same URL.

Another consideraon is how the web CMS can support mul-touch user inacon to enhance the

customer experience on smartphones and tablets. Web CMS soluons with strong mobile capabilies

support app-like mobile experiences and deliver touch-based interacons using HTML5 and frameworkssuch as jQuery Mobile.

Applicaons. Since websites typically include a number of common elements such as calendars,

newsleers, blogs, mulmedia, user forums, etc. a web CMS should provide each of these applicaon

types as a part of the basic product. Beyond the set of modules, web CMS soware should provide a

public API that supports integraon with external applicaons. Web services support, using SOAP or

REST-based protocols, as well as connectors to external databases, may be crical in integrang an

organizaons’ line of business applicaons and legacy systems. Generally a web CMS’ ability to easily

integrate with applicaons and data is referred to as the “extensibility” of the CMS plaorm. While

extensibility is oen one of the most dicult aspects of a web CMS to evaluate, extensibility may be a

crical consideraon is gaining the business eciencies and capabilies required in a website or project.

SEO is a mix of various features in the web CMS that support best pracces to help elevate search engine

rankings for websites. Support for SEO should include:

Search engine friendly URLs. Web addresses for each page that describe the topic of the page, show

where the page is organized in the website, and do not use any special characters, such as queson

marks, to denote dynamic content.

SEO metadata. The web CMS should make it easy to add descripve metadata for tles and page

descripons. It should also provide the ability to auto-populate metadata by default. Addional

“bot” instrucons, such as “no index” and “no crawl,” should also be available.

XML site maps. Site maps are connected directly to leading search engines, such as Google and

Microso Bing, and nofy search engine crawlers of new or updated content and its priority in terms

of indexing frequency.

Automac redirecng and forwarding. When pages are renamed, moved, or deleted, the web





15

CMS should automacally issue a permanent redirect so people using the old links can nd the new

content or be directed into other pages.

Canonical URLs. Every web page should only have one authoritave address. Canonical URLs

redirects users from every variaon of a web address to a single address. This may include adding (or

removing) the www. before the domain and redirecng for various extensions (such as .htm, .aspx,

or .html).

Mullingual. The ability to publish web content

in dierent languages and for dierent geographic

regions is crical for many organizaons. A web

CMS should streamline the mullingual publishing

process, making it easy to dene a locale – a

combinaon of language and region, for example

French (Canadian) – for dierent sets of content.

Typically, a web CMS can support mullingual in

two dierent ways: as a version of each page, or as

a clone of each page. Versions make it easy to track

each translaon for a page; however, the source

page and each translated version of that page are

bound together, so it becomes dicult to organize

a dierent set of navigaons and site structure for

each language version of the site.

In the cloning approach, content is branched from the source page, but also remains linked to that

source page. The cloned page may be organized into a dierent site structure. When one version of apage is updated, the owners of each of the other clones are noed of the changes.

We nd that for most organizaons cloning is a beer approach, as companies oen oer dierent

products and services in dierent countries. The ability to support variaon is essenal.

A web CMS should support translaon, either side-by-side in the CMS, or through an external translaon

service bureau using an import/export system. Web CMS clients ulizing mullingual features need to

support foreign character sets, such as double-byte characters and Unicode, as well as bidireconal

(BIDI) text for Arabic and other languages. Lastly, it is oen essenal for web CMS soware to provide

localized versions of the soware so users in dierent countries can work in their own language.

Mul-site publishing. A web CMS should provide the ability to manage and deliver content for mulple

sites. Again, like SEO and mullingual, mul-site publishing is not as much a feature as a collecon of

features in support of best pracces.

Publishing targets provide the ability to choose which sets of content are deployed to which locaon

and site, as well as determining the format the content is delivered in. For instance, a news story may be

A web CMS should streamline the mullingual publishing process, making it easy to dene a locale for dierent sets of content.





16

published to the public website using one look and feel and to the company intranet using another.

Similarly, a web CMS should support managing content in dierent environments, such as test, staging,

and producon. Content may be promoted between these environments to ensure that it is properly

tested and approved before it goes live.

Understanding Deployment

For the purpose of explaining deployment opons, let’s assume that the opmal set of content for a

website exists within the content repository. There are a number of ways that content can be delivered.

The rst consideraon is that of binding. That is, when does the content on a web page actually bind

with the page? When a web page always consists of the same content – such as a press release, for

example – that page is said to be stac. The content on the page never changes. When a website visitor

views the web page, the press release will always be the same. In this case, the content of the page has

“bound” with the page at a very early stage.

In other instances, website content does not bind with the page unl the website visitor requests the

page. Suppose that a visitor clicks on current events. Within the repository are events that happened

last year, this week, and event that will happen next month. Therefore, the current events page will

have content that changes on a daily basis; in this case, the page and the content bind only when a

user requests the page. This is called “late binding” content, and such pages are made possible by the

dynamic capabilies of the web CMS. Instances where late binding capabilies are important include

those where companies will want to oer content based on user preferences. Retail enterprises may

want to present a parcular color or size of clothing when a shopper clicks on the current specials

secon. This may be dependent on product availability, which the web CMS may also wish to check just

prior to delivering the content.

When considering the purchase of a web CMS plaorm, buyers will want to understand in detail what

the capabilies for the early and late binding of content and pages are. In most cases, there will need to

be some ability to combine early and late binding content, such as a press release as part of a page that

contains several other content objects. The collecon of objects on this page would be late binding.

Another website deployment consideraon is whether to use a content delivery network (CDN). A CDN

provides mirroring and caching of web content across mulple servers placed in data centers worldwide.

CDNs provide very fast content delivery and are ideal for delivering images as well as streaming media

les. With a CDN, you can easily scale content delivery without adding addional hardware by ulizingnave cloud services. Because content is redundant, a CDN helps ensure maximum upme for websites.

The challenge of working with a CDN is that it is dicult to support dynamic content. Some CDNs

support a short list of server technologies, but deploying dynamic or data-driven content on a CDN adds

addional complexity and can be expensive. CDN deployment oen requires using a stac, decoupled

deployment of HTML, or the “pull” approach, where the content is pulled in by the applicaon pages

from stac content.





17

Web CMS Implementaon

The implementaon of web CMS systems commonly presents as many challenges as the selecon of

the web CMS itself. While various web CMS’ require dierent levels of proprietary product experse, all

products will require specialized knowledge of best pracces for implemenng that parcular system.

Therefore, implementaon almost always involves some combinaon of internal and external experse.

Some companies opt to perform the bulk of implementaon themselves, taking a DIY approach, and

only enlisng the help of external experts for parcularly problemac areas. Other customers hire third-

party system integraon rms to perform implementaon. This is oen a company with close es to

the selected soware vendor, such as a cered partner within the vendors’ services network. In other

cases, buyers opt to let the vendors own professional services team perform the implementaon. In

each scenario, there are do’s and don’ts, such as the following:

DIY. Not knowing what they don’t know, web CMS buyers oen embark upon an implementaon

with no reliable idea of how many IT resources or how much me will be required to implement their

project. They typically commence such projects with esmates of three to six months, and they typicallyconclude projects within three to eighteen months. Somemes their esmates are accurate, and

somemes they aren’t. And because the devil really does live in the details in web CMS land, it is not

uncommon for a DIY implementaon to take two to three mes as long as planned. It is advisable in such

projects for web CMS buyers to enlist the aid of an external implementaon expert, at least for the inial

planning phase. A lile insight into the implementaon do’s and don’ts goes a long way.

Third-party systems integrators. Third-party integrators oen represent a good choice for combining

specic web CMS product experse with industry-wide best pracces. While the vendor’s professional

services will certainly oer guaranteed product knowledge, they may not be as compeve as third-

party integrators at oering bleeding-edge implementaon pracces relevant to specic business use

cases or objecves. However, buyers must be thorough in their assessment of a third-party integrators’

product knowledge of the web CMS they have chosen.

Buyers must also be cauous when allowing a systems integrator to make the web CMS purchase

decision. Because integrators typically integrate a limited number of web CMS’ (typically two to four),

they will advise clients to buy one of these systems even if another product would be a beer t.

Vendor professional services. As menoned above, vendor professional services are a guaranteed way

of geng up-to-date product experse. But in specic industries, third-party integrators may have more

up-to-date implementaon experse than vendors.

Web CMS Template Approaches

To make clear just one technology decision, we will discuss briey several approaches to site templang.

Four common opons are HTML, applicaon server technologies (.NET, PHP...), XSLT, and Apache-based

approaches.





18

HTML. The language used to create and dene templang

standards. While this approach has its pros and cons, it

usually works well for primarily stac sites (“early binding”

sites).

Applicaon server technologies. This opon tends to be

the best templang approach for sites on the “late binding”

side. This approach is oen complex, but it oers the highest

level of personalizaon. The details of this approach will vary

depending on which applicaon servers are used and can

range from industry standards to completely proprietary.

Applicaon server technologies may include Microso .NET,

PHP, Cold Fusion, and Java.

XSLT. This approach is based on transforming content within

XML documents based on denions in a stylesheet. Thisapproach is widely used, and is among the most extensible

and exible of all templang methods.

Apache-specic opons. This includes two examples: Tiles

and Velocity. Tiles is based on the Struts framework, and,

very generally, allows for the denion of page fragments

that can be dynamically assembled into a page at the me it

is requested. Velocity is a Java-based open source templang

framework, based on the MVC model, which emphasizes

the best pracces-focused, independent development of

applicaon code and page design.

Buying a Web CMS (Again)

Today many organizaons buying a new web CMS are upgrading from a legacy system. Organizaons

change CMS soluons for a wide range of reasons: the user experience may be too complex, the

soware may have been implemented incorrectly and requires addional investment, the old CMS may

not oer the current features required to deliver a compelling web experience, the cost of upgrading

to a new version warrants an evaluaon of other soluons, or the system has become too expensive to

support.

For buyers upgrading from legacy systems the outlook is good. Web CMS soware has improved

dramacally over the last few years, while costs have fallen. You can get more from your web CMS

investment than ever before.

While upgrading does not fundamentally change the process of buying a web CMS, it does introduce

addional criteria. Foremost is how the exisng content and applicaons may be migrated into the new

S P O T L I G H T O N M I C R O S O F T. N E T

Microso.NET is one of the most popular

development frameworks for web CMS

applicaons and sites. Today there are two

forms of .NET development: the tradional

forms-based development model, and the

new MVC (model view control) framework.

With forms-based .NET development, the

web CMS and its integrators develop a set

of server controls that output HTML and

other formang. With MVC the developer

applies formang to content that uses

standardized design paerns that support

open standards like XHTML and CSS.

While many .NET web CMS applicaons

are built around Web Forms technology,

and there are more developers skilled in

Web Forms, Microso itself has advanced

the MVC model. MVC also provides beer

support for deploying web content to

support dierent browser standards,

support mobile devices, and ensure

beer brand and design standards across

websites.





19

web CMS. While many vendors provide migraon or site

import ulies, the fact is that migraon always requires

some investment and level of eort. A content inventory is

generally a best pracce in migrang to a new web CMS. In

a content inventory the content owners should dene which

pages need to be created, refreshed, maintained, or rered

and priorize those updates. Integraon of exisng and

planned applicaons required understanding the web CMS

technology plaorm, extensibility, and deployment model.

Second-me web CMS buyers are oen guided by the pain of their exisng system, rather than the

opportunies of the new system. If the legacy web CMS was slow to publish, or made it dicult to

support mulple environments like staging and producon servers, evaluators tend to focus on these

issues above all other criteria. While we would not recommend purchasing a web CMS that does not

meet key requirements, it is also important to not miss the forest for the trees. The focus should be on

the features and support that can help you execute your business strategy.

Lastly, every web CMS is dierent. The savvy buyer knows it ’s not what the CMS can do, but how

the CMS supports each feature and use case. Even experienced web CMS buyers can fall into “check-

box” evaluaons where the emphasis is on the breadth of features, rather than the overall value of

the soluon based on the quality and depth of the features, the usability, and key criteria such as

performance and scalability.

Our Best Advice

We encourage web CMS buyers to remember that choosing a web CMS is a praccal maer. While it maysomemes be useful to discuss the academic nicees of various content management-related topics,

the business use cases that mandate a soluon cannot be postponed. Prospecve web CMS buyers are

generally very good at arculang their web CMS problems, and we encourage them to make use of

these dilemmas as a starng point toward choosing a content management soluon.

As anyone who has ever tried to tackle the web CMS problem can tell you, eecve content

management is an ongoing project. To help approach a web CMS purchase, we advise prospecve buyers

to:

• Assemble a list of current challenges that stem from content-technology, content-people, and

content-process issues.

• Dene issues that are likely to arise in the next year.

• Dene overall web strategy and taccs, as well as the metrics that will be used to measure success.

• Use this criteria as the basis for evaluang content management systems and vendors.

“The savvy buyer knows it’s not what

the CMS can do, but how the CMS

supports each feature and use case.”




If a web CMS can successfully address these scenarios, within budget – and you as the buyer believe in

(a) the vendor’s viability, (b) the potenal for posive long-term return on investment, and (c) the likely

sasfacon of your users with the web CMS plaorm – we believe you have found the right soluon for

your business. Get the party started!

TAKE THE NEXT STEP

About Ingeniux

A leading provider of web content management soware,

Ingeniux empowers organizaons to manage world-class

websites and vibrant online communies across web,

mobile, and tablet plaorms. Ingeniux soware is available

as a hosted service (SaaS) or on-premise applicaon.

Ingeniux delivers unparalleled service and support to

customers worldwide.

Discover what Ingeniux can do for you.

• Call (877) 445-8228 to speak with a soluons expert

• Email [email protected] to request more informaon

• Visit www.ingeniux.com to learn about Ingeniux soluons