Author’s Note: Considering the subject matter and length of this particular article, I’ve decided to split it into two separate articles.

Related Articles:

1. How to Fix Your Broken CMS: Part 1
2. How to Fix Your Broken CMS: Part 2

Background

In Part 1 of this series, I wrote at length about the current state of CMS software in general, and proposed a dramatic shift in our attention from features to user experience. At the end of the article, I offered a possible direction in terms of how to build a better CMS, and how we might better fulfill end user expectations (needs vs. wants).

In Part 2 of this series, I’ll be addressing the elements of what I feel would make a truly effective CMS.

Read on…

A Recipe For a Truly Effective CMS

Rather than approach a CMS as the alpha and omega of managing content, we need to approach it fundamentally: as tools to support people (and their myriad flavours of an editorial process).

Keep it simple. Keep it lean. Keep it efficient.

Ingredients

We need a few ingredients:

1. A system to facilitate the editorial workflow
2. A system to act as the delivery mechanism (loosely coupled with the presentation layer)
3. Enhanced user-profiles to determine access levels and the end user experience

Profiles

Let’s begin with the last ingredient (the element that binds all others together): the user profile.

The fundamental need here is to deliver a user-experience designed for a wide range of end users without becoming homogenous, meaning that the interface with which an editor performs her job can differ dramatically from that of an content author.

Generally speaking, a single individual can act in one or all of the following capacities:

1. The physical author of a piece of content
2. The reviewer of a body of content
3. The one delegated with the authority to promote content into another process

Note: these are fairly general roles, and granular capabilities/responsibilities/access rights should be introduced to reflect the organization’s needs.

The goal of a profile is to allow users (and those governing the process) to determine their desired user-experience based on both their role in the workflow, including selecting or customizing the interface that is ideally suited for their job function.

Everything else can be considered excess unless it promotes efficiency or enables productivity.

Example:

For simplicity’s sake, let’s assume that we’re talking about a content author—we’ll use Karen McNally as our archetype—whose only responsibility is to craft a piece of information and then promote it into the workflow.

Karen’s profile grants her access to a collection of her work (material that is still considered a work-in-progress, e.g. a “draft”), which she can edit or revise as necessary. When the piece of content is crafted and ready for review, she promotes it into the workflow.

Karen Smith has now fulfilled her fundamental role and responsibility as a content author. It is now up to another person—Michael Bloor, our ‘editor’ archetype—to review and make suggestions that she can implement.

Michael will then review Karen’s recent draft, suggest changes, contribute to the subject matter, and later promote it back into the system where it is then promoted further into the production chain.

What Karen likely sees in terms of an interface is a streamlined set of screens that:

• Allows her to quickly access her work
• Allows her to manipulate and edit her work, likely including suggestions for supporting material and media
• Allows her to “check-in” her work into the editorial workflow

In the example above, we know that Karen only needs a certain set of screens and features in order for her to fulfill her responsibility as a content author. At this point, the material is then subject to an editorial process that might repeat once or several times before it is then delegated to someone else in the workflow.

In her role, Karen has little interest in formatting for final presentation—that is someone else’s responsibility. She does care about ensuring some basic formatting to communicate the subject matter, and it’s likely that she does have an interest in providing other source material to support her work.

As for Michael, he likely sees a set of of screens that:

• Allows him to quickly access one or several drafts submitted to the editorial workflow
• Allows him to make modifications and re-assign the draft back to the original author
• Allows him to promote the draft into the production chain

In Michael’s case, he has a narrow set of responsibilities; however, his profile provides him with similar screens as Karen along with a series of screens that she would not otherwise see. On top of this fundamental difference, Michael has enhanced privileges that allow him to promote content or delegate content for other systems/processes.

The Delivery Mechanism

It’s a fundamental truth that a website will undergo change at some point—it might not be today or tomorrow—but it will likely evolve either through the introduction of new content or other factors like a redesign.

In the case of a redesign, many aspects of a website are affected: the underlying architecture, the look and feel, and in all likely hood—the content.

Considerations:

• Most CMSs tend to be focused on short-term execution, e.g. getting a website developed and running
• Most CMSs promote data-warehousing—a concept that is both dangerous in terms of potential liabilities for the organization, and inefficient in terms of productivity for the long-term users
• Most CMSs are developer-centric and unfriendly to those who are not familiar with the developer’s philosophy around content management and the resulting methodology applied to the system in question

What we’ve experienced are systems that are designed for short-terms success for a small group of users and long-term frustration for the intended users (Karen McNally and Michael Bloor in our previous example).

What we want is is a system that is still intended to facilitate the production of a website, but is a process that is loosely coupled with the task of managing content. This means that our once feature-bloated CMS should now be an efficient tool for developers and web-designers to execute the website’s look and feel and features without having to juggle data-entry at the same time.

Essentials:

• Integration with the editorial workflow
• Light replication of data in the form of content instances that can be modified according to the rules of the presentation layer (the website)
• A role-based interface for web-designers to execute the Information Architecture (IA) and Interaction Design (IxD) of the website, and apply presentation rules to content instances
• A role-based interface for developers to visually access an manipulate data specifically related to the features and functionality of the website
• An API for developers (font-end and back-end) to interact with content for enhanced presentation purposes or develop features for content dissemination

The marketers behind most CMSs tend to advertise the ability to manage all of a site’s information in one place, but they forget that information does not begin and end with the CMS. Content needs to live on in a universally accessible and secure location and should in all likelihood be subject to both the organization’s information governance policies and content strategy.

Given the above, we must now assert that a website should not to be used as an organization’s information warehouse, and that the concept of a content management system is most definitely a misnomer.

The solution that manages the nuts and bolts of a website is a system designed to do exactly that (and perhaps a little bit more if you need it to), but it should not be responsible for the long-term management of content.

This now leaves us with answering the workflow issue.

The Editorial Workflow

The editorial workflow is a system designed to support the creation and governance of content. All of the objects that comprise content (subject matter, media, resources, etc) are managed and governed by this system.

We can expect that a system like this can get convoluted and complex very quickly, but let’s distil things down to essentials before we start thinking about the additional requirements that are needed to support the essentials.

Essentials:

• Integration with desktop systems/software (e.g. minimum: importing documents into the workflow; ideal: leveraging existing software like word processors to provide a familiar interface)
• Version control and revision history to track the changes that are applied to a single unit of content
• The ability to apply a strong taxonomy with support for folksonomy
• The ability to link a unit of content with a collection of [supporting] source material (resource management)
• The ability to promote a unit or collection of content from one user to another
• Ensure access to the workflow is governed by user-profiles
• Ensure that interfaces for the workflow customized according to roles and preferences
• The ability to audit the collective content inventory (reporting)
• The ability to provide data mappings

The above list address both process and the need for flexibility for organizations that might have a strict or collaborative workflow.

Some considerations:

• Not all content is created equal, meaning that while text is the easiest to manipulate and consume, the method of presentation for the subject matter is what people experience; organizations will produce content in many forms—text being the most common—and the workflow is there to track and move it along from one process to the next. Assembly and integration into the presentation layer should handled elsewhere, e.g. promoted to another process.
• The workflow overlays the repository and it’s complexity, meaning that while content is still created by people it needs to reside somewhere and in some mutable form—a database for all intents and purposes; however, that does not mean that the complexity of the database be reflected in the user-experience. Quite the opposite is needed.

Sounds like a tall order? It’s not—the only thing that makes software complex is our unrealistic expectations. But we still need something to bridge the gap between the delivery mechanism and the editorial process.

The Secret Sauce: Data-mapping (aka, our “bridge”)

What is it?

Data mapping* is the process of creating data element mappings between two distinct data models. Data mapping is used as a first step for a wide variety of data integration tasks including:

• Data transformation or data mediation between a data source and a destination
• Identification of data relationships as part of data lineage analysis
• Discovery of hidden sensitive data such as the last four digits social security number hidden in another user id as part of a data masking or de-identification project
• Consolidation of multiple databases into a single data base and identifying redundant columns of data for consolidation or elimination

* Source: Wikipedia: Data Mapping

The point that we’re most interested in here is: “Data transformation or data mediation between a data source and a destination”

What we want to do is map content that resides in the editorial workflow to areas in the presentation layer (the website templates, pages, parts, elements, what-have-you). This means that we are only referencing the source content, storing an instance of that content, and applying presentation rules derived from the presentation layer (the website).

Let me re-iterate that: the intent is to avoid directly handling and manipulating the source material.

Further considerations:

• Instances of content are loosely-coupled, such that changes made to the source content do not necessarily affect the instance in the presentation layer until explicitly updated—we do this to preserve workflow and ensure governance
• Content changes are one-way, meaning that instances of content are just that—modification of the instances, such as formatting, do not necessarily affect the source content—we do this to maintain the integrity of the source content and ensure compliance with governance policies
• Instances are disposable, meaning that an instance of content might have a limited shelf-life; once decommissioned, the instance does not disappear completely. It still exists in it’s raw form in the editorial workflow

The reason we implement data mapping is simple: A CMS is a tactical system and should be decoupled as much as possible from the workflow, which is an operational system.

Effecting Change

For the record, this is why I think this approach would work:

1. The approach aligns with user’s needs (not wants)—we focus only on what the end user needs, and build only the features and systems that will help that end user be productive and efficient.
2. The approach bridges a fundamental gap between software and process—that is, it brings people back into the equation.
3. We are not re-inventing the wheel—that is to say that traditional models and workflows have continuously proven to work, and we can learn a lot from the hard lessons others have had to struggle through.

I originally wrote this segment of the article to reflect the top three reasons why this approach would work. Instead, I changed my mind half-way through to reflect the crux of my argument: Content begins with people and ends with people.

That is the single fundamental that we need to understand.

I wish I could simply say that the only reason why this approach would work is that, “We need it to,” but that would be pure fantasy. In the real world we’re faced with an infuriating mess of business requirements, politics, and budget constraints.

If we’re going to effect change, we need to build an effective business case that brings people back into focus, and only you—yes, you—can do that. If you’re a consumer, developer, or in a position to make these kinds of critical decisions, you have an opportunity (and responsibility to yourself and the people who work with you) to choose a better way.

What’s Left?

I’ll round this off with a challenge to the industry and to consumers. My hope is that someone with enough patience to have read through this rather long-winded series of articles, will embrace the fundamentals and concepts proposed here and evangelize them.

A Message for CMS Developers & Marketers

I am not alone in feeling that software falls short of our expectations when it comes to managing content; after all, we see content published everyday and in all manner of forms.

