After coaching numerous clients on the intricacies of WordPress, I started to wonder if there might not be a better way to approach training. Eventually, I decided that training videos might be be the solution. As a result, I’ve spent a fair amount of the past month recording a series of WordPress training videos that are now available at no cost on WordPressTraining.com.

My hope is that the site will appeal to both novice and experienced WordPress users. Whether you’re looking for a comprehensive overview of the entire WordPress system, or simple insight into a single administrative page, WordPressTraining.com should help you get the most out of your WordPress blog.

I’ll be adding new videos as time allows, and, of course, updating the videos as new versions of WordPress are released.

The current collection of videos focuses on what I refer to as Core WordPress training — a detailed overview of the various blogging features and administrative options.

I look forward to receiving constructive feedback from the community. If there are specific topics you’d like to see covered in future videos, drop me a note, or leave a comment below.

The MarketWatch quotes display with either a minty green or pale pink background depending on whether the current quote has risen or fallen since the previous quote. Every few seconds the numbers blink as a stocks price changes. For stocks that are trading up and down throughout the day, readers are treated to alternating flashes of pink and green. The numbers include the current price, the daily price change, and the percentage change – so it’s a fairly long string of numbers that changes with each update. A story with a half dozen quotes embedded in it can be a truly a mind numbing experience.

This amazing innovation got me thinking – why stop at real-time quotes? Why not have whole sentences and paragraphs change in real-time as well? After all, the real-time quotes could change in a way that might fundamentally alter the nature of a story. Wouldn’t it be better to have writers create alternate scenarios that could be swapped into the story as the corresponding stock prices change? Talk about stickiness. Readers could spend an entire day just trying to get through one story;)

All sarcasm aside, I like the Web 2.0 thing as much as the next guy, but every once in a while I run across a DHTML or AJAX widget that just makes me scratch my head and wonder, “what could they have possibly been thinking”. Just because something is technologically possible doesn’t mean it’s a good idea. It’s all too easy to get carried away with the coolness factor of some new technique and lose sight of the user and the message you’re trying to convey.

In all fairness, I think the MarketWatch feature could work with a little tweaking. The real-time updates need to be removed from the article copy and placed in a quote box beside the article. The flashing and blinking would still be distracting, but at least the readers wouldn’t see numbers changing mid-sentence. Better yet, the updates could be moved to the real-time graph box that only displays when a user mouses over a ticker symbol. That would eliminate all distraction and give users the choice of viewing real-time numbers at will.

Note, I haven’t even begun to address the accessibility issues related to the MarketWatch real-time quotes. I’m guessing Jaws and other screen readers might actually explode if they were to encounter one of these pages.

Do you have other nominations for an AJAX Hall of Shame? Tell us about it in the comments.

• Sample Market Watch Story – real-time updates only visible during market hours

And, of course, the migration phase of the project comes in on time and under budget. No, better, it’s done early and under budget. The content migration team is celebrating at the local pub while other teams are sweating deadlines.

In the real world, we all go into content migrations with high hopes and solid plans. Depending on the size of the site and the culture of the organization, you can expect delays, misunderstandings, and more than one last-minute “uh oh”. There is a lot of good advice relating to managing the migration portion of a CMS project, and I’ve linked to some favorites below. In the meantime, here’s my short strategic plan:

• Finish your content inventory. By finish, I mean identify every piece of content on the existing site and new content. If the letters TBD appear anywhere on your worksheet, you’re not done.
• Identify where the content goes. Specifically. Exactly. When you get to item 507 on your inventory, you should know exactly where it will slot into your new site.

• Gather all the content. Sure, locating the content on the existing website will be easy, but what about the new items? Knowing they’re in Jim’s drawer or on Rex’s hard drive is all very well and good, but you want physical and/or virtual possession of every item to be migrated before you start work. This will eliminate the need to create “Waiting For” placeholders — these tend to be overlooked in the final rush to launch a site.

  Before you add a single item, you need the following ready to go:

  1. Content From The Current Site – I prefer not to work on a live site because it seems like servers die just when you need them most, so I like to work from a copy of the site.

  2. Electronic Files

     – Sounds easy enough, but you need content in a readable format. Plain text is good, but more likely than not you’ll get documents in Word or other standard formats. A word of advice: if the electronic file cannot be read by a modern machine (and hasn’t been accessed by your client’s staff this century), chances are it shouldn’t be migrated to the new website. This might be a great chance to update obsolete items.

  3. Hard Copy

     – Yes, by hard copy, I mean paper, generally of the 8 1/2″ by 11″ size, but I’ve been surprised by stranger sizes more than once. As with documents created with obsolete software, there’s an excellent chance that items available in hard copy only are due for major refreshing.

     At the very least, you need to factor content conversion into your budget and workplan.

  4. Ghost Content

     – This is content that should be on the new website, but doesn’t yet exist. This is where hard deadlines and good judgment are helpful. You don’t want to build your new site around items that don’t exist, but popping a letter from the president in at the last minute probably won’t be a deal-breaker. If you haven’t received To-Be-Created items by your set deadline, it’s time for a serious talk with your client.

