CMS Fridays: Why Should You Use A Content Management System?

Whenever I hear about the, “we really should be on a Content Management System,” there’s always the discussion of “why?” A lot of clients have no concept editing their own website (that’s why they hire you, right, to build it for them? Why should they get their hands dirty?). However, for some organizations, managing your own website makes sense.

If you need some ammunition, NetSuccess has a great article about the benefits of CMSes.

A content management system can be very helpful and save time especially when you have a website with many web pages and content that needs to be updated constantly. When trying to decide whether to add a content management system, or CMS, to your website you should consider the benefits that a CMS can offer.

Read on…

CMS Fridays: Content Management Isn’t Cheap

There’s this great article over at CIO about the real cost of SharePoint, a content management system by Microsoft.

A few quotes:

If an IT department is using SharePoint as a development platform for business applications, costs will increase because developers and quality assurance testers will be needed.

Time and effort needs to be put toward developing and maintaining a SharePoint governance plan that outlines the type of content that should be loaded into the system, records policies, standard processes and metadata constructs, and guidelines for approaching and supporting SharePoint projects. (Read: solid information architecture — hire an IA, dammit).

Even if your users are familiar with SharePoint, using it to solve a specific business problem (such as automating a contract management or accounts payable process) typically requires some training.

After deploying SharePoint, users will need to change their approaches to creating and managing information. Given people’s reluctance to change, a proactive change management program is recommended.

Most of the organizations out there just launch CMS systems without any thought to a lot of issues. It’s like any other software product, and should be treated as such.

CMS Fridays: First Take On BuddyPress

I’ve been playing a bit with a BuddyPress installation, the new social networking application for WordPress. It requires WordPress MU as the platform. I really like it — it’s like they say, the basic features of Facebook in a box, plus you get to add blogs and other functionality that some sites don’t have.

BuddyPress is an uber-set of WordPress Plugins that add a lot of structure and functionality to WordPress, but even with that, the installation isn’t as tough as you would think.

The pluses

• Social networking: You can add friends, create groups, create blogs — all the actions you would expect in any social network, including emails that will be sent out during particular actions. It’s all open source too, so you have complete access to the code base to customize it, and believe me, you can customize WordPress a lot.
  
• Customizable profiles: While there’s some wonkyness to adding fields to profiles (you can’t order them), adding them is a snap. I have no idea how you would actually search the fields in an advanced search sort of way — looking at the database, it didn’t appear to be very easy — but the amount of customization you can do and the easy of use to do it is ridculous.
• WordPress Plug Ins: You get full access to the thousands of plug ins that have been developed for WordPress, including the BBPress discussion forum, which plugs right in the to the groups.
• Your server, you own it: While Ning is a great solution (I’ve seen some awesome implementations) at the end of the day if you’re a business, it’s best to have it on your box so you are less suspectible to the platform. BuddyPress is that.

The minuses

• Installation: It’s on WordPress MU, so moving it over from your standard WordPress installation isn’t as easy as you would hope (well, it’s not for the normal WordPress user). There was some database installation funkiness that a few extra minutes in PHP would have solved in handling errors better. Outside of having to delete the WordPress configuation file a few times, the installation was fairly run of the mill.
• Designing The UI: With the extra funcitonality comes the extra overhead of designing a look and feel for the application. While the first theme is great — I used some of the examples to solve design issues with a marketing directory I’m working on — there is a significant amount of work that has to be done that’s well outside of the “well, it’s WordPress, I can pay only $500 to design in” comments by clients. It is Facebook in a box, and should be treated as such for complexity, and I can imagine spending a month at least designing a decent social netowkr.
• WordPress Plug Ins: Not all of them will work well with WordPress MU, so the predictability of what works and what doesn’t is trial and error. You’re going to have to live with the caution of “well, this may work, but it will be an adventure” on some of the plug ins.
• Performance: It seemed a bit sluggish, and if you are running a social network of any size, I recommend having it on a dedicated server. Some of the plug ins haven’t been tuned yet, so there is a lag. Remember, it’s version 1.0.