It should not be this painful.

As a response to the overwhelming volume of poor implementations of content management software currently being marketed, I say this:

Forget the bloated features. Forget about development paths and methodologies; spare us the complexity. The act of managing content should not be obfuscated by deep click-paths or radical dependencies upon development skills or fanatic devotion to technology—it should begin and end with the end user (we, your true customers) in mind.

We want software that helps us do our jobs better, not by imposing what you feel should be our workflow and methodology—we’ll determine that, thank you very much—but by supporting our processes with tools designed to promote efficiency and with productivity in mind.

A Message for CMS Users

We are part of the problem and we need to make a full stop. We need to re-assess our current expectations of a CMS are and what is realistic.

Forget the marketing crap. You’ve been misled.

Your CMS is broken. You know it. I know it. But does your company’s leadership—the decision-makers who bought into the CMS know it? Does your IT group resent you for having to do your job on top of dealing with their own?

You need to speak up.

You need to find a way to clearly articulate why your CMS is broken, and influence your decision makers to move in the right direction: not by wasting more time and money on trying to fix what was broken from the beginning, but by stepping back and re-evaluating expectations.

You know that you hate wasting time and feeling incompetent and frustrated—its especially frustrating when you see it done so well in other forms. You want that. And by ‘that’ you mean the process(es) that help traditional media get their content from concept to publication.

Adopting a better approach begins with knowing what you really need and tempering your expectations with pragmatism. You need to build a compelling business case for change.

Author’s Note: Considering the subject matter and length of this particular article, I’ve decided to split it into two separate articles.

Related Articles:

1. How to Fix Your Broken CMS: Part 1
2. How to Fix Your Broken CMS: Part 2

In recent weeks I’ve been fielding a number of questions from prospective clients and visitors to my site regarding criterion for selecting the right CMS for their website. More often than not, I tend to direct them to an article I wrote previously on this particular subject: Top 3 Myths of Content Management Systems – Feb. 6th, 2009

The article offers some recommendations on selecting the right CMS for your organization, and some insights into common myths surrounding CMSs in general; however, the article does not necessarily provide the desired criterion for determining what makes a good CMS (or not).

The reality is that they are all pretty much the same—big (and getting bigger), feature-bloated, and a serious impediment for efficiency.

In short: your CMS can most certainly be considered a serious productivity killer.

From my perspective, the issues I’ve mentioned above stem from a series of false expectations on the part of CMS consumers that exploited by CMS developers by and large.

Read on…

Background

In my previous article I ranked the following as the number one myth surrounding CMSs:

“Myth No. 1: A CMS Should Manage Everything”

The statement asserts what I feel to be one of the most misleading notions of CMSs—the ability of a single software solution to manage every aspect of a website. After further consideration on this particular myth’s origins, I’ve come to realize that most of this stems from aggressive and misleading software marketing. And we—the consumers—are partially to blame for this.

Why?

For some absurd reason, we have this strange notion that a single solution is all we need, and in response, software vendors develop and market to that notion. The current market is saturated by systems both open-source and licensed and all of them tend to suffer from the same problem: feature-bloating.

Feature-boating is one of the tell-tale signs—to me—that a solution is trying to be too many things for too many people. The solution in question is trying hard to manage too many things when really it should only manage a handful of tasks or better: support a well thought out workflow that is tailored to the organization.

It seems to me that the software vendors—CMS developers in this case—tend to forget the end user and their experience.

The Tired Debate(s)

There are several ongoing debates about the merits and flaws of content management systems and content management in general. Chief amongst these debates are the following:

• Content Management Systems are for IT only:
  The notion of managing the assets and objects of a website are the sole responsibility of IT for the simple fact that it is seen as a technical task and not an operational responsibility.
• Distribute the responsibility of managing content:
  The notion of decentralizing content management and enabling “content owners”—those seen to be subject matter experts or authors—to take responsibility of conceptualizing and publishing their content.

These are diametrically opposing views serve to illustrate the chasm dividing opinion as to how to circumvent the issue of poorly implemented CMSs. There are strong advocates of better practices and better approaches to managing content, with some strong arguments and proposals in favour of better processes.

The Perspective

For the most part these debates only touch the surface of the issue. The typical approach/solution is to look at the the type and makeup of the organization, its stakeholders, and their particular roles/responsibilities as it applies to the website’s business requirements. At that point, whomever is in charge of making the ‘big decision’ then selects a solution with enough features to address 80-90% of these business requirements.

The selection of a CMS is almost as politically driven as the content that it is supposed to manage.

The resulting solutions places the organization back into the same vicious cycle created by lack of infrastructure, inhuman methodologies, and an understandable fear of technology. As a result, expectations are not met and the organization falls prey to its old habits, falling back into old patterns.

And the familiar debate begins anew.

A Different Approach to The Problem

What if we’re looking at the issue from the wrong perspective? What if it’s not enough to simply circumvent the issue with more systems and software?

It seems to me that given the emphasis on trying to become software agnostic by re-focusing on process alone, or attempting to become software-gnostic by relying exclusively on the software, we overlook the fundamental problem: the software we choose is still broken.

What we should be doing is focus on the following:

1. A sound editorial process—a tailored (read: organization specific) workflow for getting content from concept to creation and eventually online.
2. A better understanding of what is content vs. resources—the difference between the subject matter of a website and the assets and objects that help to communicate the subject matter.
3. A shift in software development from Features to User Experience informed by Content Strategy—a fundamental movement by software vendors to move away from creating yet-another-CMS-with-identical-features-as-it’s-predecessors (accepting that the market will buy into software that addresses a fundamental need rather than a perceived notion).

The last two points—previously mentioned—are perhaps the two most underappreciated facets of building a better solution.

Resources vs. Content

In 2005 Adam Mathes published an interesting paper titled, “Source vs. Resource Ontology”. In his paper, Mathes attempts to present a better definition of resources in the context of electronic documents on the web.

There are some interesting insights in his work, and I particularly appreciate his pragmatic view of what resources are perceived to be in the real world.

A significant issue is that even pages we often refer to as being static are not in a strict sense, static, complicating things. “Small” edits over time, for example spelling corrections, change the resource content depending on your perspective. In many cases a “base” of static content is surrounded by dynamic content. For example, a news article that contains advertising. The “article” in one sense doesn’t change, but it is a dynamic resource in an important sense as the advertisements change. Other examples of small amounts of dynamic content in generally static resource include having the current day and time displayed on a page, even if the rest of the page is unchanged. Adam Mathes, 2005

This brings me to my point: we’ve been led to believe—through pervasive feature-focused marketing—that CMSs are able to effectively manage all aspects, assets, and objects of a website, e.g. “the content”. Resource are not Content. Resources are resources, and a CMS is little better than a crippled operating system sitting on top of a very complex database.

“Content” in the context of a CMS is both erroneous and problematic. It is erroneous for the fact that the fundamental experience of web is still text-based, and this is evidenced by:

1. Continued emphasis on producing text-based content first and media later;
2. Reliance on text-based search
3. Ease of access

The notion is problematic for the following reasons:

1. Content is abstracted to the point that a single piece of information cannot be distinguished from another by the fact that the “system” sees all as being equal. And often we see CMSs without strong implementations of a Taxonomy or Folksonomy solution to give the resources any meaning.
   Note: abstraction is necessary where software is concerned—after all, defining meaning and purpose is a human’s task and not the sole province of the the software; however, you still need your software to support that fundamental task.
2. As we incorporate more resources to communicate the subject matter of our content, the software intended to manage the resources requires a proportionate amount of systems or features to “connect-the-dots”—meaning that a a software’s complexity can be directly linked to the degree of abstraction as previously described. What we end up with is more “power tools for developers” and less productivity for those responsible for the long-term management of content (read: real people).
   Victor Lombardi’s article on Boxes and Arrows is an excellent resource that presents a good case for managing the complexity of content management systems.
3. CMSs emerge on the market with nearly identical features and with only small variations on their approach—and yet again, we still experience the emphasis on short-term development and less on long-term strategy and governance.

Emphasise “User Experience & Content Strategy” vs. “Software Features”

So far, I’ve made reference to several sources that go back as far as 2004—what that simply indicates is that serious issues with CMSs are not an emerging trend. They are in my observation, a continuing trend. And we continue to support that trend.

We the consumers—being a fundamental contributor to the problem of CMSs—have made it acceptable for software vendors to saturate the market with products that miss the mark completely when it comes to addressing a fundamental aspect of content management: Content begins with people and ends with people.

The Impact of Poor CMS implementations

If I am to sum up the impact of a poor CMS implementation it would be, quite simply: Frustration and Abandonment.

Both Erin Kissane, and Jeff Cram blogged about their particular frustrations and perspectives on CMSs and CMS implementations and their impacts on the organization. What’s interesting in both articles is that we see the continuing trend of the CMS getting in the way of efficiency and productivity. While Cram’s article nicely illustrates the frustrations of a poor CMS implementation (are there any good ones?), Kissane urges us to refocus on workflow.

…Create a workflow that works for your organization. Make sure your CMS supports that workflow. Erin Kissane

Users don’t care about the technology; they take it for granted that the technology will be there to support their jobs, but the sad reality is that the technology gets in the way. Again.

What users do care about is their experience with the CMS. Was it a good experience? Was it a bad experience? These are questions that influence decisions as to whether or not they will repeat the experience or abandon it.

When we talk about “user experience” in the context of a CMS, we’re talking about aspects like productivity, efficiency, and overall comfort level with the system in question. It is pretty clear to me that the vast majority of CMS developers take it for granted that their particular methodology of working with content (ahem, resources) is The Way To Go with little consideration for reality. And reality in this case is the end-user’s experience.

On Software Features

Software developers have proven that their ability to build pretty much anything in terms of systems to facilitate getting data into and out of a database. The feature lists of many of the available CMSs alone are enough to illustrate that point. But features alone do not make one CMS better than the next.

Unfortunately for the rest of us, those feature-bloated systems fall short in fulfilling expectations—one expectation in particular is that: I as a subject matter expert or content author should be able contribute to the creation of a body of information, without getting lost in the nuts and bolts of my CMS or without fear of liability (read: breaking the system).

Packing more features into the CMS compounds the issue. Stop. Take a good look at the audience—the people—who end up with the task of actually using the CMS after the development team has implemented it.

When it comes to audiences, it doesn’t matter if it’s an individual, a small business, or an enterprise-level organization that is using the CMS—they all have at least one thing in common: the end users are people who have jobs to do, not a heck of a lot of time to do it, and likely don’t have the patience to tackle the learning curb for that nifty new Cadillac of CMS [that is supposed to make their lives easier].