• Practice content triage. Prioritize your migration plan. My approach is pretty simple, yours may vary, depending on the project:

  1. Top-Level Content

     – This generally means entry pages to major sections, content deemed by the organization to be “critical”, and policy documents. If someone says the site’s launch has been moved up, you’ll know that the top levels have been built out with no broken links.

  2. Secondary Content

     – This deeper content should not be launch-critical, but still needs to be migrated. This is generally current content or content accessed on a regular basis.

  3. Archives/Tertiary Content

     – Large websites tend to have troves of “archives”. Government agencies, for example, tend to keep archives of old minutes and agendas as online public records. While it may be determined that meetings from 1999 don’t need to be migrated, chances are that there will be some infrequently accessed content. This goes last as budget priorities may dictate a slower migration pace (or the client may decide to do this work as time permits).

• Focus on the migration. I like to do content migration without any other business distractions. This is the first time I’m really “touching” the content, and despite the best efforts and most assiduous inventory practices, things slip through. This is my chance to make sure everything is perfect. The art of content migration doesn’t allow me to do detailed proofreading or rewriting (meaning I have to curb my natural instincts), but I do know that titles are spelled correctly, leads form complete, readable sentences, and nothing is duplicated.

You may be working in isolation or you may be working with a team of content migrators — these key steps apply in either case. I like to have the migration done early enough to accommodate last-second tweaks and mind-changing. Many of our clients require daily site updates, so planning for a final content load is also something we factor into the launch schedule.

Content migration is a big part of any successful CMS implementation — with a good strategy and careful planning, it can also be the most painless.

• Ten Strategies for Content Migration (Adaptive Path)
• Web Content Migration Project Design (CMS Watch)
• Preparing web content for migration (deyalexander)
• Wild Information: Content in Its Native Environment
• The Content Inventory: Roadmap to a Successful CMS Implementation

Give Your Content Some Attention

If you’re using a content management system (CMS) there’s always the temptation to assume that your content is fine. It’s being “managed” right? So what could possibly go wrong?

Plenty.

Use the New Year as an opportunity to review the quality of your content. While most CMS systems include some form of workflow, you might be surprised by some of the things that slip onto your website. Be on the lookout for content that is outdated, inaccurate, irrelevant, or just plain incoherent.

Validate Your Website’s Relevance

This is a different sort of validation than you’re probably used to, and one that definitely can’t be performed by an automated testing tool.

Website’s have a tendency to veer of course (some more rapidly than others). If it’s been a while since your organization launched its website now may be the time to verify that your site is still an accurate representation of your business.

If it’s been more than a year since you developed your current site you might be surprised to find out that many of the goals and assumptions that drove the initial development have changed.

Keep in mind that the following things have probably occurred since your website launched:

• Your understanding of the web has changed
• Your understanding of your customers has changed
• Your customers have changed
• The web has changed

Think About Your Customers

And by extension, stop thinking about your organization. Too many websites are still organization centric with an emphasis on departments and divisions. Most customers don’t have a clue what department they need to contact. Instead, they typically come to your website with a specific task in mind.

Have you identified the most common tasks that your customers have in mind when they come to your website? Does your website support your customers in completing these tasks?

If you’re not sure what your customers are trying to accomplish, and whether or not your website is actually helping them achieve their goals, there’s a pretty good chance that your website could use some improvement in this area. It might be time for a user survey.

Review Your Site Navigation

Site navigation is another area where a CMS can lull webmasters into a false sense of confidence. If your CMS allows multiple users to make modification to your global navigation and your site has been online for more than, say, a week, you probably have some review and cleanup to do in this area.

As sites grow navigation items has a tendency to sprawl. Without regular attention your site navigation will grow out of control and turn into an unusable mess of unrelated links.

Don’t assume that all of your site users immediately head for the search engine (although they might eventually end up there if they can’t easily navigate to what they’re looking for).

Take some time to review your navigation structure and ensure that it’s still coherent. Conduct ad hoc user testing to ensure that others can use your navigation as well. Just because something make sense to your web team doesn’t mean that it will make sense to your customers.

Be on the look out for:

• Navigation labels that use jargon.
• Sub-navigation items that may be misfiled.
• Navigation that leads to areas that have no content.
• Missing navigation items (hard to look for, but you’ll know them when you don’t see them).
• Misfiled content (the result of authors who quickly add content but aren’t sure where to put it).

Identify Accessibility Problems

Even if your site was developed to be WCAG or 508 compliant, accessibility issues can still creep into your site over time. Unless accessibility review is part of your ongoing workflow, chances are your site has at least a few accessibility issues that require your attention.