CMS Fridays: At The Very Least, Buy An Associated Press Style Guide

Is it 9 or nine? What’s the proper abbreviation for California? When should I use a semi-colon?

These are all questions that might be asked during the migration of a content management system, or writing text for a new site.

How do you establish style? Consistency is another key to effective writing, and readers do notice typos and style inconsistencies (I know, I get the emails from friends when I have them here). There’s nothing that is more glaring than when certain items are used incorrectly. It’s even more frustrating when the defaults (i.e. “am” for instance, for time) doesn’t match a consistent style.

At the very least, run out and buy a few copies of the Associated Press Style Guide. For $10 at your local bookstore, or about the same at Amazon, the book is the bible for style and capitalization (please don’t compare this site to the Style Guide, I’m not getting paid to do this). This style guide is used by thousands of journalists to answer such questions as the proper spelling and usage of punctuation for such terms as Dr Pepper, ball point pen, and Popsicle.

Throw a few copies of this book around, and the authors will at least get close to what it should be. Consistency is the key.

Here’s the top 10 Associated Press tips as stolen from Cubreporters.org:

1. Use a person’s full name and title the first time you mention him or her in an article. For example, write Don Swanson, professor of communication, not Prof. Swanson. Once people have been fully identified, refer to them by last name only. There are exceptions, so always check the AP stylebook.
2. Spell out abbreviations or acronyms on first reference. For example, use Passaic County Community College the first time you refer to the college in a story. You may use PCCC on any references made after that. Another example would be to use DAR only after you have spelled out Daughters of the American Revolution on first reference.
3. Abbreviate months when used with days, and use numerals (1, 2, 3, etc.) not ordinal numbers (1st, 2nd, etc.). Exceptions are March, April, May, June and July — write them out, don’t abbreviate. For example, write Sept. 2, 2008, not September 2nd, 2008. But, when using only the month and year, spell out the month.
4. Generally, spell out the numbers zero through nine and use numerals for 10 and higher. Note, however, that numbers used at the beginning of a sentence are spelled out. Example: Five hundred twenty-four students attended. It is better, however, to rewrite the sentence so that it doesn’t begin with a number. Example: Attending the event were 524 students from local colleges. Years are one of the exceptions. For example: 2008 was a bad year for investors.
5. But use numerals even for ages younger than 10. This is another exception to the aforementioned number rule. When used like an adjective, say X-year-old, including the hyphens. Otherwise, don’t use the hyphens. For example: the 5-year-old girl kicked her brother, who is 8 years old.
6. Spell out the word “percent” but use numerals for the actual number. Examples: Participation increased 5 percent. Nearly 28 percent of all students don’t like algebra. Exception: use may use the % sign in headlines.
7. To indicate time, use figures and lowercase letters (9 a.m., 6 p.m.). Put a space between the figure and the letters. Exceptions are noon and midnight. Do not say 12 noon or 12 midnight — it’s redundant.
8. Capitalize formal titles used before a name. For example, write Secretary of State Hillary Clinton. Very long titles may be shortened or summarized unless they are essential to the story, but the shortened form should not be capitalized (for example, you may use spokesperson instead of Vice President for Public Affairs and Communications). Use lowercase when formal titles follow a name (e.g., Hillary Clinton, secretary of state). General titles, such as astronaut Neil Armstrong and actor Matt Damon, are lowercase.
9. Capitalize formal titles and names of people, places or things to set them apart from a general group. These include proper nouns such as Mike, Canada, Hudson River, and St. John’s Church. But use lowercase for common nouns (i.e. nouns not coupled with a proper name), such as the river or the church. Also, put a word in lowercase when you have more than one proper noun sharing the word. Example: Ocean and Monmouth counties. Capitalize the first word in a sentence. Refer to the dictionary or AP Stylebook, if needed. When in doubt, use lowercase.
10. Do not use courtesy titles such as Mr., Miss, Mrs., or Ms., except in direct quotes or where needed to distinguish between people of the same name. Using courtesy titles may be polite. And the New York Times uses them in its articles. But it is not AP style.