And when it comes to enterprise—there’s just a whole heck of a lot more of the same folks who share those same traits.

On Content Strategy

When it comes to the user experience with Content Management Systems, it has become increasingly difficult to discuss the topic without bringing Content Strategy into the conversation. And for good reason.

You cannot effectively implement a CMS solution without the Content Strategy to inform its use or role in the process.

There are some refreshing forward-thinkers out there like Kristina Halvorson, who make a compelling case for the necessity of a Content Strategy to help organizations effectively define and identify their priorities for content, and to teach better/pragmatic ways of approaching content for the web. In her book, Halvorson addresses the concept of a strong workflow to audit, capture, and produce better content through several phases.

What is compelling about her argument is that it is once again focused on people, not software.

Halvorson’s book, Content Strategy for the Web, does not cover—in full—CMS strategy (Software selection, design, and implementation)*

* Content Strategy for the Web, Kristina Halvorson, 2010, “What this Book Is Not”

Fundamentals First

Before we can start to improve the software we must also examine other models that have implemented a solid combination of software and process to provide a productive and efficient workflow that, well, works.

Case Study: The Traditional Editorial Process (aka Publication Production):

In an traditional news publication, the responsibility of conceptualizing/determining what is news worthy is left in the hands of the editors and may also be subject to a schedule [in the case of features].

It is the responsibility of the writing staff to develop the stories and craft them into something appropriate for the readership. Stories are then subject to editorial review and approvals, after which, it is promoted to the production cycle.

It is the responsibility of the production team to format the content into a presentable form—ready for mass consumption.

In the above example, we might see a single story evolve from concept to creation, and further evolution through review, contribution, and editing until it’s ready for publication. This is one flavour of the traditional editorial process, and may be present in more intricate or rudimentary forms in other organizations.

What’s notable about this example:

• A single story goes through a process and is handled by more than just one person (editorial process)
• A single story is always subject to a form of governance (editorial responsibility)
• The resulting story is then delegated to another process that shapes it according to the requirements of the medium (presentation)
• The system described above is a collection of several processes—the system of Publication Production.

What is still amazing to me is the fact that despite the evolution of software and the emergence of technology, the editorial process is still relevant. And they’ve been doing this every single day for decades without pause.

That begs the question: why—with all of the technology and knowledge at our disposal—are the content management systems unable to effectively replicate the efficiency and scalability of a traditional publication system?

The answer: software is the impediment—we the consumers and developers—expect software to do anything and everything with our content, forgetting that first and foremost that content begins with people and ends with people.

What we want is a solution (or set of solutions) that enables people to contribute to an organization’s collective knowledge, and ensure that the responsibility of disseminating content is left in the hands of people who [should] know where it goes and how best to present it.

A Little About the End Users

We need to recognize a few things about the typical end user:

1. Software developers have proven—ad nauseum—their ability to manipulate data in all kinds of interesting ways—the typical end user doesn’t care.
2. The typical end user doesn’t care about the fact that your CMS uses stored procedures or that you’re using ORM for database modeling.
3. The typical end user doesn’t care a wit about the technical marvels you—the software developer—have pulled off in order to make your CMS function the way it does.
4. The typical end user is concerned largely with the fact that they have a job to do and very little time to do it, but instead are starring dumbfounded at a screen loaded with all kinds of strange and confusing doodads that require a user-manuals thick enough to break windows.
5. Lastly, [most] people care about people—human interaction is essential in organizations, and the reason workflows, work, is due to human interaction that drives the workflow.

Considerations

This leaves us with a fundamental question to answer:

Q: If the goal is to de-emphasise feature development and emphasise developing better user-experiences for the end user, how do we do that?

A: We start by clearly establishing expectations (wants vs. needs) of what a CMS is and what it should do for us—the end users, and stop letting the software dictate our limitations.

A Unifying Concept

All of this talk about state-of-the-market and fundamentals is all well and good, but putting it to practice—truly developing and empowering CMS—is another thing altogether.

What we need is a unifying concept: the flux-capacitor to transcend the barrier of… well, you get the picture.

What this means is:

1. If we’re going to start with the user, we need to ensure we address the end user’s fundamental expectations by providing an experience that is designed for them, and not a homogenized user experience that is meaningless—one size does not fit all.
2. Content should not be managed in a silo but as part of a collaborative workflow—informed by strategy*, regulated through governance, and supported by technology.
3. The system should not enforce workflow through strict methodology or present technical barriers but provide flexibility—allowing greater access to the process/system to effect productivity and promote efficiency.

* I wrote earlier about the necessity of a CMS being driven by strategy—forgive the double-speak—but when I talk about strategy in the context of a CMS, I do mean both the Operational Strategy (the workflow, logistics, etc) and the Content Strategy (the heart and soul of Content).

Let’s summarize what we’ve been talking about so far into a set of actionable principles:

1. A CMS should not be the start-point and end-point of a content creation process (the editorial workflow), in fact managing content should be considered an on-going process.
2. A CMS should be a system that allows instances of content to be formatted and manipulated according to the requirements of the presentation layer (the website). Instances by nature can be disposable.
3. A CMS should be—at the very least—a set of loosely coupled systems: the first to facilitate the editorial workflow; and the second to facilitate production/publication for the presentation layer

With these concepts in mind, let’s focus on what’s needed executing the concept…

Cont’d, How to Fix Your Broken CMS: Part 2

Change is good.

What’s New?

A number of things have changed over the past few months — my current circumstances not withstanding — I’m now in the position where I’m able to take on consulting work and wanted to communicate that fundamental change on many levels (the most obvious place to start being my blog, of course).

I’ve talked about shifting focuses on this site for the last couple of years, but never had the time or need to push the change forward. I do now and what you’re looking at is the result. Where before my blog mostly concentrated on the things that interest me (it still does), it’s taken second stage to the need to showcase my work in a meaningful way.

You can learn more about what I offer as a consultant here, but if you’re more interested in the work I’ve done, you can take a look at a cross section of that material here.

What To Expect

I’ll still be continuing my series on WordPress Theme Development and the ongoing updates to some of the other minor series, but I will also be posting about the work I’ve completed in the form of case studies. My hope is that I can share some of my experience in a way that is meaningful (without putting me out of work ).

About This Theme

This new WordPress theme is called “Dusk”, currently at version 0.5, as I’m quite sure there will be a number of tweaks to the design and features over the coming weeks.

It’s possible that I will release this theme to the public in a year or so when I’m ready to re-design – or perhaps I’ll market it as a premium theme (who knows). But I do plan to release it at some point as I have with my other themes.

The Design Concept

The inspiration for this new theme came largely from watercolour paintings – mostly the texture and the vibrancy of colours, but also the techniques involved in working with the medium.

I felt that it would be a strong juxtaposition to the more technical and rigid structure of the content – one balancing the other. The primary focus of this theme is showcasing my work first and my writing second. The layout for the main page was given a unique structure most appropriate to the type of blended content without overpower the other.

Behind The Design

“Dusk” is based on the 960px grid concept and implemented using Blueprint CSS. I’ve been focusing on Blueprint CSS lately as it (amongst others) expedites some of the common CSS development tasks, allowing me to focus on ensuring the creative aspects of a design aren’t compromised. This of course assumes that the design adheres to the 960px grid concept (and this one does).

Final Thoughts

If you’re interested in how I might help your project succeed, I can help you in one capacity or another. Don’t hesitate to ask

The math makes my head hurt already.

If any when you do manage to find a handful of solutions that you feel might answer your particular needs, your challenge will be in settling on one system out of many. How do you decide what stays and what goes?

Here are some of the top three myths that lead people astray:

Myth No. 3 — A CMS is ready “out of the box”.

General Perception:

Content Management Systems provide website administrators with everything they need to launch, manage, and maintain a website with little to no effort.

Reality Check:

Launching a website is never as easy as 1, 2, 3.

The level of effort and resources required to get a CMS up and running corresponds directly to the business requirements of the site, and size/complexity of the CMS.

Forget what was advertized on the box.

If you’re in a position where you’re still thinking about which CMS to go with, consider talking to customers who are actively using the software. Compare notes. Ask specifically about how key features worked for them or more importantly, what didn’t work for them and why.

This is a good opportunity to consider your own requirements for needing a CMS. It’s easy to get lost in all the hype and lose sight of why you needed it in the first place, so put your needs into writing and use your list as a guide post when evaluating features.

Myth No. 2 — Anyone can use a CMS.

General Perception:

“If you can use MS Word, you can use a CMS”.

Reality Check:

Understand that every CMS subscribes to a different philosophy when it comes to working with content. The methodology behind the workflow might make sense for one group and be totally alien to another, which makes it more difficult when you’re attempting to do feature comparisons (ultimately, they all follow a few common strategies).

It comes down to the User Experience.

You cannot legitimately equate the whole experience of using a CMS to something like MS Word. You can legitimately equate a feature of the CMS to MS Word (if it exists).

The User Experience between a system like “Joomla!”, “Magnolia”, or “Drupal” are dramatically different. I won’t get too deep into the how and why of things, but suffice to say that if your comparison between package was based only on side-by-side comparisons of their interfaces, you’d immediately see how different they are from each other.

Consider who will actually be using the CMS. Is it a group of developers or is it a group off general staffers tasked with the responsibility? Think about the end user here; it’s not the site visitor who will be directly affected by the CMS, but the people managing the content.

What kind of interface are they most comfortable using (WYSIWYG, form based, code)? Do any of them have working experience with HTML, CSS or a scripting language?

This is your red flag.

Stop.

Take a step back and look to your content team — get their input.

Myth No. 1 — A CMS should manage everything.

General Perception:

Content Management Systems are designed to manage all of a website’s content and features.

Reality Check:

Content Management Systems come in all flavours, but not one of them handles every facet of a website in an elegant manner (thus the reasons for Myth No. 2, 3).

I’m not quite sure how this myth started, but I’m sure anyone who has had the opportunity to work with a CMS understands this: there is an expectation that a CMS has the ability manage the content of every single asset, feature, function, or concept in a given website.

This is so – dangerously – far from the truth.

Think about it this way: Your CMS does not define your website.

Read that last sentence again. Memorize it for the next time you’re making recommendations to your clients or shopping around for yourself.

A CMS is designed to help you manage content, but unless engineered to be, two websites are never the same beast. Content volume, features, design, strategies can vary wildly, and so it is next to impossible to have a single CMS (out of the box) manage every aspect of a website without running into the need to extend, include plug-ins, or write unique code to support the site’s particular requirements.

