The Black Art of Estimating Translations

Almost all the source content that we spit out of or WCMS goes out to our vendor for translation into 32 languages. They constantly demand accurate estimates of word count changes for each language (so they can make sure they have adequate staff in each language), but can never give us a good method for determining this estimate.

For changes to content that has been previously translated, the best we can do is to count all the words in each affected sentence, add up all the changes, then reduce the count by about %20 to account for translation memory savings. But sometimes translation memory automatically takes care of %75 of the changes and sometime almost none at all. For us, there is just no way of knowing which it will be until it runs through their system.

If anyone has a better way, I’d love to hear it!

Distributed Content Creation - Another Consultant Fantasy?

It’s probably on page two of the WCMS sales guy’s Powerpoint deck - “Our product will allow a subject matter expert, anywhere in your organization, to edit and create Web content.” When I was pushing WCMS solutions as a consultant, I talked about this all the time. Sounds like a great idea. And if you have a simple site that is published in one language for local consumption, it is certainly doable. But if you have a complex site and buy into the other big sales pitch, “single source” content, then things get tricky in a hurry.

There are two main problems I see all the time with being able to push content creation out to subject matter experts:

• Complex Interfaces - SME’s in your organization already have a job to do, they might create content every now and then, but not very often. If the WCSM is hard to use and understand, and they have to be re-trained every time you want them to do something, they just won’t do it.
• Complex Content Reuse - It is hard to get occasional WCSM users to think like people who use it every day. They don’t think about the potential impacts of a change they are about to make. If they are editing a content module that is reused on eight different pages, they need to check and see if the edit is valid in all contexts. If not, then they have to create a new version and hook that new version up to the page with all the correct metadata… they get in over their heads pretty quickly.

Here is an example of what I’m taking about. You have a product page that says your product is guaranteed for 90 days. You re-use the module that contains the “90 days” text in all your product pages. If the guarantee on one of your products changes to 180 days, and the product manager is tasked with updating the product content on the Web, he very likely to just go to the WYSIWYG editor, change “90 to “180″ and republish the page - not realizing that he has just changed the guarantee to 180 for all product pages because the module is re-used. They just don’t think like a Web content specialist, it’s not their job.

After a few of these high-profile screw ups, even if the mistake gets caught and never goes live, the SMEs will start to find reasons why they are just too busy to take on the job of updating Web content and the job will come back to the Web editorial staff.

The best way to make this work is to very carefully carve out specific content that can be maintained outside of the editorial department and building this content in a very simple manner, with as little re-use as possible, so the SME can be confident that they are not causing problems by making their changes.

Real-Time Publishing - Reality or Consulting Fantasy?

Can you publish something directly to your organization’s Web servers? I’m talking about pressing a button on your PC that moves new content to your staging server, verifying the change and pressing another button to move the new content directly onto your production server and see it go live. Can you do that? Are you being told by your WCMS consulting team that you will be able to do that?

Well, you better find out. In transactional Web sites for large organizations, this is pretty rare. But it is part of the sales pitch and every WCMS consultant’s Powerpoint deck, and almost no one ever questions it. Sure, it’s technically possible, but is it culturally and organizationally possible? Often not.

If you purchase hosting from a third party, then the chances are better that, for a price, you can make immediate publishing work. But if your organization runs its own Web servers, then you may have a problem. You have to deal with a team of gatekeepers who’s mission is in complete conflict with your mission. You want to publish fast and often, they are only concerned with keeping what is already live on the site up and working. They live in fear that something you are about to upload will bring the entire site down, so they will create an impressive gauntlet of approvals, signoffs, wait times, and procedures to slow the whole process down to a crawl.

In my organization, we have a whole team of migration specialists who keep the staging and production servers completely isolated from the rest of the company. If I want to get new content up on the site, I have to open a migration request, they have to approve it (in other words, they have agree that my content change is worthy for production), my team then creates a TAR bundle that get’s FTP’d to the migration team, they unbundle it, play with it a bit, then schedule a migration to staging. Some updates sit in staging for 4 or five days before I can get them up to the production servers. And oh, they don’t do any migrations on Friday or after hours unless you pre-arrange to have someone standing by.

So if you THINK your shiny new WCMS will allow you to push new content out 10 times a day, you need to find out who actually controls your Web servers.

“Just get some contractors,” Does Not Work with a Complex WCMS

Back when we did all of our writing in Word then tossed it over the fence to a team of HTML programmers it was easy to take on large, surprise projects. We just hired a few writer and HTML developer contractors and put them to work. It was an easy process. But with a complex WCMS, that’s just not an option. The general estimate here is that it takes about three months of full-time work to get someone up to speed with just the WCMS basics.

The learning curve for using our WCMS system is huge. You not only have to deal with the normal problems of what to write and who is the subject matter expert, but now you have to figure out how to build the content, using a variety of content types and presentation templates. Some of the content you may need to change may be reused elsewhere in the site so it takes someone knowledgeable to figure out where it might be used, and if the proposed changes apply in all contexts. Then there are the workflow issues… don’t even get me started.

Anyway, it’s something to consider when deciding to implement a big complex WCMS system. If you have an unpredictable workload and large projects may fall into your already %110 allocated lap, then you had best start training the admins and support staff now. You will need them eventually, and when you do, you won’t have time to train them.

WCMS Projects and Offshoring

When a WCMS project is viewed as an IT project, it falls into the kind of project that might be sent off shore for development. I still contend that a WCMS implementation has a strong IT component, but is really more of a BPM and change management type project that requires serious involvement from those who will be left to live with the system long after the programmers have moved on. Having the developers separated from the content authors by 5,000 miles and 12 time zones makes for a difficult collaborative process.

In Offshoring in an ECM Context, the author talks a bit about what might work when offshoring a CMS project and a few of the things to watch out for.

Case Study - Changing “Filler Content” into “Killer Content” Increases sales by %142

A great case study on how just rewriting content with good Web writing guidelines and the customer in mind can provide an amazing ROI. By focusing on editorial content they took a site that had no growth in traffic or enquiries since 2002 and generated the following results:

• From the 10th page to the 1st page of search results—and quite often the very first result—for many important keywords
• Unique visitors up 84 percent
• Visits up 208 percent
• Page views up 129 percent
• Returning visitors up 194 percent
• Unique enquirers (remarkably) down 10 percent
• … but sales up 142 percent!
  

Study Group Web Content Improvement Case Study

"The Web Content Strategist's Bible" Just Released

After talking a big talk for quite a while, I finally dug in and wrote the book. Trying to get everything I know about Web content strategy out of my thick skull was no mean feat and I certainly would not say I've covered everything, but it's a start and a great introduction to the practice and full of good information. There is plenty here for someone new to the idea of content strategy as well as lots of process advice and personal war stories that even the most seasoned veteran will find useful.

Find out more about The Web Content Strategist's Bible

So why an ebook?

I hope to have a lot of conversation about this topic and look forward to adding more information based on your suggestions and things that occur to me in my day-to-day work as managing editor for a the UPS.com website. I'll use this blog to keep track of Web content strategy topics I plan to add and keep you informed when I put up a new version of the ebook with additional information.

Free Updates for Life

Because I hope to make a lot of ongoing changes to the ebook, I'm offering free updates for life to anyone who reads the book and takes a few minutes to write me with comments and suggestions. Tell me what I did well and what needs more work.

User-Friendly URL Generation - A Must Have

One of the really good decisions we made early on was to make sure our WCMS captured and generated a human-readable URL structure. Quite a few WCMS systems still generate nasty, 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 URLs that look like: www.companyname.com/sitearea/subarea/subfolder/language/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.