Top 10 Things to Find Out Before
Selecting a CMS Vendor
- How long will it take to create, start,
and complete a simple content creation job with the system under
a heavy user load?
There can be a great deal of behind the scenes indexing and
database churning when users are creating and editing content.
A system that responds immediately with only one user may grind
to a halt when there are twenty content developers loading content.
- Is there an automated solution for
migrating existing content into the new CMS?
Often the answer is a solid “no.” But vendors will
try to make you think it might be possible during the sales
process. Usually existing content has to be re-created using
the new CMS. This is why you might need the twenty content developers
mentioned above.
- How many users can effectively use
the system at the same time?
Between content developers, editors, translators, and reviewers
the number can get big in a hurry.
- What parts of the system code can
be modified and what parts are proprietary black boxes?
Often it is easy to change the user interface for parts of the
system, but changing the way that the content is indexed and
stored is not possible.
- Exactly how does the translation process
work when using an external translation vendor?
This usually entails developing a specific workflow to be used
for external translations. The system will allow you to bundle
a bunch of records to out to a vendor and then re-insert them
back into the system when complete. This re-insertion of content
puts a huge load on the system and must be taken into account
when planning. You may only be able to load a few hundred records
a day without adversely affecting system performance.
- How do you delete records from the
CMS?
Having the ability to remove content records sounds obvious,
but once a record gets created in theses complicated, indexed
systems, actually removing it can cause serious data integrity
issues. Make sure you understand the process and if that process
works with how you plan to use the system.
- Make sure you understand how structural
changes to a master source content record propagate through
to versions of this record (language versions for example).
If the system being discussed automatically creates language
versions based on a master source content record, structural
changes to the master source record (such as adding a new link)
may not get automatically passed down to all the versions. You
may have to add the changes manually to each version, or create
a new workflow that propagates the changes.
- Will the IT group let content developers
migrate Web content directly to the production servers without
their involvement?
You may own the content, but the IT folks own the servers and
may be very reluctant to letting your team publish directly
to their servers. They will want to be involved to make sure
nothing bad happens. So if you are forced to FTP files to the
IT team and have them load them onto the servers there is no
need to pay your CMS vendor for expensive real-time publishing
tools.
- What is the structure of the URLs
generated by the system for each Web page?
Quite a few WCMS systems still generate query-based URLs that
look like : www.companyname.com/val=345234057$^%$*^(7876**&(*&97659%8650
You really need to be able to look at a URL and know exactly
what page on the site it represents. Real, readable URLs that
look like:
www.companyname.com/Sitearea/subarea/subarea/filename.html
give you a way to talk about site areas and particular pages
with a common taxonomy that everyone understands. When someone
tells me, “We have a problem with the ‘hammer’
product page in the ‘tools’ section,” I know
what they are saying and what page they are talking about.
Besides the fact the search engines can’t do anything
with a long, query-based URL, the site owners usually can’t
either. I love that I can look at a URL for a page on my site
and instantly know where it fits in the site structure and what
the content and navigation should be.
Keep the query string out of the URL.
- Completely understand the complexity
of the content creation process before assuming that you can
use a distributed content creation process.
Unless you have a very simple site and do not plan to design
for a lot of content reuse, expecting your content to be developed
by random people all over your company is a fantasy that CMS
vendors will always try and sell you. Most companies find that
once the system is built and delivered, that the system is very
efficient, but very complex. A module of content may be used
on several different pages and in different contexts. Changes
must be planned carefully. Users who only make content changes
a few times a year will not be able to use the system effectively
and will usually do more harm than good. If your site and CMS
implementation is complex, plan or hiring enough dedicated content
developers and content strategist’s to handle most of
the workload.
Understand How the CMS System will be Used, Not
just how it will be Built
Not having a content developer or managing editor
involved in the design and implementation of a new CMS is the
single biggest mistake I see companies make. This is treated like
it is an IT project when it is really a creative content development
project. IT developers rarely understand exactly how a CMS is
to be used by content developers and usually make bad decisions
if these people are not involved.
Get it In Writing
The cool thing about asking these questions before
you sign a contract with a CMS vendor is that you can then use
their answers to these questions as acceptance criteria when they
say they are done and want to disengage. Point them back to their
promises and don’t let them leave until all these criteria
are met or they give you an appropriate reduction in cost.
|