Consider that feat the Holy Grail of all CMS.

Be realistic about what you need a CMS to do. Think about the content of your site, and if you haven’t already, consider bringing on a Content Strategist to help you define the Information Architecture.

An important thing you should try to understand is that you don’t need one tool to manage everything – in the real world, you need a toolbox full of the the most reliable, appropriate tools to help you manage your website content.

Things to consider when you do manage to find a suitable CMS.

It’s easy to get misled by the marketing and hype, and technical jargon around a CMS. If you can only remember three things before you start searching, keep the following in mind:

1. Find a tool that your organization can implement: Speak to your development team/IT to get a realistic scope on what it will take to get up and running.
2. Realize who will actually use the software: Most importantly, interview your content management group to find out what their expectations (and level of experience) is with a CMS or similar software.
3. Develop a content strategy: Interview the key stakeholders to find out what the common needs are, and what the business requirements are for the website – don’t engineer your content to fit the limitations of one tool.

Ultimately speaking, a CMS is just one tool for the task of managing the content of your website, and sometimes you need different tools to do the job. There is no doubt that finding the right tool is going to be an easy task – expect a difficult road – but with a little forethought, some planning, and a good understanding of your needs (not wants), choosing a CMS will be less painful in the long run.

Here are a few screenshots of the product:

Features

Here are some of the features from the website:

Unlimited hierarchically structured page navigation menu
The page navigation menu provides critical information and functions. It allows you to perform quickly common actions on pages and shows how information has been organized.

Drag and drop page ordering
This function simplifies the organization of your site’s pages. It makes new sorting arrangements of pages possible.

Flexible page content: body, sidebar, extended, summary
Each page can have its own customized parts (divisions). It can be ‘extended’ text for news, or ‘summary’ for article: you can define whatever you want, whenever you want. These can even be used for extended metadata fields.

Per page layout customization
Pages can have their own layout, or can inherit the layout of the parent page, or they can reuse another page layout. This allows the site owner to make every page look exactly as desired.

Simple and reusable content snippets
You can define ‘snippets’: small pieces of content used across several pages, like page headers or footers, or contact info, etc. This means less cut-and-paste text in your pages. This will reduce your modification time when you need to add, remove or change the text in it.

Other

• Password protected administration.
• Simple user and permission management.
• File manager (plugin) allows you to upload, browse and edit files.

For the most part, you may be stuck with using the setup that the Theme Designer decided to adopt.

Blogs typically take one of three common approaches to displaying posts:

1. Posts are displayed as excerpts with a “read more” link.
2. Posts are displayed with the full body of the posting.
3. Only one post is displayed with pagination available.

The first approach — the most common of the three — is likely a result of the Theme Designer choosing to use the out-of-the-box functionality of the blogging software (and to be fair, it is likely the most efficient); however, not everyone wants a cookie cutter solution to displaying their posts.

The reality is such that you don’t actually need to do a lot of work to get your blog postings to appear the way you want them to. I can’t speak for other blogging software packages, but when it comes to WordPress, there are a many techniques you can apply to customize your postings.

WordPress – The Loop

The meat-and-potatoes of WordPress is “The Loop“. If you’ve ever attempted to customize a WordPress theme, it’s likely you’ve encountered this The Loop (essentially a “while” loop). This is an example of a very simple loop (taken from the WordPress codex):

   1: if (have_posts()) :

   2:    while (have_posts()) :

   3:       the_post();

   4:       the_content();

   5:    endwhile;

   6: endif;

This is a better explanation if you’re not too familiar with code:

The Loop is used by WordPress to display each of your posts. Using The Loop, WordPress processes each of the posts to be displayed on the current page and formats them according to how they match specified criteria within The Loop tags.

If you examine one of the template files of your theme you may encounter a more complicated version of the above snippet.  The Loop is where we are going to start to customize the appearance of your postings.

Postings

A post in WordPress is comprised of a number of elements such as the Title of the post, the Content of the post, and assorted information like the Date/Time, etc. In the common approaches, all of the postings share the exact same format and display identical information.

Boring.

But it doesn’t have to be this way. The developers of WordPress were smart enough to realize that while the majority of theme designers don’t mind this type of homogenous approach, there are a few Theme Designers out there who prefer not to follow this pattern. As such, WordPress is built with with the ability to modify how The Loop is applied.

There are several approaches to modifying The Loop, but the two that I prefer are:

1. Use query_posts with counter and offset.
2. Use The Loop with counter and conditions.

The Loop With query_posts(…)

It took me a while to understand what this feature did; quite simply put, it adds additional parameters in the The Loop to instruct WordPress on what to output.

   1: <?php query_posts('showposts=1'); ?>

   2: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

The snippet above was taken from one of my WordPress themes. In the theme, I use the above approach to display ONLY my most recent posting in full. Here’s a simplified version of the markup I use:

   1: <!-- set main-entry -->

   2: <?php query_posts('showposts=1'); ?>

   3: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

   4: <div class="main-entry">

   5:     <h2><a href="<?php the_permalink(); ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h2>

   6:     <?php //the post meta ?>

   7:     <ul class="meta-top">

   8:         <li><strong>Posted:</strong> <?php the_time('F j, Y'); ?></li>

   9:         <li><strong>Author:</strong>  <?php the_author(); ?></li>

  10:         <li><strong>Filed under:</strong> <?php the_category(','); ?></li>

  11:         <li><?php if( get_the_tags() != NULL ) { the_tags('<strong>Tags:</strong> ',', '); }else{ echo "<strong>Tags:</strong> No tags set for this entry."; }?></li>

  12:     </ul>

  13:     <?php

  14:         the_content('Read more...');

  15:     ?>

  16: </div>

  17: <?php endwhile; endif; ?>

  18: <!-- end main-entry -->

In this example, The Loop is executed only once and only once. The query_posts() function passes instructions to The Loop to show only one post (using query_posts(‘showposts=1′)). While The Loop is executed, it will output all of the post’s information that I’ve specified using the appropriate Post tags.

NOTE: I have set the container <div> class to “main-entry”. This references a rule in my CSS file that will style the output accordingly.

Unfortunately, you’re stuck with only one posting on your page. We need to display older postings as well, and ideally in a format that is different than the most recent.

As previously mentioned, The Loop was executed only once with the example above. This is a powerful feature of query_posts(), in that you have a tremendous amount of control over The Loop — in this case, how many times it is executed.

To render the older postings, you can do this:

   1: <!-- set past-entry -->

   2: <?php query_posts('showposts=9&offset=1'); ?>

   3: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

   4: <div class="past-entry">

   5:     <ul class="dateblock left">

   6:         <li class="top"><?php the_time('M Y'); ?></li>

   7:         <li class="bottom"><?php the_time('j'); ?></li>

   8:     </ul>

   9:     <div class="entry-content">

  10:         <h1><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h1>

  11:         <?php

  12:             the_excerpt();

  13:         ?>

  14:     </div>

  15: </div>

  16: <?php endwhile; endif; ?>

  17: <!-- end past-entry -->

Aside from the simpler markup, the core difference between this second snippet and the first are the instructions/parameters in query_posts(), and the CSS class which is referenced.

   1: <?php query_posts('showposts=9&offset=1'); ?>

   2: <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

   3: <div class="past-entry">

If you combine both of the examples above, what you’ll find is that you’re actually running The Loop twice — in the first instance, The Loop only outputs the most recent post. In the second instance, it skips over the most recent  post completely, and outputs as many older posts as you defined in query_posts().

NOTE: if you examine the parameters in the second query_posts() instance, you should see “showposts=9&offset=1” — this will output 10 posts in total on your page, where 9 such posts are older.

Styling The Posts

What you need now are two CSS rules which define:

1. “main-entry”
2. “past-entry”

   1: /* CSS Snippet */

   2: #post-container div.main-entry {

   3:     background-color: #CCCCCC;

   4:     color: #000000;

   5:     font-size: 1em;

   6: }

   7:

   8: #post-container div.past-entry {

   9:     background-color: #ffffff;

  10:     color:#333333;

  11:     font-size: .92em;

  12: }

The XHTML markup does not have to be different between these posts, and as you can see in the CSS snippet above, you can get away with as little as displaying a different background color, font color or a larger font size.

The Caveat

Yes, there is a downside to using query_posts(). Programmatically speaking, you should try to optimize the number of queries you execute against your database. Since WordPress is largely database driven, you can expect a high volume of requests on any given page. Using query_posts() should be done sparingly (I limit it’s use to the homepage of my blog).

Also, if you are wanting to support pagination, you will need to do a little more work to setup the query properly — you can read more about it here.

The Loop With Counter & Conditions

The simplest method to determine and style your most recent post in contrast to your older postings is a pure implementation of “The Loop”. This implementation also relies on using a counter to keep track of how many posts you’re outputting (as determined by your WordPress settings), as well as a condition to determine which class to reference when styling the output.

Here is an example of this in action:

   1: <?php

   2:     if (have_posts()) {

   3:         // the counter (initialized to 0 );

   4:         $n = 0;

   5:         // the while loop

   6:         while (have_posts()) {

   7:             // the CSS class to apply

   8:             $class = ( $n == 0 ) ? "main-entry" : "past-entry";

   9: ?>

  10:             <!-- set post -->

  11:             <div class="<?php echo $class; ?>">

  12:                 <ul class="dateblock">

  13:                     <li class="top"><?php the_time('M Y'); ?></li>

  14:                     <li class="bottom"><?php the_time('j'); ?></li>

  15:                 </ul>

  16:                 <div class="entry-content">

  17:                     <h1><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h1>

  18:                     <?php

  19:                         if( $n == 0 ) {

  20:                             the_content();

  21:                         }else {

  22:                             the_excerpt();

  23:                         }

  24:                     ?>

  25:                 </div>

  26:             </div>

  27:             <!-- set post -->

  28:

  29: <?php

  30:             // incriment the counter

  31:             $n .= 1;

  32:         }

  33:

  34:     }

  35: ?>

As you can see from the example above, we’ve taken a basic instance of The Loop and added in two variables:

1. $n — this is the counter used to determine which which is the most recent (starting at “0″ — the first).
2. $class — this is the CSS class that we want to reference (“main-entry” or “past-entry”).

The method and approach to styling the post is the same as the examples in query_posts(). The XHTML markup can be re-used between new and older postings, but this is not required. With a little work you can supply The Loop with two different sets of markup to render.

The Caveat