This is another area where CMS systems and distributed authoring can create problems. In a perfect world every contributor would be knowledgeable about accessibility and would work diligently to ensure that their content is fully accessible. Since we don’t live in a perfect world you’ll want to review your site for any issues that may exist.

While accessibility scanning tools are no replacement for manual review, they can be a good starting point for reviewing a large number of pages.

Be sure to document any accessibility issues you uncover for future reference. Also, make it a point to meet with any authors who are contributing non-accessible content. Use your accessibility review as an opportunity to educate your web contributors.

This is by no means a comprehensive list, but it should be enough to keep you busy in the coming months. If you can think of similar suggestions that we’ve left out, please let us know in the comments. Also, if you’d like us to expand on any of these suggestions in more detail, please let us know.

So how do visually impaired people watch The Simpsons? With the Descriptive Video Service (DVS) of course. DVS is an audio track that explains the action taking place in a television program. With The Simpsons that includes reading all of the oddball signs that fly by during the course of an episode (not to mention Bart’s scribbling on the chalk board at the start of each episode).

WFMU’s station manager Ken has an interesting post about his accidental discovery of the DVS signal while battling with his broken VCR. Like many people, he hadn’t really given any thought to how visually impaired users might watch and enjoy programs like The Simpsons. At first he assumed The Simpsons were doing a parody of Arrested Development.

Ken also makes some interesting observations regarding censorship and editorializing on the DVS track, but that’s probably a topic for another post on another blog.

At any rate, if you’re interested in hearing what the DVS track for The Simpsons sounds like, Ken has posted an entire episode available for download.

• The Simpsons as Described by WGBH

It’s easy to avoid focusing on content when you have no idea what it is or where it is. CMS vendors focus on the user-friendly aspects of their software; rarely do they address the complexities of content migration. Since the system you’re implementing is supposed to make content management a breeze, there’s a temptation to avoid thinking about content until the very last minute. This flawed assumption has doomed all too many CMS projects.

Our first article defined content in all of its many forms. This article focuses on the nuts and bolts of identifying content and coralling it in such a way that you have what you need when it comes time to populate your CMS. The key to achieving this goal is a process called the Content Inventory.

What Is Included In A Content Inventory?

Content Inventories almost always take longer than anticipated. We try to start this phase of the project as early as possible, knowing we can iterate the inventory as new information about the project is revealed. Your inventory serves as the starting point for developing your IA and as the roadmap for ensuring all content is migrated to the new site. While many documents are created in the course of a web development project, chances are your content inventory will become your primary tool and reference point.

This inventory includes:

• Content on the current website. Every item. Without exception.
• Content to be migrated to the new website. Every item. It’s easier to scale back than to add on.
• Web-based applications or transactional systems to be integrated with the new website.

Web-based applications or third-party systems are not necessarily content, but should be noted on the inventory for informational purposes. These applications often require placeholder content or links to external systems. If these systems are not included on the roadmap, they might be overlooked in the final rush to get everything done before the specified launch date.

For each item on your content inventory, you need to capture (at a bare minimum) the following information:

• Description: The title of the content item.
• Content Owner: This is generally the department or individual responsible for the content item.
• Content Type: Content types include articles, forms, and systems.
• Format: Formats include hard copy, electronic file (Word/Excel/PDF, etc.), and links.
• Location: This is the location of the content item. Locations include URLs, the hard drive of an individual, a shared directory, or file drawer in the basement of the building.
• Update Frequency: You might want to include “Frequent”, “Sometimes”, or “Rarely” flags in your inventory. Frequently updated content generally requires a higher profile in the navigation schema.
• Status: The status of content can be current, obsolete (generally content on the current site that will not be migrated), or to be created.
• General Notes: If the content requires special treatment or you have additional information to capture, note it in this section of the content inventory.

Creating The Content Inventory

While we expect our clients to shoulder their share of the burden when it comes to the content inventory, we typically take a first pass by inventorying all content on the existing website; we do this by methodically following every link on every page, in order. This approach allows us to spend quality time with the client’s existing content and leads to a deeper understanding of the client’s business.

Once we’ve seeded the inventory with the existing web content, we provide the inventory worksheets to each department and allow the client’s staff to add any additional content they want to include on their new website. This requires that the client be as specific as possible. You need to know if you’re migrating two agendas or 25. “Various documents” is not a content item — the content migration is not the time to work out the details of what was meant by “various”.

Once the client has completed their work, we analyze the entire content inventory and follow up on the inevitable questions that arise. This follow-up is done via email, phone, or small meetings with key staff. At this point, we’ll iterate on the inventory with the client until we’re sure we’ve captured everything that needs to be included. This process includes tasks like identifying gaps in the content and coming up with appropriate titles for articles.

