What CMS Do You Use?

It might be one of the oldest questions on the web (surely the topic of some long-running flame wars), but I’m curious, so I’m asking: What Content Management System do you use?

Some backstory: I’ve recently begun working at a New York-based web design and Internet marketing firm as their all-around design/development guy, and a big part of what I’m bringing to the company is expertise outside of Flash-based development (which is really common in the industry for which my company does work), and some really old-school Dreamweaver-generated table-based designs.

I’m there to push CSS, standards-based stuff, flexibility, and implement solutions that push the industry forward in terms of accessibility, usability, and efficiency. It’s an uphill climb, to be sure (can you climb downwardly?), but one that is fulfilling, and for which noticeable progress is already being made. In a way, I’m as much a consultant as a site-builder, and that suits me just fine.

Now, one thing I’ve been trying to figure out is how best to approach issues of content management for our clients, particularly new ones.

The way I see it, there are several different possibilities:

1. Having the client (or content manager) purchase and use commercial CMS software like Adobe Contribute or Dreamweaver.
   
2. Purchasing and installing a web-based CMS (something PHP-y, ideally, since I’m capable with that).
3. Using Wordpress, Drupal, or similar open-source Content Management Systems.
4. Building a custom CMS from the ground up.
5. Implementing services like the new CushyCMS, which is a totally hosted content management service that now offers a premium version for designers that allows you to create a branded CMS and bill clients monthly, if desired.
6. Award all clients a complimentary copy of HTML For Dummies upon completion of their site and change the office phone numbers.

A few of my thoughts on the above possibilities, and then I’d love love love your input and suggestions:

• I’m inclined to hate Dreamweaver and Contribute (I think they violate my religion, perhaps). And I think there’s a great deal to be said about the ability to update one’s site from anywhere with an internet connection - without having to install expensive software.
• Non-free web-based CMSes: I know they exist, but I don’t know which ones are good. Why use these rather than their free counterparts?
• I’ve used Wordpress in the (recent) past for client sites, and I like it enough, but it doesn’t seem meant to handle “real websites.” I don’t mean this as an attack on its particular technical merits (though the Digg crowd surely does), but merely as a comment on what I gather to be its “software worldview,” if I may coin a phrase with only 283 results in Google.
• I have yet to use Drupal, though I’ve been researching it, and it seems viable.
• We don’t have the capabilities in-house to develop custom Content Management Systems aside from very exceptional cases for which we can have a pretty cool Rails developer to put something together for us, so that’s pretty much out, and beyond the financial abilities of most of our clients, besides.
• And CushyCMS intrigues me, and seems really great for smaller clients, but the idea of relying on third-party hosting scares me a little. How do you tell your clients, “There’s nothing we can do about it?”

Ultimately, I’m curious to hear what you use, what makes it awesome (or makes it suck), and what you know about the different options out there for folks looking to build some seriously cool sites, and spread some seriously decent standards-compliance at the same time.

Let me know in the comments!

The 2008 Gmail Appeal

Email Standards Project - Gmail Grimaces from Mathew Patterson on Vimeo.

More on the Email Standards Project (from me).

Email And The Fight For Standards

As a young web designer who cares about standards and accessibility, but also about paying the rent and having enough left over to buy some slick gadgets, I often find myself stuck between the proverbial rock and a hard place when it comes to designing HTML emails for a client.

You see, on one hand there’s a strong part of me saying, “No! Don’t do it! It’s not worth it to revert to web practices straight out of 1999. Tables are bad! Inline styling is bad! People hate HTML email! Your code is ugly! Fish are friends, not food!”

But then the devil on my right shoulder (wearing a blue dress, not a blue beanie) speaks up to say, “Dude, you need money if you want that [insert latest Apple product here]. Clients will not settle for text-only emails, or at least they won’t pay you for them. And besides, studies show that HTML emails are actually much more cost-effective for businesses. Suck it up a code a table, you sissy. Everybody used to do it, why do you think you’re exempt?”

To some of you, this whole discussion might seem to be flying 50,000 feet up, but here I’ll try to summarize:

In web design, it is now widely accepted that using Tables (grids of rows and columns, just like one you’d create in MS Word) for the structure of a website is a bad practice because it doesn’t allow for the separation of content (the text and pictures and videos) from presentation, and requires a ton of maintenance, among (many) other things. CSS (Cascading Style Sheets) emerged years ago as the solution to this problem, allowing designers to change the look of an entire site simply by editing a couple lines in a single external file (instead of every line on every page), and after a lot of activism in those early days, is now widely accepted as the proper way to code a site. Standards-compliant pages tend to load faster, have shorter development times, and are readable by every device now and in the future that has support for these standards.

The trouble is, most email clients don’t have this support, and some (like Outlook 2007) have even less support than their predecessors. Worse still, every single email client has vastly different support for various CSS/HTML elements, and will render your code in disgustingly problematic ways. So, by and large, many web design companies have abandoned email design, or if not, done it begrudgingly, ashamedly.

I’ve done my share, and it’s not glamorous work. Looking at what I’ve just written sometimes makes me want to cry (in pretty much the same manner that coding all-Flash sites does, but that’s a post for another day).

Finally, some of the big guns in web design and standards-advocacy are taking a stand and beginning to fight for standards support in all the major email clients, rather than ignoring the practicalities and pretending that HTML emails don’t or shouldn’t exist. That kind of denial sounds nice in theory, but in practice it’s totally flawed. Today, the default in nearly every email program is to send an HTML-formatted email. Any time you change the colors, or the fonts, or add some underlining or embed a picture - that’s HTML. So, if it has to exist anyway, shouldn’t it be done right?

These reasons (and others) are why the announcement of the Email Standards Project is such a big deal, and why I can hardly wait for the day when I’ll have coded my final bit of inline styling.

If you’re in the business, please join me in supporting this initiative. Here’s how you can help.