While this implementation is rather straight forward, it can get complicated quickly if you want to include more and more variations between postings. Each variation requires a little more forethought, and the appropriate conditions to determine what to do and what to render. What you may end up with is a lot of messy markup that is difficult to read.

Conclusion

It doesn’t take a lot of work to modify your WordPress template to render your most recent posting in a unique fashion. In some cases, you can download plugins to help you style your postings; for me, having to rely on additional plugins seems more overhead than is necessary. The techniques outlined in this article are only two of many such approaches (and certainly a manual approach).

Don’t feel as if you have to select one over the other. In fact, your writing style and your choice of template play a large part in determining which method is most appropriate.

Hi Chris,

I’m really curious on how you got that quote feature on your comment section. Do you mind sharing your code?

Cheers,
[author name omitted]

While this is not a new feature by and large, it is one that I thought would bring a sense of discussion to the linear WordPress comment format much like how forums work. I’ve attempted to use threaded commenting plugins, but they are ugly and overly complicated for something that should be fairly straight forward.

In any case, this is the JavaScript snippet that I wrote (you need jQuery, but comes with the theme)

// attach a function to the quote comment link
  $('a.quote-comment').click( function() {
      var tb = $('#comment');
      var strQuote = $(this).attr('title');
      // assign the value
      tb.val('<blockquote>' + strQuote + '</blockquote>');
      return false;
   });

This is the result:

There are a couple caveats to this feature

1. You can only quote one comment at a time, as I didn’t build in concatenation.
2. It is not parameterized so you’ll have to customize it for your own theme.
3. Requires some additional styling (no big deal).

If anyone wants to improve on this, feel free to share!

Sometimes you can have too much of a good thing, and WordPress is no exception. There are many plugins that offer surprisingly similar features with the exception that one might handle the same task in a slightly different manner.

Sifting through plugin lists isn’t fun either.

I thought I would share a short list of the WordPress plugins that I found to be useful without being too gimmicky.

Posts

Plugin: the_excerpt Reloaded

URL: http://guff.szub.net/2005/02/26/the_excerpt-reloaded/

Description: Displays the excerpt of a posting (or uses the content of your post if no excerpt is available), and formats the excerpt accordingly.

This plugin was developed in 2005, and there are other similar plugins that have come along since, but I like this one simply because it works as advertised. If you’ve downloaded and installed my theme, you’ll notice that I use it in areas such as the main posting, and in the archive or past postings.

Plugin: “Add to Any: Share/Save/Bookmark Button”

URL: http://wordpress.org/extend/plugins/add-to-any/

Description: Adding social bookmark features can be a bit of a pain, and implementations are inconsistent. This plugin takes the pain out of adding social bookmarking abilities to your postings using a very simple UI for the user to interact with.

Comments

Plugin: Get Recent Comments

URL: http://wordpress.org/extend/plugins/get-recent-comments/

Description: Displays a formatted list of the most recent comments on your site. This plugin has a number of new features, but I typically use only the basic features — for me it’s a time saver, as well as a quick and easy way to implement a comment list without a lot of work.

Archives

Plugin: SRG Clean Archives

URL: http://www.geekwithlaptop.com/projects/clean-archives/

Description: Displays a formatted list of your archived posts with additional functionality for animation and user interaction.

I just love the fact that I can take this plugin and output an archive with minimal fuss. I disable all of the additional features and apply my own CSS to customize the look and feel. It’s really quite easy, and if you’re into experimenting with some of the extra JavaScript features, you can come up with some fun results.

You don’t need a lot of plugins to enhance the features of your blog, and I personally recommend against relying heavily on plugins; instead, I do recommend that you pick plugins that effectively suit the features you need to communicate better on your blog.

Given that I am not the only one to encounter this issue, I thought I would share my recent experience and a work-around.

DISCLAIMER: Please note that I do not in any way advocate this as a permanent solution for any mass e-mail deployments on a budget. At best this article should be taken as a cautionary tale.

The Task

I developed an micro site for a client for an HR and team-building campaign. The micro site required internal users to claim their pre-assigned accounts through a simple “claim” URI provided in a email that was to be sent out after an internal event. One click; confirm the email address; accept a new user-defined password, and that was it. Simple and quick.

The Issue

The account claim workflow was simple, and my team and I had tested the system numerous times. We tested the standard exploits; we tested cross-location claims; we tested unorthodox methods of faking and breaking into the site. What we hadn’t tested as thoroughly was the e-mail deployment.

I made the assumption that we wouldn’t have issues with the email deployment since my team had done previous deployments for this particular client in the past. Easy peasy, right?

Not really.

The email was scheduled to deploy close to the end of the day yesterday. It went out. It came back. Rejected. As it turns out, I had also forgotten that the previous deployments were for external email lists — this was the first time we were handling a mass deployment to an internal employee list.

The Drama

By 9:30 this morning, I had a couple urgent notes from the client and spent the following hours following up with their IT department and our email service provider, along with our bulk e-mail distributor. It was then I found out that the email servers and the domain needed to be “white-listed” before any mass emails could filter through.

(You know those moments when you take a second and realized what a rookie mistake you just made — that was me this afternoon — email deployment cardinal sin numero uno).

By 4:00PM I was pretty much ready to hang myself after waiting for hours to hear back from the “deliverabily” department and the support desk to whom I submitted this rather urgent ticket. Not a fun day.

Desperate, I considered last resorts:

1. Have the client distribute the email themselves.

2. Set up a new account with a new provider specifically for this project.

3. Delay the deployment.

For various and obvious reasons, neither of the options were appealing to the client. The email deployment was 24 hours behind schedule at this point, and employees were chomping at the bit to claim their promised accounts on this micro site. It was time to fall back to some unorthodox means.

Enter Microsoft Word and Mail Merge (I feel dirty just writing this already).

The Solution

Mail Merge is one of those Microsoft Office features (there may be similar features in other products — I wouldn’t know), that is either loved or hated. I personally dislike it for the fact that it just wasn’t easy to use, and the lack of an intuitive workflow; however, it did come through for me today, so I’m going to cut it some slack.

Before we get started, this is what you should know:

1. If your target company has an IT policy in place to deal with bulk emails and spammers, you need to contact them first in order to get your e-mail server “white-listed”. No solution, even the one I’m outlining here, will get through a well-implemented IT policy. Read that last statement again and remember it.
2. You will need to provide the IT administrators at the target company with at least two things: the static IP address (possibly range) of your email server, and your the domain you are sending from. e.g. sender@somedomain.com — you will likely be asked to verify this through some simple test emails.
3. You will want to setup a new mailbox or profile through your Exchange server (contact your system admin for help on this). This will prevent you — your email account — from receiving a potentially overwhelming volume of bounce-backs or auto responses, etc.
4. If you have MS Outlook installed, start it up as you will need it to connect with your email server to send emails.
5. Lastly, you are definitely going to need some patience.

If you’ve done your due diligence and saw to it that the IT department of your target company has “white-listed” both your email server and domain, you can safely send a volume of emails through.

As with any bulk email deployments, you will also need a target list. Your list can come in one of several formats, the most common of which is a *.CSV formatted list.

I had several data fields in my list such as “first name”, “last name”, “email”, and “claimid”, so take some time before firing up MS Word to clean up your list.

NOTE: for the purpose of this article, I am using MS Office 2007

Step 1: Prepare your email list

Assuming that your list was previously validated, here are a couple house-keeping tasks that you might want to deal with first:

1. Ensure that your target list has the appropriate field/column headers.
2. Remove unnecessary fields.
3. Remove duplicates (mail merge helps you with this, but take the time to parse your list previous to using it).

I’m sure there are a number of best-practices you should keep in mind when dealing with email lists, but that’s not what this article is about (and it’s clear that I am not an authority or I wouldn’t be writing this article).

You can create a *.CSV using any text editor, but the most popular method for businesses is to take an existing Excel spreadsheet and save it as a *.CSV formatted document. Doing this will essentially strip out any proprietary document format information, but preserve the data, its structure, and order.

In this example I have two records (recipients) to whom I will send the email message to. I have four main fields which are denoted as follows (you can name and format them as you wish, this is just an example): [firstname], [lastname], [email], [claimid].

You will need all of the fields despite the fact that you may only use one or two of them for personalizing the email message.

The last step here is to save your *.XLS (*.XLSX if you’re using Office 2007) as a CSV, but before you do that, you should be aware that the application will display a couple of warnings regarding saving the file in a different format. To avoid multiple warning, simple delete out an unused worksheets from your document.

To save your file as a *.CSV you must do the following:

1. Select File > Save As.
2. When you see the “Save As” dialog, click on the “Save As Type” drop down and select “CSV (MS-DOS) *.csv” from the list. If you’re on a different platform (mac), select the appropriate encoding type (“CSV (Macintosh)”).
3. Click Save.

The first warning should pop up, which looks like this:

Click “Yes” to finish saving your document. If you did not delete any unused worksheets as I mentioned earlier, you may be prompted with a second warning; get past them and save out your CSV or use another application if the experience is becoming frustrating.

Step 2: Prepare Your Message

If you’re planning on sending out a mass email, you’ll need to have a message to send, and fields to populate. At this point you can fire up MS Word. You should be presented with a new document. Compose your message (or copy and paste it from whatever document you had originally composed it in), and create personalization fields. For example:

At this point it is safe to note that the Microsoft Office development team should seriously consider over-hauling this component for usability (their usability metrics be damned).

Step 3: Import Your Email List

This is the part that I had the most trouble with as I was both nervous about supplying the wrong fields, and generally hitting the wrong button that might cause MS Word to send the email “accidentally”. Zero points for usability Microsoft.

Jump back to MS Word and select the “Mailings” tab in the ribbon (if you’re using previous versions of MS Word, you’ll have to Google the location of that feature). Once you have selected the Mailing’s tab, you can click on the “Start Mail Merge” button to kick things off.

1. When you click the “Start Mail Merge” button, you will be presented with a short menu of choices.
2. Select the option “Email Messages” from the list.

Next, click on the “Select Recipients” button. You will be presented with three options in the drop-down list. Select “User Existing List…” from the options.

You will be presented with a “Select Data Source” dialog. Browse to the location where you saved your *.CSV and select the file and click “Open”. If you still have your CSV file open in Excel or another application, you may receive a prompt to open a “Read-only” copy or create a “Local” copy. Select read-only as that is about the only action we’re performing with the file.

If you’re curious to see the data you imported, click on “Edit Recipient List” in the main menu — you will get a dialog that lists the records in your *.CSV. There are a few useful aspects to this feature such as selecting and deselecting recipients, de-duping, sorting, and validation.