Content inventories, especially for information-rich sites, can get quite large. A spreadsheet allows you to sort and filter the data into multiple views as needed. Once we’ve completed the initial capture of information, we expand the inventory to include keywords, target customers (especially helpful for developing a user-centric navigation system), and other information relevant to the migration. This content-related data is a crucial part of the raw material used to develop the site’s information architecture.

We said in our first article that the first step to developing an Information Architecture is identifying a website’s content. Once you have an understanding of the type of content that will be included on the new website, you can begin to figure out how all of the pieces will fit together.

For example, if you’re building a site for local government, you’ll notice that various departments have resources targeted toward businesses. In a physical City Hall, business owners may be required to visit multiple departments in order to perform various tasks. As you develop your IA, you can target this customer group by aggregating business-focused content into a common area and organize that area around the various tasks that business users would want to accomplish. The result of this process is a customer-oriented site structure improves the overall user experience.

Once the IA is complete, we add one more column to our inventory: location on the new website. Knowing where things go in advance allows the entire migration process to proceed rapidly. Our worksheet allows us to easily sort by new location and build each section of the site in an orderly manner.

There are many approaches to the content inventory process, and you will ultimately find a system that works best for you. The first step, of course, is creating a usable spreadsheet. Here’s an Excel worksheet that you can use as a starting point. Remember, a content inventory template is just that; you’ll note that ours includes columns for language and audience. This is information we need to capture for the majority of our clients. Different projects have different needs, and you may need to modify this template on a case-by-case basis.

Analyzing The Content Inventory

While individual departments can create their initial inventories, one person should be responsible for analyzing and understanding every item on the completed inventory, from its purpose to its relationship to other content. Employing too many analysts leads to big picture items being missed. For example, some sites will have the same content item posted in multiple locations. A good CMS streamlines the process of managing one piece of information in multiple places; however, the content analyst needs to be aware that this duplicate content exists (we usually indicate this in the Notes section). Otherwise, you will negate the benefits of a CMS. A single content item is easy to maintain; the same item in multiple locations means that someone needs to remember to update the item in every location, every time the document is updated.

This analysis of the content inventory also aids in identifying and understanding various types of content (content classes) that need to be accommodated by the CMS. Articles can take on many forms: news releases, public notices, agendas, FAQs, or even photo galleries. Good content management systems handle a variety of content classes, and identifying the article classes early in the project aids the design process, information architecture, and CMS implentation.

Adaptive Path’s Jeffrey Veen has called content inventories “mind-numbing” (Doing a Content Inventory (Or, A Mind-Numbingly Detailed Odyssey Through Your Web Site)).

There are benefits to this tedium. By the time you’re finished, you will have a better understanding of your client’s business and, likely, a lot of ideas about how to better organize content. You will discover relationships between content that can be maximized. And you will walk into the Information Architecture phase of your project with confidence.

Next Up: Analyzing and Preparing Content for Migration to Your CMS

Related Articles:

• Wild Information: Content in Its Native Environment

This first article defines content types that need to be accommodated by your CMS and analyzes common problems we’ve faced when it comes to corraling content. The second article in the series unfolds the roadmap to a successful CMS implementation: the Content Inventory. Our final pieces looks at content migration and the triage process often needed to migrate content in a timely manner.

What Is Content?

Content development and migration comprise a major phase of our development process. While some might argue that Information Architecture is the cornerstone of a successful CMS implementation, you cannot begin to develop a site’s IA until you’ve identified all of your content. For the purpose of this series, we’re defining content as:

• Articles: These are the text-based documents that will constitute the bulk of content in your CMS. As you analyze your content, you’ll find a number of discrete article types (news releases, agenda items, job listings, etc.) which may require special treatment. Many CMSs support a variety of content classes, and it’s important to identify article types early in the process in order to develop a workable strategy for dealing with them.
• Forms: This type of content usually involves the collection of information from your website’s users. Forms trigger an action that usually involves some sort of workflow. If you plan on converting paper forms to a web-based process, you will almost certainly need to do some level of business process analysis. When dealing with forms during the content development phase, it’s not uncommon to discover that many forms (or form fields) are out-of-date or no longer relevant. There’s nothing worse than wasting time developing a web-based process for a paper-based system that serves no puprose. In general, you should do your best to curb your client’s urge to automate bureaucracy.

You’ll notice we didn’t include external links in our definition of content types. For the purposes of populating a content management system, links are generally treated in the same manner as any other article.

Common Content Formats

Though businesses embraced PCs in earnest in the late 1980s, most organizations have a surprisingly difficult time producing usable digital content. As you begin inventorying your content, you’ll discover that it exists in many formats (or, in all too many cases, it doesn’t exist at all). Each format has special challenges to be considered as you migrate it to the web.

