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

Strategic use of texture can help to shape the perception of a design; it can turn a simple website layout into something evocative; when delivered in context with the subject matter of the site (articles, information, etc), texture can help to communicate tone and attitude.

Texture In Web Design

Visual textures can be lumped into three relative categories:

1. Patterns
2. Photographic
3. Illustrated

Patterns as Texture

Patterns are the most common type of texture that you encounter on the web. In many cases they are tileable images that are rendered as background images in a page, or appear as textured design accents. Patterns can range from illustrated elements that can repeat endlessly, or as three dimensional (often photographic) textures that can evoke a sense of depth and dimension.

Example:

Fig. 1 – Tileable Patterns.

Resources:

• K10K Pixel Patterns
• SquidFingers Patterns
• BgPatterns

Photographs as Texture

It would be more appropriate to consider photographic texture as singular instances of texture applied to the design, rather than something that is explicitly tiled as in the case of patterns. Photographic textures tend to range in subject matter, but the most common example of photographic texture are images that can be used as backgrounds, such as walls (brick, cement, etc).

Example:

Fig. 2-4 – Light, textiles and other industrial textures.

Resources:

• ImageAfter
• iStockPhoto

Illustration as Texture

Illustrated texture is something of a trend over the past few years, where artists and designers mix various sources such as photographs, tileable patterns, and light to create unique textures.

Examples:

Fig. 5-7 – Mixed water color backgrounds.

Resources:

• iStockPhoto
• Brusheezy

Texture in WordPress Themes

Texture as a design element contributes to the overall personality of the design. When it comes to WordPress Themes, authors tend to exhibit a need to communicate an aspect of their personality through the theme they choose to employ on their blog.

If you’re thinking about using texture as part of your design, consider the following:

1. Theme: What is the theme of your theme?
2. Prominence: How prominent are the textures going to be in your design?
3. Repetition: How often and how many repeatable textures are you planning to use in the design?

Bringing it Together

Designing a successful WordPress theme is no different from designing a compelling website layout – both need to illustrate an artistic (and practical) balance of many design concept where texture may be one fundamental aspect of that balance.

When you’re considering the design of your WordPress theme, think about how your chosen texture(s) will work together with your other design elements to communicate the overall theme.

For example, if you’re out to create a theme that needs to communicate and “outdoors lifestyle” or “nature”, you may want to consider using textures that are organic. In a case like this could could mix various types of textures (tileable, photographic and illustrated).

Fig. 8 – Outdoor Italia

The Outdoor Italia site is a great example of how various types of tileable and photographic texture can be used in a design to communicate a theme. The site makes great use of photographic textures in the form of leaves, paper, and the occasional physical item to deliver a sense of depth.

Fig. 9 – Wild About Gardening

The Wild About Gardening is one of my favourite sites for two reasons: the illustration work makes subtle use of — and reference to — watercolor art, and it blends well with photographic texture. This site is a great example of Photographic and Illustrated texture working naturally together to communicate a sense of unity in the design.

The above examples aren’t WordPress themes, but the leap from content to editorial layout isn’t difficult to make.

Remember that not every WordPress design you create has to have shiny buttons and glossy blocks. Take time to experiment with texture in your design, and discover how different textures can dramatically change the tone and style of your design.

While I’m an ardent supporter of promoting the WordPress platform any way I can, the contest documentation sent up red flags after the first and second read through:

1. The rules for entry had been modified once (noted by the site owners) ;
2. The foundation of the contest is rooted in the participant submitting a “concept” but later defines a concept as being a production comp.
3. There’s a fairly ambiguous panel of judges as implied by, “Designs are assessed by a special team from ColorLabs Project…”  — who are these people?
4. Lastly, this: “You understand that by participating in this contest, your theme concept is possibly used by ColorLabs Project and may be made available for purchase on our site. Winners will be awarded a cash prize for their work. Any other theme concept will only be made available for purchase after a once-off fee agreed by both parties. Sales generated off the theme will be kept by the company.”

Get Your Story Straight:

First off, if you’re going to launch a contest, make damn sure that the language surrounding the rules and regulations, as well as the terms and conditions are as clear as you can possibly be. I say this as a a Creative Director and planner who has been involved in advertising campaigns that were build around some hefty prizes. Nothing makes a contest go south faster than poorly written contest literature. Once you post those rules, you had better ensure they are final. I can’t speak for the legal ramifications of changing contest details mid-way through, but I can say there’s a significat level of trust that is lost in having to do so.

Concept vs. Concept Art

Second, a Concept is quite different from Concept Art. Be sure what you’re asking participants for. A Concept, e.g. an idea — is typically something you solicit in written form. Concept Art is visual. In a design contest like this (and considering the last condition in the T&C), asking for a visual concept without providing appropriate conditions to protect the artist’s work is borderline unethical. There is nothing to prevent the contest hosts from turning around and re-creating the concept art into production-ready source files. Participants should be well aware of this possibility.

Industry Peers/Professionals or Your Grandmother?

Third, who the heck are the judges? While there is nothing wrong with not disclosing the judging panel to the general public — to me, there’s a level of trust that a contest host can provide through disclosure. Quite frankly, are the members of the judging panel qualified to act as judges given the criteria? This is pretty grey-area from my experience.

Exactly How Are You Planning To Use My Work?

Lastly, the final condition on the T&C is loosely worded, and relinquishes — as I understand it — a considerable amount of the artist’s rights to the contest host. While on the surface, there is nothing essentially wrong with this practice, but it leaves me questioning the ethics of amassing a royalties-free library of design for resale. On one hand, it may be quite alright to capitalize on the award-winning themes as well as the runners-up, but what of the rest? Are the remaining “unqualified” designs to be saved for later resale or are they to be destroyed? What about compensation for artist? The language surrounding this particular conditions is a little vague.

In any case, I’m not a lawyer — just someone who really wanted to participate in a contest, but unfortunately this one comes off as a scam poorly disguised as a contest. What’s next: timeshares in the Bahamas?

Seriously though, if you are considering participation in any contest of this kind — take the time to educate yourself on your rights as an artist/designer and pay particular attention to the organizers of the contest. At the end of the day you’ll need to judge for yourself whether or not a contest is legitimate and what your work is worth.

Biola Undergrad

I liked this site for its particular blend of graphical styles (hand-drawn illustration, vector and photography). The design successfully delivers on style while still respecting the need to remain usable.

Visit them here.

Redbrick Health

This is a fairly dramatic departure for a health insurance provider in that they’ve done away with the typical corporate look and feel in favour of a more consumer-oriented aesthetic. Browse though the various sections and you’ll see that the designer carried the theme consistently throughout the experience. one feature you might want to check out is the parallax scrolling effect you get when you resize the browser window (pay close attention to the clouds).

Visit them here.

Edit Studios

A UK based web company, Edit Studios’ website offers some interesting features that caught my attention. I particularly liked the rotating portfolio that breaks up the standard grid, as well as the playful hand-drawn details peppered sparingly though the design. While this isn’t the most ground breaking of sites, I do like it for the fact that I get almost everything I need to know about the company right from the get go.

Visit them here.

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.

Too Much of a Good Thing

“Copy Overkill” is essentially the tendency to overload a single page with too much copy — too much information, and in some cases too much of the wrong type of information. In the landing page project I described, one of the elements required as part of the A|B testing was a series of marketing messages and follow-up content that were to be finely tuned for specific verticals.

The writer was given a set of wireframes with a series of “blocks” in which copy was to appear. What the web-designer received was a content deck overflowing with copy and precious little screen real estate to contain it all (including all other design elements).

Now, the typical first reaction of a writer who is unfamiliar with how copy works online is to say, “Well that’s your job as a designer — you go make it work”. The second is to vehemently argue the validity and importance of keeping every word that was written in the content deck.

You can likely imagine the reaction and the ensuing conflict between teams. This can quickly turn into a project manager’s headache.

How Much is Too Much?

It seems that nearly every project I have been involved with suffers from this tendency. I’m hoping that one day I’ll luck out and not have to deal with this again (one can dream); in the mean time, it is difficult for a designer to argue with a writer about how much is too much or the validity of their words on screen. To make things easier for both sides, here are some ABCs that can help to determine the copy density for a given page:

Audience

Who is the target audience?

This is a fundamental question that needs to be answered before a single line of copy is committed — a good communication brief (sometimes known as the “strategic brief”) should answer this, as it is likely one of the key bits of information that was gathered at the outset of the project.

Without getting into too much detail about demographics and psychographics, etc. there is a significant difference between how much information one group prefers in contrast to the other. Understanding the target audience is key in determining the amount and type of information they prefer when reading a page.

Remember, we’re writing for the web, not a novel — and since we’re on the topic writing for the web, remember to that each word is worth pennies.

I know of one writer who would throttle me for seemingly diminishing the value of his fine words; however, the fact is that every word that appears in strategic areas of a page is worth something, especially if the site is part of a campaign leveraging SEM (search engine marketing) as a traffic driver. Consider too that the right verb can spur a user to action and direct them into the process of converting from a prospect to a customer (aka “conversion”).

Balance

What is the best balance between Design and Copy?

Typography is a discipline in design that copywriters tend not to observe — for most, it’s not a part of their job function; however, it is something that writers who are developing copy for a web-audience should attempt to appreciate, since good typography can help form a strong visual path to the desired action.

Web Typography is not necessarily the same as Print Typography — the principles are similar, but the application is where there are glaring differences. Writers should also consider the other elements and features that make up a given page (branding, navigation, visuals, etc). These elements when combined, dramatically reduce the amount of space in which to work.

The issue of real estate is compounded by the fact that unlike print, the visible real estate on screen can vary wildly, and so a web-designer has to look at a page in terms of segments:

1. 33% for initial messaging and brand exposure.
2. 33% for context and call to action.
3. 33% for the granular details.

The closest comparison would be that of daily news publications — there is only so much only so much space to identify the publication itself; only so much of the font page that can be devoted to the headline and visual; and only so much column space to deliver the story. On a newsstand this defines which paper a reader will choose.

I tend to invoke one rule that I carry over from my days in designing for editorial: “Write to fit”.

This rule shouldn’t be invoked frivolously. Editors invoke this as a measure of last resort when there is quite simply not enough room for all the words to work effectively. When it comes to the web, screen real estate is at a premium.

Be prepared: This will sound cliché, but as a designer you need to show the writer why his copy is not working rather than tell him it is not working. The proof is almost always on screen, and no — 7px type is not an acceptable solution.

Be sensitive: As with design, coming up with compelling copy is not an easy task — appreciate that a writer spends as much time agonizing over verbs as a designer spends over grids.

Context

Why is the user viewing your page, and how did they get there?

I’d like to think that every website is unique in some small way but the reality is often the opposite. The sheer volume of websites online today is staggering. Within a particular industry you might find thousands of similar sites, and within those sites a myriad of identical pages with each one saying the same thing as their competitor.

However your visitor (aka “prospect”) finds you, you need to understand the context around their visit.

If the particular page is part of a targeted campaign with an SEM strategy, you can expect that they’ve found your page through results or other traffic drivers purchased for that reason. This is a pre-defined path with an expected purpose and resulting set of actions (abandon or convert).

If a visitor comes to your site cold (e.g. no identifiable referral or metric), you can assume they are searching for “something”. You need to help the visitor determine what that “something” is — and quickly.

This is where copywriting comes into play. The behaviour for most users (especially if they’ve only stumbled onto your page), is to start scanning for key words and phrases that might help them orient themselves. I’m treading pretty close to talking about SEO here, but it’s unavoidable given the current topic.

Some key considerations:

1. Your positioning statement or value proposition should answer their need — they came searching for something, so your content needs to address their query with an appropriate response.
2. Lighten up — dense blocks of copy are intimidating and visitors shy away from these in favour of bite-sized phrases and sentences. In web as with print, readers tend to “see” blocks of grey rather than areas with “lots of copy”.
3. Draw clear relationships between copy on page — clear communication builds trust, and showing strong relationships between blocks of information tells a user that your content is well thought out and authoritative. You’re not attempting to over-sell the subject of the page.