CMS Fridays: The Ugly Truth About CMS Migrations

You’ve been running some custom CMS built during the internet prehistoric era (read: 1999). It’s huge, it’s a mess, and the development company that built it is charging you too much money. Someone on your management team has decided what the new platform is, and like or not, it’s moving day.

What’s going to happen?

I’ve been through a few of these, and they’re never easy. People always estimate the amount of work it’s going to be, and for the most part there’s no real thing as a straight migration. At some point or another there’s human intervention.

Here’s a few truths and what to do to move it along.

Just because it’s the system picked to fill all your needs, it will not fit all your needs

Content management systems are picked for all kinds of reasons (and more specifically, the people that help you those content management systems are picked for all kinds of reasons) other than the right reasons. Sometimes it’s price, sometimes it’s for personal preference.

It’s really about biting the bullet — most of the things you do in the beginning will take a lot longer to do than the previous system because the previous system was custom to your needs. No out of the box content management system will completely fit the bill, so you need to figure out how to alter your workflow and business processes to fit the new system.

What to do? Figure out the strengths of the system, and play to them. That might mean doing some work that you don’t think it’s the right way to do it, but that’s okay, learning a new system is going to take time.

There’s no such thing as a straight migration because it deserves a new information architecture from the start

Like it or not, the site’s going to take a lot of reconstruction, because legacy systems like that have outgrown their previous design. It’s like a freeway that’s been around 30 years — when you have to reconstruct it, you’ll have to build new interchanges, lanes will have to be reconfigured, and it should be just wider. Think a virtual version of the Santa Ana Freeway in Los Angeles.

This is a painful process, because that means moving a lot of pages around, and it also means editing a lot of pages.

What to do? Bite the bullet. The users deserve pages where they can find information.

The content will be no where as clean as it needs to be

Almost ten years of content entered into the site by people that have long since moved to greener pastures means that a lot of pages will have old font tags, some won’t be structured correctly, and across the board, every page will a different adventure. Phone numbers will be in 23 different formats, headlines will be in lower case, upper case, title case and all cases.

One of the great things about content management systems is that anyone can edit the content.

And one of the worst things about content management systems is … anyone can edit the content.

What to do? Set up some standards from what the content should be, including giving everyone a copy of the Associated Press Style Guide or Chicago Book of Style, and set a style guide for the hierarchy of content.

There will be a lot of content missing

Just because it’s a migration doesn’t mean it’s really a migration. There will be new pages. There will be missing pages. There’s will be new content structures. And someone has to write all that content.

That’s one of the biggest secrets of doing a migration: after a site inventory of the current system, what you thought was there you didn’t necessarily thing was there, so you  might migrate some of it, but re-write a lot of it.

What to do? Employ a content strategist or copy writer. You aren’t programming a new system, you’re using a tool, so the ratios of the roles will be much more to user experience folks and content specialists. You don’t need a bunch of developers, you need writers.

CMS Fridays: Picking A Content Management System

Your IT person says Joomla. Your PHP person says Drupal. Your marketing person says SharePoint.

Let’s be frank: they are all buzzwords, and the person speaking to using that system usually has an ulterior motive outside of what’s best for the users. It’s like that Linux guy that likes Linux because it’s easy for him and no one else. Does that really serve the office?

If you have a Microsoft Gold Partner sitting in your office, he’s going to say SharePoint fits the needs for anything short of curing cancer even if MOSS is completely the wrong system. And frankly, all developers have their favorites, and sales people sell, regardless of what the product is. Mac vs. PC. Windows vs. Unix. Drupal vs. Joomla. They’re all religious wars, wars I’m especially tired of.

Every product has it’s merits, and should be judged on them alone, not on a salesperson’s preference. End of sentence.

What do you do?

Read on…

CMS Fridays: So, Just How Do We Fit “Unsere Dienstleistungen” Into The Navigation?

The reason that I used “Unsere Dienstleistungen” is that’s the German translation of “Our Services”. If you are localizing a website, have you considered that the site’s going to look like in German? Chinese? Spanish?