• Hard Copy — Far more often than you’d imagine, the only available format for certain information is in hard copy. If you’re lucky, there will be a pristine master copy used to make duplicates as necessary. Chances are, the master copy will actually be a hundred generations old, last updated on a manual typewriter, mimeographed, and unreadable.

  This type of physical content must be manually gathered (we use an expandable plastic interoffice-style envelope for this; we also use Post-Its to make additional notes about the document when appropriate). Surprisingly, locating actual copies of important physical documents can be a challenge. Your client’s staff will dig through desk drawers, scour filing cabinets, and, in desperation, pull brochures off racks and say, “Use this.” By “use”, they mean “use your magical web conversion machine to turn this into an attractive web page”. What this really means is that you’ll need to rekey or OCR the document to obtain usable text. How you should make this determination is covered in Part Three of this series.

  We’ve also learned that documents existing only in hard copy are often outdated, if not downright obsolete. We strongly recommend reviewing hard copy documents with your client to determine relevance and accuracy before you spend three days scanning mountains of paper. We’ve discoverd instances were businesses hand their customers documents signed by employees who left the organization a decade ago. The web project is the first time many standard business documents are reviewed in-depth.

• Electronic Files — Electronic files are created by programs such as Word, Excel, PowerPoint, Adobe Acrobat, PageMaker, or one of a zillion other applications. It is not unheard of for a client to produce a file requiring an application that hasn’t been commercially available for over a decade (yes, some people still have WordStar 2000 files). That you do not have, nor can you obtain, a copy of the application will come as a surprise to your client. Regardless of what format these electronic documents exist in, you will have to provide guidance in formatting them for migration to the web.

  Though we create guidelines and instructions for collecting and providing content, we’ve found that clients usually organize the content they give us in ways that make the most sense to them. Most people believe their method for aggregating information is logical and helpful. Because your content inventory will likely identify content by owner, we suggest instructing the client to put content into folders named after content owners before turning the content over to you (this is usually done by file transfer or by providing CDs/DVDs full of documents).

  But wait . . . once you have the file, how do you identify it? Sure, your client can name each file in accordance with the file name indicated on the content inventory, but what fun is that? Frankly, with some clients, actually receiving content is a challenge. Expecting usable, logical files names is too much to hope for — this is where good titles on your inventory come in handy. Remember: your client has been using naming conventions that are relevant to their business, and, especially when it comes to large projects, renaming the files is not practical.

  Though it should go without saying, the electronic files you receive are not likely to be well-formatted. People have been improperly using word processors for nearly 20 years, and it’s not likely they will suddenly start using proper document styles anytime soon. This poses a variety of new challenges, including the fact that content cannot be copied and pasted from Word without significant clean-up. We address this challenge in other articles (see links below) and in Part Three of this series.

  Our caveat about relevance and accuracy applies equally to electronic files.

• Ghost Content — It is inevitable that your client will identify content that should exist but doesn’t. Or they know it exists somewhere, but they just can’t find it. Or maybe they just haven’t gotten around to actually creating it yet. In these cases, someone will have to actually write the content. If you have writing skills, you can include content creation in your budget. If you don’t, keep your fingers crossed and hope that the ghost content isn’t destined for the home page.

Most organizations are excited about the prospect of a new website and eager to help you help them. However, most organizations don’t have a good grasp of the work involved in creating that website, especially when it comes to implementing a CMS. Your job is to keep the project on track. Understanding the core issues of content development and migration will allow you to keep things moving.

Next Up: The Content Inventory: Roadmap to a Succesful CMS Implementation

For those of you who aren’t familiar with the term, a folksonomy is basically a taxonomy created by the people and for the people. A community of users collaborates by “tagging” various types of content with user created keywords. This concept is flourishing on a handful of community driven sites that all seem to have a certain addictive quality. I think the best way to fully grasp how folksonomies work is to dive into one of the sites that makes use of the concept. Flickr, 43things, and del.icio.us are good places to start. Given the success of these early experiments in group tagging I have no doubt that we’ll be seeing folksonomies implemented on all sorts of sites in the very near future.

Lately I’ve been thinking about one particular artifact of the folksonomy phenomenon — the folksonomy menu that serves as a sort of buzz index providing users with a quick visualization of the most popular tags (technically I think it’s called a weighted list). Popular tags are displayed in a larger font and it’s relatively easy to identify hot topics at a glance. This visual representation of the popularity of any given tag is undeniably cool. However, once the coolness factor wears off it becomes fairly obvious that these menus are also not very accessible.

I realize these sites are currently trail-blazers and they deserve to be recognized as such. I have no intention of detracting from the innovative work that’s being done. My concern is that once folksonomies enter the mainstream, the next wave of sites implementing them will likely begin a wholesale copying of the work that’s being done by these innovators — markup and all.

Also, I need to point out that folksonomies are community driven. A few minor changes to the existing markup would go a long way towards making these communities accessible to everyone.

Analysis of the accessibility of weighted lists on five websites using group tagging and folksonomy