Moving on…

Step 4: Customize The Message Format

This next step is important (as are the following). You will need to personalize the email message along with some fields which are not readily apparent later on. The first thing you should do is customize the appearance of the recipient’s name. To do this, click on the “Address Block” button. You will receive a dialog that will assist you in choosing an appropriate format for the name. I’ve chosen the disable “Postal Code Insert” as those fields do not exist in my email list; however, the last option is worth considering — “Format address according to the destination country/region”. A sample of the output is displayed on the right-hand of the dialog.

Click “OK” when your settings are customized.

The next button beside “Address Block” (working from left to right), is “Greeting Line”. This feature allows you to create a greeting line such as: “Dear John Smith,” — going so far as to allow you to apply additional formatting. It can be useful for form messages, but for the purpose of this exercise, we’ll use the sample message and greeting like we created earlier.

The next thing you’re going to want to do (in fact, you can probably do this before some of the previous steps to personalizing the message), is match the fields in your CSV to the fields the typical Mail Merge expects. You can do this by clicking on the “Match Fields” button:

You will be presented with a small dialog which, if you’ve formatted your CSV properly will have automatically detected the matching fields, otherwise you will need to manually troll through the list and match the fields as needed. Since we have only a few fields to deal with, it shouldn’t be a big chore. If you recall, we have a fourth field “claimid”. We’ll get to that one in a moment.

Click “OK” to continue.

Step 5: Personalizing The Email Message

At this point the task is almost complete. You now have all the necessary mappings for your email list along with a working copy of your message. It is now time to insert the personalization fields.

To insert personalization fields perform the following steps:

1. Select [firstname] from the greeting line (first line).
2. Click on the “Insert Merge Field” button. You will be presented with a list of fields matching your email list.
3. Select “firstname” from the list.

What you should now see is the greeting line as it is customized with the fields. e.g.

Dear [firstname] [lastname], is now Dear «firstname» [lastname],

Repeat these steps for the last name and any other field you might want to insert into your message.

NOTE: since MS Word 2007 automatically converts text that looks like a URI into an html link, you will need to ensure that the link remains as plain text, especially if you are adding a personalization field. Allowing the application to automatically format your links does not mean it is correct. e.g http://www.somedomain.com/«claimid» may be parsed as:

<a href="http://www.somedomain.com/">http://www.somedomain.com/«claimid»</a>

Once you are finished with this step, you may want to use the “Auto Check for Errors” feature located here:

There are three options — the first of which is likely the most useful (and grief-free).

Step 6: Deploying The Email

This IS the last step, after which I highly recommend you take a breather and get yourself a beer, if only to calm the nervousness of relying on this method of deployment — believe me, it’s understandable.

To send your email message, click on the “Finish & Merge” button:

There are three options with this feature, but the one you’re going to want to use with this excercise is “Send E-mail Messages”. Selecting the last option will present you with a dialog (yet again); complete the dialog options before sending.

1. Select the field you’ve mapped for the recipient’s email address.
2. Supply a relevant subject line.
3. Select a message format (text or HTML).
4. Select how many recipients are to receive the message.

Click “OK” when you are done.

MS Word will now send your Mail Merged message(s) — individually — using MS Outlook. If you have not started the application, it will automatically prompt you to do so. To be safe, monitor your outbox and your sent messages to confirm that the email was deployed. Depending on the volume of email recipients in your list, you should have just as many individual emails sitting in your sent/outbox.

That’s it. You’re done. Go get a beer (I need one now after writing this).

Conclusion

As I warned in my earlier statements, this method is not ideal — and in all likelihood should be avoided at all costs unless you are in a serious bind.

I cannot guarantee the results of this method as it will vary from deployment to deployment. If you skipped past the first few steps and neglected to contact your target company’s IT administrators to conform to IT policy, you’re in for an inbox loaded with bounce-backs and delivery failures at best — at worst, you’re going to get a call from someone with a lot of very uncomfortable questions.

Again, there ARE repercussions if you avoid your due diligence; however, if you are attempting this method, you’re best off to apply it to low volume deployments. If you want anything larger than say 100 recipients, you’re better off using a service provider who can supply a smoother process, and help you navigate the pitfalls of email deployments.

You’ve been duly warned.

Mr. Armstrong opens with a fairly provocative statement:

You may have noticed that in certain business and marketing circles there exists a “backlash” against the design community. Despite the rise of attractive, user-friendly solutions, in such circles unattractive designs have somehow managed to remain at the verge of acceptance.

There are two things I would like to note about this broad-reaching statement: the backlash is not against the design community, but rather the agencies, vendors, and consultants. More specifically the backlash is a direct response to service-providers who are unable to provide solid end-to-end solutions to answer key business and marketing requirements.

Good or bad aesthetics aside, a business to business (B2B) or business to consumer (B2C) website that provides leads or successfully converts a prospect to a customer is more valuable by the simple fact that it does what it was intended to do: to market or to convert.

No amount of “business speak” by a designer agency/vendor/consultant can compensate for a poorly conceived product.

“Pretty doesn’t mean effective: statistics are your friend!”

Mr. Armstrong makes some good points in the article, the most notable — I believe — is this first guideline.

It is true that statistics are definitely your friend, but you have to be very careful on how you interpret the statistics.

The example given compares two websites from dramatically different industries. The first, 2Advanced Studios, is a design firm while the second, Perry Marshall is an author’s site. You might argue that they have similar business goals in mind, but the reality is that you cannot effectively compare these two businesses and glean true insight into what works and what does not.

Comparative statistics should be taken from competitor websites within the client’s industry or a related industry.

The adage: “What’s good for the goose…” does not apply here.

When refreshing an existing business website, your client will usually have a number of pre-conceived goals in mind.

The most typical goals are:

• Improve sales
• Capture more leads
• Build awareness (brand, industry issues, products & solutions, etc).
• Foster brand trust and build brand equity.

Your client’s business goals should be your Rosetta Stone when interpreting and establishing your baseline metrics for success, and at this point aesthetics are a non-issue. This segues into Mr. Armstrong’s second guideline…

“Every design should have a measurable goal”

I have a particular issue with this statement:

Saying that the goal is to “build the brand of XYZ” or “create an online presence” is basically meaningless to a business-minded person. A goal is only a goal if it is measurable.

I agree that brand building might seem ephemeral and subjective, but there are quantifiable metrics for this — it does have meaning for a client.

A smart business will have clearly defined what constitutes effective brand recognition and build their brand’s equity on these definitions. The brand-building activities and their results are quantifiable (see “build brand awareness, Foster brand trust…”) — “Build the brand of XYZ” is a legitimate business goal.

That aside, “measurable goals” should be a reflection of the business goals, and if you can answer the challenge from a design perspective, and provide insight through incremental testing, etc. you will have built a stronger foundation for the client to determine their success metrics.

“Your site should have one clear path”

Mr. Armstrong suggests that:

As a customer comes to your site, you want to be in complete control of the 1st thing they see, the 2nd, the 3rd, and all the way down until they accomplish your goal that you’ve set. In other words, they have entered your sites “funnel” or “chute”.

In a perfect world we would all build sites that work on this principle. The reality is that entry points into a website vary from user to user, campaign to campaign, and search engine to search engine. The notion of strictly engineering the site to control your users and their behaviour is akin to trying to catch the wind.

On a business site, the most overlooked exercise is to determining what the audience wants from the website and compare it to what the website actually offers. What you should expect is a handful of common use-cases which illustrate the behaviour of the target audience and how they truly interact with the website.

If your client’s website offers only one service or product, then the primary audience will likely follow one common path, and Mr. Armstrong’s proposition can ring true; however, if your client’s website offer’s multiple products and solutions to several key audiences, the most effective thing you can do is develop a user-interaction strategy to help users qualify themselves quickly and funnel them to the right place regardless of their entry-point into the website.

E.g. from a user’s perspective: “I am this type of user, and I am looking for this type of content.”

Whatever strategy you take, the execution should remain simple, effectively changing the principle to : “Your site should drive your traffic effectively”.

“Provide performance metrics”

I would consider this an irresponsible statement:

Finally, if you really want to impress business people, put together a little report of how a design performs. It doesn’t have to be fancy — maybe a little spreadsheet (those business types do love Excel) with some basic metrics you can pull off of Google Analytics like visitors, time on site, most popular funnel path, and even a goal conversion rate.

I definitely agree that providing post-launch metrics are an effective means of helping to justify or support certain design decisions on a website, but this needs to be put into serious perspective: a responsible designer Agency/Vendor/Consultant will look first to ensure that the metrics support the design recommendations as it applies to the business goals.

To be clear: look to the business goals of the website FIRST — design decisions when it comes to websites should be considered with an eye towards better usability to support those business goals.

My biggest point of contention with this last guideline is that metrics are interpretive and can easily be used to disguise a poor architecture or site user-interaction strategy.

The value of certain metrics are largely determined by type of website, which in many cases is a reflection of the fundamental difference between a E-commerce website vs. a Lead Generation website. “Traffic Volume” for one site does not equate to “Lead Capture” on another.

Simply providing a spreadsheet and some screen captures is a easy way to obfuscate or skew the meaningful metrics. Be responsible and avoid polluting your client’s metrics without providing a deeper understand of the ‘why’ behind the numbers.

Conclusion

What the last section of Mr. Armstrong’s article should have proposed is:

Much of the time, “business speak” can (and will likely) hamper true conversations and discussions around meeting business goals. I would suggest that rather than effect pretence, speak plainly.

When you are engaged with a client to develop or refresh their website, it is your responsibility to educate yourself and your client about what constitutes good design as it is applied to their project, and ultimately how the goals are quantified.

This is how an agency/vendor/consultant can add true value for a client.

Understandably, this is a touchy standpoint to take depending on who you talk to. From a design and creative perspective, one could argue that it’s all about the ideas; and from a development perspective, one could argue, equally, that the technology drives the creative.

I don’t see that either argument is truly wrong; rather, it has been my experience that creative ideas that steam ahead without regard for the technology required to execute the idea, have typically run amok. This is a lesson that I’m forced to re-iterate whenever I start on a new project.

The road to project hell

When I’m involved in any sort of discussion around creative for online media, one of my first questions is always, “how is it supposed to work?”

Depending on how that question is answered, three typical scenarios arise:

1. People will hedge around the issue of technology and gloss over it with a dismissive, “let’s address that later — this is creative discussion,” response.
2. The “build it and they will come” syndrome rears its ugly head once again (this is, by far, my personal favourite and one that I’d put money on if the occasion presents itself).
3. Technical members of a team are conveniently uninvited from the next few meetings until the concept is baked, and only once it’s ready to go into development are they brought back into the mix.

Follow any of the above scenarios — unimpeded — to their natural conclusion, and the result is an uncomfortable, awkward discussion with the client about how the concept needs to be revisited.

This is the not-so-fun part where I usually get dragged back into the mix to help sort things out. For some reason — and despite my best efforts — the same issues come up time and again.

(At this point I usually excuse myself for a sanity check.)

Seriously, how many awkward client conversations does it take for folks to realize the pattern? How much more of a projects’ profit margin need to be consumed before the red flags start to go up? What about the impact to public/client perception of the creative company as a whole?

Rock the boat

When it comes to online media, it is naive to foster the notion that separating the creative from the technical is sound practice.

If you find yourself in a scenario such as the ones I mentioned earlier, consider the following:

1. Challenge the assumptions and address the issue head-on. There are solid technical solutions to creative challenges, and just because the problem cannot be solved one way does not immediately discount the possibility of it being solved in some other manner. Engage the creative process with a healthy amount of pragmatism.
2. Web-projects need strategy, planning, and enough time to execute effectively. Very few online experiences/applications are instant hits. The rare ones that are (Twitter, FaceBook, BaseCamp, etc), have strategy and planning behind them, each with enough time to evolve. Do not be afraid to play the devil’s advocate and ask the tough questions.
3. Designing and conceptualizing in a silo is rarely ever effective. External input (partial or impartial) can be the difference between having to call a client and tell them you can’t execute on what you proposed, and taking the kernel of an idea and pushing it in a direction previously not considered. Keep your technical team involved as much as possible — they are the last ones who have to execute the concept.

When asked, this is how I consider being able to “do better work”:

If a creative team can accept the notion that separating the creative from the technical is folly, the possibility of conceptualizing better ideas and solutions (stronger creative) is all the more tangible.

Perhaps I am over-simplifying the issue (clients do play a big role in contributing to the issue as well), and there are many other considerations, but all of that aside, at some point common sense needs to prevail.

The creative industry has seen an incredible upsurge in companies adding “interactive” to their service offering, and along with that we have a number of other vendor companies which bill themselves as agencies with similar services.

If you are a student, you may want to consider that the idea of “working for the best” is more of a matter of determining where you can best hone your craft — in this case, web design or development.

Is there a difference?

Yes. But let’s take a step back for a moment and take a look at the question holistically.

The creative industry is comprised of many players, but you can draw a clean line right down the middle — I can say this because I’ve been on both side of that industry line.

The players fall into two distinct categories: the traditional Advertising Agency, and the Boutique Shops (vendors).

In the past, it was possible to make a distinction based on their portfolios, but given the current state of the creative industry, we need to consider what makes an ad agency versus what makes a boutique shop.

For the most part, ad agencies have a much broader service offering than a boutique shop. A traditional ad agency will typically offer their clients such services as: branding, messaging, conceptualization, and design. These types of agencies bill themselves as a “full service” agency as most of them include additional services like “media buying”. A full service agency also has the added benefit of several organization layers — management specifically designed to handle a large volume of projects.

The service offering of a Boutique Shop is considerably less. In most cases, a Boutique Shop will offer only a fraction of the services which an ad agency supports. The services are typically design, development, broadcast, post-production, etc. Companies like this have chosen to specialize in one field or another and offer their specializations to larger companies who outsource to them. A Boutique Shop does not [always] have the organizational layers to handle volume.

When it comes to Interactive Services such as web design and development — this includes flash, application programming, etc, — ad agencies typically rely on outsource partners to provide that specialization.

At this point I can already see the emails coming in to argue this particular point, but let me say this much: ad agencies can often provide “Interactive Services” through internal web-teams, but most of them do not. This as more to do with their particular focus in the industry (traditional media, print, etc).

Why the distinction?

The distinction has less to do with size than it does with capabilities. More specifically, it’s about the creative.

Advertising agencies want to own the creative on every level. Quality is obviously important, but the execution is not something they want to concern themselves with most times. The capabilities of an advertising agency are quite considerable, but again, this all relies upon their outsourcing relationships — printers, media, etc. An ad agency relies on the specializations of a vendor to help them execute a concept.

Boutique shops typically do not have the capability to execute a fully integrated campaign on a national level let alone a global scale. That is not to say that they can’t leverage serious partnerships to allow them to do that, but even then the campaigns are limited in scope — mostly online with limited if any offline components.

Interactive boutique shops know this. Quite honestly, most of them appear to be quite happy with this distinction. There are certain financial and client-related constraints which boutique shops do not have to worry about simply because they typically will not encounter them. On the flip side, you get the few who attempt to bill themselves as a full service “agency”. Well, nobody is being fooled, least of all the client (if they’re smart).

Don’t get me wrong — a boutique shop can be creative and have great ideas. Sometimes those ideas resonate so strongly that they propagate into a campaign idea or platform, which may or may not turn into a national or global campaign. But you get the idea.

Suffice it to say that what a boutique shop does is execute on components of a campaign. A boutique shop can do this quickly where ad agencies with internal web development teams might take longer — specializations remember?

Which is better?

Neither is better … or worse.

Ad agencies offer tremendous opportunity for creative development, where as a boutique shop might offer better opportunity for technical development. For students, an internship is an opportunity to challenge the way you think and work, and ultimately what you’ve learned. If you are a student, you may want to consider the company which offers you the best experience in terms of professional growth and opportunity, and not necessarily what looks best on a resume.

When it comes to interactive — web design and development — I strongly suggest interning with a creative company which will challenge the skills and theories you’ve learned in school. The work you may encounter as an intern is a direct reflection of the capabilities of a creative company (ad agency or boutique shop), so make the determination based on what you might end up working on, and what you can walk away with.

In my previous article “Getting emo with color” I discussed the benefits of understanding the emotional impact of color.

…think about how certain colors can provoke a response. A combination of responses creates an experience. So when we design with color, what we’re really doing is designing an experience. So before you start mashing pixels together in your next design, ask yourself this one question: “What kind of experience do I want to create?” Source: “Getting emo with color”

When you’re designing your WordPress theme, consider what kind of experience you want your readers to have. This goes back to Part 2 of this series where I suggested asking yourself which type of blogger/writer you considered yourself. Knowing that is part of understanding how to develop an experience for your readers. If your articles are verbose then you may want to consider a color scheme that allows better readability over a longer period of time, or if you are brief, then a more flexible color scheme may be considered.

A emotional user experience

Color influences the User Experience in ways you might not immediately consider, and while color affects people in various ways, there are some generally accepted understandings:

• High-energy colors — colors that fall in the warmer part of the spectrum — tend to make readers feel restless. Certain combinations of colors can make readers feel agitated and that reflects in the amount of time they are willing to spent on a given page.
• Low-energy colors — colors which fall in the cooler part of the spectrum — tend to leave readers feeling passive. Again, this is not necessarily a good thing as you are not engaging the reader (let’s hope your content is engaging).
• Neutral colors — colors which are neither warm nor cool — make for a bland experience.

Here are some examples of color schemes to illustrate color temperature. Keep in mind that not all of these sample pallets translate well for a design, but they are a good foundation to build on.

Warm Colors:

Cool Colors:

Neutral Colors:

Note: All samples were taken from COLOURLovers.

Contrast is key

Take a look through SmashingMagazine.com’s collection of WordPress themes. What you’ll notice is that the color palettes fall equally on both sides of the spectrum (with a bare handful that are monochromatic). But what you may not immediately recognize is that each of them employs contrast to a high degree.

Contrast is a tool that works well to deliver focus add tension in a design. Developing contrast is not always as straightforward as designating a big block of white space (literally) as the content area. In order to develop a good balance between your color scheme and necessary contrast for your readers, you need to figure out a few things:

• On average, how long are your articles? The longer the article, the longer it takes for your readers to consume it. In a case like this, low contrast makes it quite difficult for a reader to maintain their attention and adds undue physiological strain.
• Is there functionality or features in your sidebar that are absolutely integral to the reading experience. I’m not only talking about ad space here, I’m also talking about search features, or a list of recent or related articles, links, etc. If the sidebar features are not integral to the reading experience, you may want to make sure they recede into the background through lower contrast.
• What is relevant in terms of content? Do you want your latest article to stand out from the rest? Consider that readers interested in your blog will be visiting through varying methods(RSS, Organic Search, Track-backs, etc.), which means you may want to ensure they get what they are looking for quickly.

Tools of the trade

In my previous article, “Getting emo with color“, I mentioned a few tools that can help you in developing color schemes. Here is a site that I personally love: COLOURLovers.

The samples generated by the community are great to experiment with and it also helps to see what others are doing as well. But be careful, these are color schemes and do not necessarily reflect a real-world application, just an aesthetic.

Fortunately, there are tools out there that can help you in terms of gauging contrast. Take a look at Jon Snook’s “Colour (color) contrast check” article. Jon provides a nifty little utility for evaluating the contrast of your color selections. The example page lists two other utilities which you can play around with as well. 456Bereastreet.com complied a list of additional utilities which are both desktop and web applications.

I can’t tell you which color schemes work best — that is for you to decide; however, I can tell you that regardless of the color scheme you end up with, it is wise to ensure that you provide contrast in the right places for the right reason. Understand your goals and design accordingly.

For this installment, I’m going to focus on another issue that tends to plague web designers — typography.

Before we get started, it’s best that we get a few misconceptions out of the way:

1. Typographic principles for Print Design cannot be applied to Web Design;
2. Good typography requires images;
3. Users only care about content;

For the most part, point three is correct; however, let’s put this into a little more context. Users care about your content — or at least you hope they do if they’re browsing your site — but that does not preclude you from developing a better reading experience for them by applying some straight-forward approaches to typography. I personally hate going to a site only to find that fonts are so tiny on my screen that I have to crank up my font settings in my browser to read it. It is equally annoying if I really want to read the content and am forced to resort to that. It doesn’t hurt to make things a little easier for your readers.

As for the second point, my response to that is typically “know your audience”. I say that because every site is different. Content on one site might require that images be used in place of text, whereas on another site, it is far more important to the audience that content be easily accessible (select, copy, paste, etc). Arguably, it is easier to share text-based content, than it is to share graphical content. Understand who your audience is, and cater to them as appropriate.