Is there a color in the design that’s okay in Korea, but not okay in France? Does the IA work in English, but not in Hebrew?

Many of the major content management platforms, open source and commercial, have extensive support for localization, but supporting those other languages has a new set of requirements. Have you designed the site with this set of requirements?

Here’s a few tips to think about while you are going through the design process.

Ynet English — Left To Right

Ynet Hebrew — Right To Left

Design With Cultural and Linguistic Differences In Mind

Did you know that some languages read from right to left? Can you imagine having to develop this functionality for Israel as a browser developer?

For example, YNet News is an Israeli publication published in English, but the Hebrew edition reads right to left, so the navigation is completely different. Or that publications that are online for Quebec citizens use a different dialect of French than France. Or Spanish used in Mexico has significant differences than Spanish spoken in Spain.

Those differences should be researched up front, and considered during every step of the design process. For example, there are 31 different forms of address formats in world.

How are you going to design that contact form again?

Consider Color Implications When Designing The Site

On of the major client’s branding had been set for months. About a week before launch, someone asked what the implications of the color were for, say, the Korean culture. After review with the branding agency and the client, the color of the logo (and much of the design), was changed.

About.com has a great post about what certain colors mean in certain cultures. It doesn’t mean that we all should design everything in black and white; it’s just meant to limit misuderstandings.

Design With Flexibility In Mind For Language Translation

As you can see by the headline, certain languages (German, for example) are very, very verbose. Other languages (Chinese, Japanese, and Korean come to mind), can say the same thing in a few characters. Every language is different, and even adult sites know that the best thing to do is to hire a good translator instead of having an application translate the text, if there’s a budget for it.

Take your Photoshop mockups or HTML clickthroughs and use Google Translation tools to test your designs. If it fails the German test, reconsider your design.

Plan Localization At The Beginning

If you have even a whisper of an chance of converting the site for multiple cultures, plan localization at the very beginning. This is done by desiging the site so the URLs read like this: http://www.site.com/en/. This means that all pages under EN are English pages. This achieves two goals:

• The site won’t break from an SEO perspective
• Design of the site will include content regions based on the language

This planning saves weeks of time later on changing the site, and setting up the site at the beginning this way familarizes your staff on how to edit the content areas. Many content management systems have separate files for each language, and editing of the content happens with the files.

Hire Good Writers To Translate The Site

The red-headed stepchild with the plain sweater in content development is the copy writer; rewriting the same copy in different languages mean the same copy will read poorly in more than one language, and a straight translation from Google is not the way to go.

Go with writers that are native in the core language, and can communicate clearly in the other language. There’s a lot of dialects and other colloquialisms that are missed is the person isn’t a native speaker, and that makes a big difference in how the site reads.

Or, how would you like your client to be the object of ridicule on a Chinese message board?

CMS Fridays: More About Them, What The Sales Person Won’t Tell The Client, And Vice Versa

You’ve solved the problem!

You’re implementing Drupal, SharePoint or something else that’s a “content management system”, and you’re getting the client involved in creating the content. One problem — getting them to use the content management system is impossible.

Seriously, I’m all for putting power in the client’s hands, but they have to be prepared for that power, and most of the time the person “given” that power has many more things to do than edit content in a website or extranet.

Here’s a few more truths about content management system and how they affect clients.

Sometimes what you wish for is what you get

All clients love the idea of editing their own site, but have no idea what it takes to create content. It means sitting down, opening up Microsoft Word and actually putting thought into the words that you are going to write. And that’s a lot of work, and they usually have no one on staff to do that task. I can’t tell you how many times I’ve had clients wanting to edit their sites because it’s been sitting for months, and they’ve forgotten the password.

Once they get in, they usually get out as quickly as possible, and ask you to add the photo or make the change.

Having that power and using that power are two different things, and many a time the client just throws up their hands and expects the company that implements the CMS to add the content.

What to avoid? Write in the contract that you aren’t responsible for content until you are responsible for it when the client is footing the bill.