I spent an afternoon looking under the hood of the folksonomy menus on following sites:

• Technorati
• Flickr
• 43 Things
• del.icio.us
• MetaFilter

I was somewhat surprised to find that the markup on each of the folksonomy menu pages was entirely different. While all sites were basically implementing the same type of menu they all arrived at their respective results in different ways. Given this finding, I was even more surprised to note that each site shared most the same accessibility problems:

• Unstructured Links: With the exception of Technorati, each of these menus was rendered as an unstructured collection of links separated by only whitespace or a non-breaking space entity. It seems fairly obvious that these links constitute a list. Rendering these items as a list would provide visually disabled users with more feedback regarding the number of links as well as the ability to skip the list entirely.
• Extraneous Markup: While not technically accessibility related, each of these pages uses a fair amount of extraneous markup to achieve its goal. I encountered a startling number of span elements accompanied by inline style declarations. And while Technorati wins points for realizing that these links are actually a list, they should also win an award for the most creative use of the EM element.
• Absolute Font Sizes: Without exception fonts were defined in pixels. As a result I was unable to resize type in Internet Explorer. This was somewhat puzzling given the fact that it would be fairly easy to implement the font size variations using em’s. del.icio.us actually went as far as defining the font size in fractional pixels extended to the 13th decimal place. They must be using one of those 30 inch Cinema Displays .
• Lack of Context: These menus currently require a user to actually view the page in order to discern the relative popularity of tags. There is no additional context that could be used to determine popularity. Given the fact that the difference in font size for any pair of tags can be as little as a single pixel, additional context would also be useful to those who are not visually impaired.

Recommendations:

The good news is that these issues are all easily fixed. Most of the solutions will be quite obvious.

• Use Lists: Lists have become the standard way of rendering a collection of links. Lists provide additional structure that can have a significant impact on accessibility.
• Avoid Inline Style Declarations: I’m sure there’s room for debate on this recommendation, but personally I would assign a class to each LI element. There’s really no reason for extraneous elements or inline style definitions.
• User Relative Font Sizes: Defining font sizes in em’s would allow users to easily resize type in any browser. Fractional em’s are easy to calculate, and they make more sense than fractional pixels.
• Add Context: While it’s not a perfect solution, it might be a good idea to add each topic’s relative rank to the title attribute of the anchor. Something like title=”Politics – Rank 3 or 10″.
• Consider Alternate Views: There’s no reason that the current standard folksonomy menu has to be the only way of representing the relative popularity of tags. An ordered list sorted by popularity would eliminate some of the need for visual clues. Adding a link to such a list would provide users with more choice while addressing accessibility concerns.

Here’s a page demonstrating my recommendations.

I realize that it can be challenging to focus on these types of details while innovating in the way that each of these sites has. While folksonomies are still relatively new, I think we’ve reached a point where it’s time to start thinking seriously about best practices.

One of the stated goals for the site was accessibilty. Granted, this was not the term used, but as we went through the process of identifying the site’s customers, local senior citizens were mentioned. Because this is a city website, they do not have to comply with Section 508 — however, as many local government agencies choose to do, the city made compliance a goal. Throughout the design process, we kept this in mind, and, because the backend of the site is a content management system, we included “hooks” to ensure things like alt attributes weren’t forgotten.

Okay, fine. Mission accomplished.

Sort of. The day-to-management of the website is handled in a decentralized manner by non-technical staff. The final review before new content is published is done from an an editorial perspective — the webmaster doesn’t know HTML, and the chances of her learning it are slim. When we loaded the original batch of content on behalf of the client, we converted as much as possible to plain HTML. Unfortunately, due to a variety of factors, not everything could be converted, and there are many documents posted as PDF files.

As the person tasked with converting the bulk of the content on the site, I realized that the goal of accessibility faced multiple challenges, all which are part of a bigger challenge:

• Non-Technical Staff Updating The Site. Have you ever tried to create an accessible table in HTML? I have, and it’s not a simple process. In fact, if you don’t do it regularly, you’re going to require a refresher course. Every time you create a new table. Let’s see, you have the actual table structure, the summary, the caption, grouping of columns and/or rows, the thead, the tbody…I’m sure I’ve missed a few pieces, but you get the picture. Just the idea of explaining the differences between caption and summary makes my head spin; if you want enforcement, we need to talk.

  Basic HTML is easy, but most people think it’s hard. Hard enough that they don’t want to be bothered learning it. I see this every day. A WYSIWYG HTML editor works just fine for the average content creator. When you get to fun stuff like acronyms and abbreviations and the art of remembering what code works with which browser, you’ve lost your audience (heck, even if you get someone who has the time and energy to do the right thing, there will always be a few who pop out of the woodwork to argue the semantic differences between acronyms and abbreviations). Coding for accessibility is easy when you’re looking at lightly formatted content. It’s not easy, as evidenced by the various discussions on the WAI lists, when the requirements of the content move beyond the basics.

