Should e-mail designers/developers ignore standards because of poor rendering in e-mail clients?

Paper for the W3C HTML Mail Workshop, 24 May 2007, Paris, France

Author

Darren Rawlings, Head of Strategic Service (Europe)

Biography: Darren Rawlings is the European Head of Strategic Services at Premiere Global Services, where he has spent the last 5.5 years helping clients achieve their e-mail marketing goals. Darren and his team are currently championing data-centric marketing and transactional marketing as they believe these are two of the most powerful tools in an e-mail marketer’s armoury.

Paper

It has often been suggested by clients that e-mail design should follow the same rules and principles as web design, as such, demands place on individuals and organizations designing and developing e-mails often mirror that of web design and development. Clients would like to see e-mails that:

It is not unreasonable for clients to expect web functionality in e-mail, after all they are both underpinned by the same technologies:

E-mail clients, however, are simply not as capable as the web browsers they rely upon. There are also more e-mail clients in mainstream use than web browsers, todays e-mails designers have to accommodate:

… and most of these are also affected by the browser version the recipient chooses to use.

For various reasons, some of which we can make educated guesses about, these browsers offer differing levels of support for CSS and even some of the basic elements and attributes of HTML. This level of support varies from the excellent support of Thunderbird, to the poorer levels of Lotus Notes, Outlook 2007 and Gmail.

We now stand at a point where e-mail designers/developers face a tough decision: to accept the status quo and live with e-mails of a more limited functionality and of poor design or push for new standards based design. The situation reminds me of a time, not so long ago, where browser hacks and browser specific functionality were the norms in web development. Web developers faced a choice, to capitulate and except these hacks as a standard way of working or push for a new purer standards compliant form of web design, a design that would force the browsers developers to adopt standards.

The choice as to whether we accept and adapt to the limitations of e-mail clients or choose to adopt a similar level of standards to web development is the choice we as e-mail designers have to make.

My personal opinion is that we have to push for the adoption of similar standards to normal web design.

Unfortunately we are seldom in a position where our designs can match our ideals. I am conscious that most of my clients would argue that their design should use the hacks and necessary deprecated elements and attributes to make the message render well in as many e-mail clients as possible. Whilst we endeavor to educate clients on web standards, and use standards compliant code wherever we can, we are of course obliged to follow our clients’ wishes. So this brings about the main counter argument to the adoption of web standards:

“It stands to reason that a message that renders well in most e-mail clients, will more successful than one that doesn’t”

For most of my clients it comes down to an assumption regarding ROI, if a call to action in an e-mail loses its emphasis or is misplaced because of a quirk in an e-mail client, it is less likely to be clicked and generate its desired result.

Similar arguments were made for relying on quirks is web design, but reliance on quirks led to inconsistencies and the dreaded phrase:

“This web site was designed to work in Internet Explorer…”

This cycle was broken by greater standards compliance in web browsers, and we now benefit from more interactive and engaging websites. People refer to the web as a platform running online applications, often using the term Web 2.0, the ability to treat the web as a platform capable of being accessed through a browser relied on standards compliance. We as e-mail designers/developers can only encourage change, it is the responsibility of the developers of e-mail clients to make the changes necessary to their applications. Until we have greater standards compliance e-mail will never progress.