Finally, most typographic principles used in print translate beautifully to screen. We have far more advanced tools to develop a better reading experience with CSS-based layouts, which control everything from positioning to formatting. While I don’t want this to turn into an in-depth discussion about usability and web standards, I will say that applying good typographic practices enhances both web usability and accessibility efforts.

Let’s get started.

Issue: Poor reading experience for users

For too long typographic style and its accompanying attention to detail have been overlooked by website designers, particularly in body copy. In years gone by this could have been put down to the technology, but now the web has caught up. The advent of much improved browsers, text rendering and high resolution screens, combine to negate technology as an excuse. Source: webtypography.net

I could not have said it any better.

When it comes to developing a good reading experience for your users, typography is an important aspect that needs as much consideration as colour and layout. A good reading experience should leave your users free to do one thing: read. If you can present your content in a way that makes it both easy to read, and requires less from the user than scrolling, you’ve accomplished what many websites fail to do.

Good typography in your design opens up your layout and makes a normally “grey” page appear friendly and light.

Something to think about:

It is inevitable that you will come across older sites — and even new websites — which still seek to compact as much copywriting into a given area as possible. It is not uncommon to hear feedback along the lines of “keep the content above the fold”; every time someone must say this, a kitten dies somewhere. I counter that kind of feedback with this. With current web standards, there is no harm in scrolling a page. It is a natural browsing behaviour; again, this is a good case where it pays to know your audience.

Density or “Typographic Colour”

First off, you need to ask yourself what kind of blogger you are. Are you the type of blogger that publishes short paragraphs with a smattering of links? Are you the type of blogger that prefers to drop lots of images and media with brief explanations? Or are you a copious writer given to generous use of copy, media and links?

If you can identify what kind of writer you are, then you’re half way to understanding your audience. People visit your blog for any number of reasons, but the foremost amongst those reasons is your content. They like what you have to say, what you have to show them, and the information you can point them to.

For the purposes of this article, let’s assume you’re like me — a copious writer. You love your words and your blog is the perfect place to share them.

Given the assumption, here are a few considerations:

1. Large amounts of copy on a screen or piece of paper turn your normal white space in a big grey mass. In traditional typography we call this “typographic colour”. More specifically this is the density of your paragraphs in relation to the space you have given the paragraphs. You can lighten things up by adjusting the “leading” (line-height in CSS), and the “Kerning” (letter-spacing in CSS).
2. Colour as a tool plays a much more important (though subtle) role in good typographic design. You have many colours to choose from, but when it comes to presenting content that is intended to be read, contrast between the background and the type is essential. The better the contrast, the less work is required of the reader to focus and interpret what is on screen. Pick colours that are harmonious with your overall design, but also have a high-degree of contrast. This does not mean you have to stick to black and white; as long as the colour has enough contrast to it, you should be fine. “Cooler” colours (colour temperature, not “cool factor”) for type work best across most screens.
3. The typeface, its size, its leading and kerning all affect the readability of your content. Choose a typeface and set its properties to ensure that it is legible. I cannot stress this aspect enough. I have had one too many debates with designers who transition from Print to Web, arguing that 9pt to 10pt type is more than sufficient for on-screen legibility (this is one of those exceptions where print and web typographic principles do not marry so well). I end these long-winded debates with this consideration: in contemporary graphic design, a designer must design for the medium. The same holds true for web designers. We have to design for the medium, and in our case the medium is the screen. Here is an article that also talks about adjusting typography for the web. It also covers parts of the previous discussion in relation to the column measure.

Here are some examples of density, and how typographic control can affect the legibility of your body copy:

You can see from the thumbnails how the leading affects the density of copy on the page. The tighter the leading (and other type properties) the more dense a single paragraph appears to a reader.

Putting it into practice

Spend the time and go through the motions of playing around with typographic colour in your design application, or if you prefer to deal with your typography in CSS you can use tools like Font Tester or TypeTester. The benefit of these online tools is that you are very quickly able to see the results of your tests as they appear on screen — in a browsing environment. The more time you spend on determining your typographic styles in the design phase of creating a WordPress theme, the better off you will be later in the development process.

Design for the medium

Keep in mind that for web, it is easier to scale back than it is to scale up. We don’t have the restrictions of paper or other physical media — we do have to contend with other issues (we’ll cover that later), but for the most part you’re better off starting larger at first and scaling back if you have to.

Here are some sites that are some examples of web typography that illustrate the design principles I have been talking about in this article:

• http://www.clearleft.com/about/
• http://www.simplebits.com/
• http://www.whatdoiknow.org/
• http://slideshowpro.net/

Some Considerations:

Feedback is always nice to have. If possible, solicit some of your readers about their thoughts on your typographic choices, but remember to put your questions into the proper context:

• “Is it easier to read my articles if I do this or that?”
• “Does the page feel lighter to you if I chose this colour or that colour?”
• “Can you scan the page quickly and find what you need?”

Further Reading:

“The Elements of Typographic Style Applied to the Web” is a site that I have found infinitely useful as a reference and as a sounding board for decisions I make in terms of my typographic design. I encourage anyone who has an interest in web typography to read it — it’s not a long read — quite brief in fact. Keep in mind that as a designer, you the final call on decisions — don’t get caught up in the stress of “I have to adhere strictly to the rules or my design sucks”. Instead, think about your audience. Put yourself in their shoes and consider what works best for them in regards to your content.

The reality is that most older WordPress themes (older than v2.x) can be upgraded to be compatible with newer versions of the WordPress software, but it does take a little effort to figure out what works and what doesn’t — sometimes creating a new theme is far more attractive than having to parse through old code. I hate having to revisit old code — yes, I am one of those people — but since I’m developing a theme that I want to share with people, I want to ensure they get the best out of what I can develop. In order to do that I needed to make sure my WordPress themes are as future proof and flexible as I can make them.

For the first part in this series, I’m going to focus on the "K.I.S.S" principle.

Now, I know there are articles galore which expound on this principle, but when it comes to WordPress or most weblog systems, designers tend to throw it right out the window. Complexity does not always equate to good visual design.

To kick off this series, I’m going to focus on a fundamental design problem, which ultimately compounds other issues later on in the development process.

Issue: Inconsistent "Column Measure" and the visual "Grid":

This is a design issue which plagues the majority of designers. Column measures form the foundation for your design "grid". The implied "grid" lends harmony to your layout and an invisible structure — a framework — you can use to communicate visual priorities of content and components on a page. There is no hard and fast rule that says you should always use one, two, three or four column layouts. It really comes down to what you need to illustrate the content and functionality on your pages without pushing it to the point of clutter.

Understanding the column measure

In short, a column measure refers to the width of "continuous text". This is most evident in magazine and newspapers where the ability to flow text into multiple columns is possible. With current development standards and web-technology this is not such an easy thing to do (it’s possible with a lot of hacking). However this does not preclude you as a designer from developing a rough column measure to aid in your layout.

Note: What is also handy (and we’ll talk about this in later articles), is the typographic settings derived from this measure. Here is a good article explaining "column measure".

Designing your "Column Measure"

The old carpenter’s adage "Measure twice. Cut once" holds true for design on so many different levels. In the case of WordPress theme design — determine your column measures first.

When you first run Photoshop (or whichever program you prefer), fight the urge to start throwing pixels onto your canvas. Instead, focus on setting out your guides. Here is a sample of the column guides I typically start with all my web-layouts:

The darker grey areas indicate where content would flow and the lighter grey areas indicate margins or padding you may wish to apply. I stick to a 20px padding practice (10px on the left and right side). The space remaining provides your gutters. The pink rules between columns indicate possible borders.

In terms of designing the column measure, I tend vary my widths anywhere between 250px to 300px — this typically lends a fair amount of space for design elements and copy, as well as enough room for extra white-space where possible.

A few things you may notice about the column sample:

• Between all three columns, I allot for a 1px border (the pink rules). I do this because it is a pain to have to factor in borders in the design after you’ve committed to your column widths. This may seem odd at first because the combined column widths end up being 601px and 902px respectively — naturally these aren’t numbers you expect to see, but these numbers end up giving you better control when you want to divide the columns.
• The columns loosely follow the CSS box model. This is vitally important if you’re designing for web standards. Being able to foresee ahead of time, how the box model affects a layout is a handy tool, not to mention that it takes the guess-work out determining margins and padding for your divs. The remaining space after any margins or padding is 280px — that’s a pretty decent amount of space to put towards content or blocks of functionality like categories, bookmarks, search boxes, etc.
• I allot a minimum of 10px outside of the layout for effects like drop shadows and such. My "Lemon Twist" theme is a good example of where that extra little space comes in handy.

Your columns are just vertical spaces which you can use to flow your content into. You can bridge or merge those columns, thereby creating interesting design elements; however, don’t let the columns restrict you — the grid that is derived from this is a very helpful tool which allows you to create designs such as what you might see with the following sites:

• http://www.ndesign-studio.com/
• http://www.snook.ca/jonathan/
• http://archgfx.net/blog/2007/geek/blogging/bus-full-of-hippies-for-wordpress (see screenshot)
• http://www.lifespy.com/2007/illacrimo-theme-release/ (see screenshot)

Putting it into practice:

Once you have your columns roughed out, start playing with blocks rather than fully fleshed out designs. With building blocks you alleviate the complications of the aesthetic, giving you much better focus on of proportion, balance, flow and tension.

Bridge your columns — which design elements might benefit from doing this? What happens when you swap the position of your sidebar and your reading area. If advertising is a feature of your weblog, where is it most effective to generate clicks and views? Does your navigation work best in a sidebar or at the top?

Play around with the layouts. When you get to a point where you’ve blocked out your layout, them dive into design.

Things to consider:

Remember, the primary purpose of a weblog is for people to read — I know there are some folks out there who may feel otherwise; however, the majority of people visiting your weblog are there to find content, read it, and move on (or share it, but I’ll save that for later). Whatever you can do in your design to accommodate that most basic of requirements, the better.

Here are some questions that may help you:

1. Think about how many columns you really need to layout your content — can you simplify?
2. What are you columns being used for — articles, advertising, photos, etc.?
3. Are there going to be exceptions to the layout that might affect your column structure, such as banners, forms, long headlines, embedded media, etc.?
4. As a reader, do you prefer to have a wide reading column, or a narrow one?

Try to answer as many of those questions before hand and avoid some of the design pitfalls later.

Ultimately the content and the functionality are up to you. By keeping most of these things in mind you will make it far easier to maintain the integrity of your design as well as work to make it future-proof.

Further Reading:

• http://www.wpdesigner.com/2007/06/19/web-typography-column-widths/
• http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/