• Time and Money. Our content migration process bumped up against the very real constraints of time and money. Like most cities, the particular agency didn’t have unlimited funds to devote to the project. As it was, we took a loss on this aspect of the project, partially because we, the developers, were committed to doing it right. Even so, we were confined by project deadlines. Eventually a site must be handed over to the client and launched.

  As staff integrates updating their areas of the website into their day-to-day activities, they will also face this challenge. Content will be added between meetings, phone calls, constituent questions, even emergencies like fires (including while the fire is raging). Careful HTML coding will necessarily give way to “get it up fast” attitudes. This organization cannot afford the luxury of a full-time staff member working on the website. The webmaster mentioned above already has a full, full-time job; the mandate to increase web content adds to her job.

• Lack of Effective Tools. As noted, we posted a lot of items as PDF files. Sometimes this was because of the time/money issue; sometimes it was because the documents were heavily formatted and converting to HTML didn’t make sense; sometimes it was because the information presented didn’t lend itself to HTML — like complex spreadsheets. Inevitably, these documents were created in applications such as Word or Excel and converted to PDF.

  Yes, Acrobat has accessibility tools. Have you used them? Even well-formatted Word documents require scrubbing after conversion. And I doubt anyone is going to pretend that the vast majority of Word documents are well-formatted. Drilling down into documents and fixing conversion errors is a time-consuming process. See above for more information on why this is a problem.

  For some documents, there’s the option of copying and pasting from Word. The CMS used by the city allows users to copy items as plain text, and we trained them on this process. A few people will likely remember the steps for stripping out the extraneous Word code and there’s an extra process run on content to clean up the HTML as much as possible. Bottom line, of course, is that these are band-aids, and most users will copy and paste directly into the HTML editing box, note that the document “looks” okay, and post. All of the lovely semantic coding will be forgotten because very few word processor users consider structuring their documents properly.

  If Word allowed someone to copy and paste plain text, maybe the final result would have better structure because the HTML mark-up tools in the editor would provide structural elements. Personally, I’d advocate for removing the bold, italic, underline, font selection and size options from the toolbars. Clearly, nobody’s asked me, and users will continue to hit the “B” button at will.

We did everything we could — from design to tool integration to template development to training — to ensure the goal of an accessible website was met. Now the full burden of maintaining the site is on non-technical staff. This is not an uncommon situation — in our experience, more websites are maintained in this manner than are sites under the control of individuals who live and breathe HTML with all of its nuances. Whenever I read that content owners “should” do this and that to achieve accessibility, I wonder how many people dictating the “shoulds” actually understand the process from the perspective of someone who drew the short end of the straw and must now add updating their department’s area on a website to their daily duties?

When we work with clients, nobody questions the goal of accessibility. Quite the opposite. But businesses and government agencies do not have unlimited resources, and they don’t always have technically-oriented staff. I realize there are many individuals pushing for improved user agents and technology; until someone can copy and paste clean HTML from Word or convert to a well-formatted (even if structurally incorrect) PDF file, websites will be littered with the ghosts of well-intentioned content authors who had to balance the “shoulds” with reality. It probably wouldn’t hurt if actual coding guidelines were evaluated from the perspective of people in the trenches, either.

There seems to be a widely held perception that CMS is a losing proposition. As a result, many corporations and government agencies have hesitated to make a commitment to CMS. A surprising number of corporate and government websites use no CMS at all, or a mixed up assortment of homegrown tools that can only loosely be referred to as a CMS.

Depending on their circumstances these organizations may not be able to resist the lure of a true CMS for much longer. There are hundreds of CMS vendors competing for the available market share. If you are not yet using a CMS it’s only a matter of time before a key decision maker in your organization gets sold on the idea. You know how it is when management latches onto buzzwords.

CMS doesn’t have to be synonymous with failure. There is no doubt that the right CMS, properly implemented, can offer real benefits to organizations of all sizes. The catch seems to be that it’s not always easy to find the right CMS, let alone a qualified team with the skills needed for a proper implementation.

As businesses of all sizes embark on their first CMS project they need to realize that they are venturing into territory that in many ways is unique. A CMS implementation is not quite like any other technology project. If for no other reason because the end result is a system that is used to manage what will essentially become the public face of your organization.

With this in mind I offer a few do’s and don’ts that could help you minimize your chances of joining the ranks of those who are unhappy with their CMS.

DO:

• Make sure you actually need a content management system. Not all websites do. Not every business generates enough content to justify the time and investment involved in using a full-blown content management system. Organizations that just need to post infrequent news updates may be able to get by with a simple blogging system. Spend some time up front determining what your real needs are.
• Get to know your content. It may sound self evident, but content is key. That would be why they call it a Content Management System. Start by asking a few basic questions: What is this theoretical content you will be managing? Who is the audience for this content? Where does the content live? Who owns it? How frequently does it change? What is the production process? What is the lifespan of your content? For larger organizations these can be difficult questions. There may be no single person in your organization who has a complete understanding of all of your organization’s content needs. You’ll need to make an effort to answer these questions before you can determine what your true requirements are. Don’t even think about selecting a system until you’re comfortable that you know all there is to know about your content and the process used to create it.
• Understand that when it comes to CMS, one size never fits all (despite what that vendor just told you). There are hundreds of CMS’s targeted at different markets. These systems have huge variations in cost, technology, and complexity. Your goal is to find a system that meets your specific content and organizational needs. The last thing you need is an overly complex system that offers cutting edge features you have no use for. Likewise, there will almost certainly be a variety of must-have features that you can’t live without. In addition to getting to know your content, you’ll want to consider the following: How many contributors do you have? Are your contributors centralized in a few departments, or do you have a deeper organizational hierarchy? What are your workflow, authorization, and publishing requirements? Do you need the ability to maintain a multi-lingual site? Do you need personalization? What about transactional capabilities? Scheduling and content rotation? Version control? Since the chances are that you’ve never developed a CMS requirements document before, you might consider seeking professional assistance before you begin evaluating CMS applications.
• Have a budget — preferably a realistic budget. As you evaluate CMS alternatives you’ll probably experience sticker shock at the price of some CMS systems. Keep in mind that the CMS license is only a fraction of your total cost. You can expect to spend 3x to 5x (or more) the cost of the license during the implementation phase. And don’t think you’re going to get off lightly just because you’ve selected an open source application. Just because the license fee is zero doesn’t mean you won’t need a considerable amount of professional assistance during your implementation.
• Consider usability and accessibility. There’s nothing worse than spending months of your organization’s time and a small fortune building a website that your customers can’t use. While it may be tempting to blame a bad user experience on your CMS, usability and accessibility problems can be minimized if adequate attention is given to these areas during the design and implementation phases. There’s no substitute for understanding your customers needs and building a site to meet those needs. Usability testing can help improve the odds that your users’ needs are met when your new site launches. While it’s tempting to focus on “the system” you should never underestimate the importance of user-centered design.
• Consider trying a low-risk pilot project that explores the potential of CMS and introduces the concept to your organization. Pilot projects can also serve as prototypes for larger projects and may be extremely useful in uncovering system requirements.

DON’T:

• Select your CMS before you have a full understanding of what your needs are. The first time we encountered a potential client who had actually purchased the CMS before interviewing professional service agencies we thought it was an anomaly. They literally had no clue what they had purchased or how they were going to build a site with their new system. Their selection became a limiting factor in everything else that followed. Since then we’ve come to realize that this sort of thing happens all the time. Upper management gets the CMS bug and they dispatch their CIO to ‘go buy one of those content management systems’. Hysteria ensues.
• Leave the CMS implementation to your IT department. Technology is only a small part of the CMS equation. Management should see CMS as a strategic business system that requires the involvement of staff at all levels and from departments across the organization. Building a team with a broad organizational perspective will dramatically increase your chances of success.
• Assume you won’t need to seek professional help. If this is your first CMS implementation you’ll likely underestimate the skill set needed to successfully develop your new website. Professional guidance during the planning phases can save a tremendous amount of time and money throughout the course of your project.
• View your CMS implementation as an isolated project with no impact on your operations. Your goal during the CMS implementation will be not only to launch a new website, but to integrate your new system with your existing business process. At the same time, a CMS project may provide organizations with the opportunity to re-assess existing processes and procedures. I am frequently amazed at the type of organizational issues that are unearthed during a CMS implementation. Outdated documents that are being distributed to clients as “current” information and non-existing procedures for mission critical business functions are typical of the types of issues that arise during the course of a CMS implementation. As these issues surface during the implementation, management should begin to take a more critical look at content and how it is created and maintained throughout the content lifecycle.
• Underestimate the amount of time required to produce quality content. You’ll need to undertake a comprehensive content inventory throughout your organization. Once your inventory is complete you’ll need to make sense of it all and begin building the information architecture for your new site. The processing of all of this content will likely involve a fair amount of document conversion and should also include extensive review and editing. These things all take time.
• Implement unnecessarily complex workflow and publishing processes. Workflow has its place, but you should resist the temptation to build elaborate workflow rules that have the overall impact of slowing down the content process. Your CMS should facilitate the management of content, not act as a barrier preventing the dissemination of new content.

Conclusion:

There’s more, of course. But in my experience these seem to be the most common mistakes that hamper the successful implementation of a content management system. Focusing on these key areas should at least set you on the right path and will hopefully allow you to avoid the pitfalls that so many others have fallen into when undertaking a CMS implementation.