The client has no one adept enough to use the CMS technically

Some CMSes, like SharePoint and SilverStripe, are straightfoward to use and for the most part don’t require extensive training to get the ball moving; within five minutes of each, I can train someone on how to add a page, how to edit content, and how to upload files.

Some of the other CMSes? I would never want my mom opening up Joomla.

Ever.

The reason they’ve brought you in for the project is not only for your design skills, but for your technical skills. The reality is that most companies small enough to want to go open source are also too small to maintain a site if it gets much further than changing out some text because their staff isn’t technical enough. Open source doesn’t mean free, and that free sometimes comes with technical overhead.

What to avoid? Put in time for training. A lot of it.

Open source is still open source — buggy and sometimes hard to use

When you use “free software”, you sometimes get what you pay for, and the client will never understand why you’re using it, other than, “you’re billing me for this, why doesn’t it work?”

The open source CMSes are what they are: developed by programmers that have a love of developing software, but sometimes do things their own ways or they aren’t thoroughly tested. Some clients don’t understand this, and figure the CMS should be bug free right from the get go.

Whatever system you select, explain to the client there’s going to be an upgrade path, and associated costs with it. This may mean some kind of maintenance deal in the future that’s like dependent on the upgrades coming out.

What to avoid? Have a very real conversation with the client about what open source means, and explain to them all software is buggy. Seriously.

CMS sites don’t plan themselves, and a bad information architecture can set you back years

The client is fully engaged, learns how to use tool in a way cavemen learned how to use fire, then “burns” themselves the first way through.

Bob down the hall in accounting can barely spell information architecture, much less construct one, and a single workshop over an hour isn’t going to give someone enough training when some of us have been honing our craft for years. It’s about planning, and poor planning for some CMS implementations can be death for user adoption. Or, how’s your company intranet holding up?

What to avoid? Book an information architect all the way through the project. If they are engaged, they can give the guidance needed for the site, and it will save time and money in the long run.

CMS Fridays: Picking The Right Content Management System

I’m in the process of setting up a few content management systems for clients, and it’s been an eye-opening experience, not because the systems are crude, but because they actually work pretty well. SilverStripe and WordPress are two that I’m looking at using on a consistent basis, but there’s a few resources out there to help you select one:

• Six Revisions has a list of the 10 promising systems it has selected
• Open Source CMS is the mack daddy of CMS lists, and a lot of them have online demos
• CMS Watch is a bit more techie, and is a news portal covering the major systems
• Sometimes a blog engine is just what you need, and Smashing Magazine has reviewed 10 of them

In the coming weeks, I’ll go through some of the implementations I’ve been doing to make WordPress and SilverStripe sing. Stay tuned!

CMS Fridays: Do End Users Really Care It’s SharePoint?

That’s a question I always ask when dealing with the clients: do they really care it’s a content management system?

The answer is no.

They’re looking for something that saves them time, backs up their data, makes it easier to share information with their co-workers, and that will work. They don’t necessarily care about the name of it, all they really want it to do is work, and for it to make their life easier.

That’s one of the points information technology departments miss in dealing with end users: the users at the end don’t really care what the name of the software is, because whatever they get, it’s imposed on them. From the email software they use to the word processing software they write up reports in, almost every piece of software is selected and standardized on across departments. Very few end users get to pick what their software is, and if they do get to pick, the information technology departments don’t support it.

So what’s my point?

To the information technology departments, specifically: whatever you do, make sure it doesn’t impose extra restrictions or demands on the end users. Whatever you build into SharePoint, take in consideration that the easier to use it is, the more users that will use it. Imposing extra governance and workflows to it doesn’t make sense.

For example, Groove is a great tool when paired with SharePoint, because you can have files on your local system sync with SharePoint document libraries automatically and seamlessly. What that meant for me is I lost a bunch of files in a system crash, but all of the files were backed up to SharePoint. I didn’t lose anything.

And it was so easy to use, I didn’t even know I was using it.

Can you say the same about your SharePoint implementation?