There are at least half a dozen other factors that will help to determine if you resonate with the unknown visitor or not, but having the right amount of copy will help to make that task easier.

Conclusion

Finding the right balance between copy and design for a website is never going to be easy, and there will be  struggles between both, but it doesn’t have to always have to be this way. Consider how you can work with your writing to team to create an effective balance, and when push comes to shove, remember who it is you are writing for.

Here are some additional articles that I’ve found useful:

The Elements of Style for Designers by Christina Wodtke

Writing Content that Works for a Living by Erin Kissane

Reviving Anorexic Web Writing

It’s also about the same time each year that I start to feel a little burned out.

One of the things I like to do at the end of every year to keep a little spark of inspiration alive so this burn out doesn’t carry over into the next year is revisit my bookmarks. I collect a lot of sites, and half the time I never recall that I’ve come across it (or revisited it). Some of what I’ve collected no longer appeals to me, but there are a few gems in there that make me glad I hoard bookmarks.

Here are a few:

ConceptArtWorld.com

ConceptArtWorld is a collection of the industry’s leading concept artists from around the world. The site is a great example of of WordPress’ publishing capabilities can be extended to create sites such as this. The overall design is understated to give prominence to the high-quality work of their featured artists.

Visit it here.

Designsensory.com

From their profile page: “The Designsensory team comprises well-rounded, imaginative and meticulous individuals practicing across a wide range of disciplines…”. This is the blog of an agency located in Knoxville, Tennessee. The rest of their site follows the same aesthetic; however, what attracted me to their blog in particular was just the sheer, unadorned simplicity of it all. The reliance on blocks of solid color, coupled with great use of white-space really makes this layout attractive for me.

Visit them here.

Viewzi.com

From their homepage: “Viewzi is a whole new way to experience search. Instead of one big list, you get nice visual Views tailored for the content you are looking for…”. Innovation is always fun to watch (and be a part of if you’re lucky). What I like about this site is that it immediately convey’s their message, “It’s all about the views!” — while not really wanting to jump on the Web 2.0 bandwagon, this site has some wonderful layouts such as their blog and about page.

Visit them here.

That’s it for now. I’m working on a nice little Christmas present for visitors this year — keep checking back.

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.

At the time Stephanie Meyer had just released the third book in her debut series, the “Twilight Saga”, and I had admired the book covers while browsing through my local Chapters bookstore.

There are so many books that hit the shelves these days that covers just start to blend together into one big mottled wallpaper. So it was a mild surprise when I encountered the stark black and minimalist cover designs.

The Twilight Theme

Inspired by this, I decided to design and develop a WordPress Theme based on the book covers.

Variations

I thought I would have been satisfied with using only one of the book covers as inspiration, but the more I worked on it, the more I felt that I couldn’t settle with just one. On top of that, I think anyone who would have been interested in using the theme would likely have a favourite cover graphic other than the one I preferred most.

Here are some variations of the same WordPress theme. It didn’t take much (CSS is awesome), and I even went as far as to allow customization with quick modification of one of the theme files.

Now WordPress authors can use either one of these themes. There’s a fourth book that is coming out: “Breaking Dawn” which I will try to add to this series at a later date.

Download

Okay, so I’ve rambled on enough, Download the WordPress – Twilight Theme v2.0.1.

Notes

BIG FYI: It looks like the comment’s code is missing from this build. I will work on getting that re-implemented tonight. My applogies for the inconvenience!

If you want to modify the graphic to achive either of the variations above, all you have to do is find the file “settings.php” in the Twilight theme folder (includes/settings.php), and edit the following snippet at the very beginning of the file:

// use either "twilight" or "eclipse" or "newmoon" to customize which graphic to show
$THEME_GRAPHIC = 'eclipse';

This theme is built on the same basic framework as my current Lemon Twist Theme. As such, you will likely want to install a few WordPress plugins that work with this theme, so take a look through this README file.

If you are running into errors when applying the theme, it is likely that a plugin is missing and is causing the problem. If you encounter this, check out the “includes” directory and modify any of the offending includes in the “sidebar” sub directory.

Still at a loss? Contact me.

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.