Top 10 E-Newsletter Checklist

Written by Lee Micai on September 20, 2011 – 11:13 am -

1. Make sure all your links are correct.

Test all of your links to make sure they go to the correct address and the pages still exist.

2. Make sure you send a plain text version.

Don’t ignore your subscribers on mobile, Facebook or those who prefer text messages.

3. Make sure all your pictures have an alternate text tag.

An alternate tag or ALT tag is a text description for images in your emails. It is used when the image is not available to the reader because they may have turned off images, or are using a screen reader due to a visual impairment.

4. Make sure all your links have a TITLE text tag.

A TITLE tag is similar to the ALT tag, but instead of a text description for images it is used as a short description of the page you’re linking to.

5. Personalize all your messages with your subscribers First names.

I hate receiving a email that does not have my name on it anywhere. You need to personalize the emails you send. “Dear Mr. Jones” or “Hi, John” instead of, “To whom it may concern” makes your subscribers feel special.

6. Always get permission

There’s nothing worse than sending unsolicited or SPAM emails and not adhering to the CAN-SPAM Act of 2003.

Instead of sending SPAM, contact your current supporters or customer base and ask permission to place them on your list. Also, place a sign up form directly on your website.

HIP Newsletter7. Include a unsubscribe button.

If you do not provide a clear and easy way to unsubscribe from your list, your email will be considered spam, and you could lose credibility.

8. Have an intriguing subject line.

The subject line provides an overall summary of the contents of your email. Create some interest; a catchy subject can lead to a improved open rate.

9. Track your results.

Most major email providers, like IContact (affiliate link), allow you to track open rates, bounce rates, clickthrough rates, etc. Track your results over time and store them in a spreadsheet to see how your emails are trending.

10. Test your emails in different email clients.

Create a template for your emails and test it in different email clients, operating systems and browsers. Once you’re pleased with how your template looks, you can reuse it.


Posted in E-Newsletter, Search Engine Optimization, Web Standards | No Comments »

The Business Value of Web Standards

Written by Lee Micai on August 29, 2008 – 10:59 am -

The below article was written by Jeffrey Veen of Adaptive Path all the way back in 2003. I completely agree with everything Jeff said. It’s just the right thing to do.

I hope you enjoy…

I’ve been involved in the Web standards community almost as long as I’ve been working on the Web, and I’ve long felt that designing to W3C recommendations is the Right Thing To Do. When it came time to redesign the adaptivepath.com site, my partners agreed that we should approach the project from a standards perspective. But before we started, we discussed whether the effort — and it was a lot of effort — was really worth it.

Certainly, the redesign increased our credibility with Web-standards aficionados. But industry accolades aside, how important is standardization to an individual business like ours? Do Web standards give organizations a return on investment? Does the transition to XHTML and CSS make financial sense? The answer to those questions is yes.

Speed Development

Though the sheer ease of creating HTML pages has clearly been beneficial to the Web’s growth, it’s also been a curse. Because they’re so forgiving, Web browsers have facilitated a system of seudo-code that breaks countless best practices in the programming world.

So many of our clients have been building multiple versions of their sites, attempting to present a perfect design for as many users as possible. For our company, we wanted one set of HTML pages, one stylesheet, and far less development work. With over 95 percent of Adaptive Path’s audience now visiting our site with standards-compliant browsers, we knew it was time to make the switch.

Web standards force you to error check. Simply declaring which version of HTML (or, for that matter, XML) you’re using will let you validate your pages against those specifications. Validation turns HTML into something like a scripting language.

Running your pages through a validator shows you exactly where your errors are. This reduces the time developers spend on QA, and gives your site incredible consistency between browsers. While current browsers still have rendering bugs, they are far less severe than they were five years ago.

Simplify Maintenance, Increase Opportunity

For years, the standards community has been extolling the virtues of keeping visual design separate from content, but logically linked to each page. This means your HTML becomes ridiculously simple. Most XHTML pages are little more than a collection of semantically rich and tags, with a pointer to a powerful CSS file.

This clean separation makes it much easier for you to develop and maintain your pages, primarily because the division corresponds to most teams’ distinctions between design and editorial work.

Recently, we hosted a CSS file for a client on our development server while they began production on content and backend systems. As we continued to iterate the design, we were able to simply edit the file without having to integrate with their versioning and release system. By working in parallel, we dramatically reduced the time to market.

Speeding development is a competitive and financial advantage. Shorter development times not only reduce costs, but free resources sooner, thereby increasing opportunity.

Open Up Access Options

Clean code pays even more dividends. Browsers that don’t offer compliant CSS implementations can now simply skip the style. In other words, semantic XHTML markup can be rendered in any browser — including non-traditional clients like mobile phones, PDAs, voice interfaces and screen readers, and anything lse that supports the most basic tag set.

A standards-compliant site that is coded for simplicity solves problems with mobile access, Section 508 accessibility, and past-version browser compatibility.

So you get all that and it’s easier to develop and maintain? Indeed. You can even eliminate some hard costs in the process.

Reduce Bandwidth Costs

When we stripped away the fonts, tables, and little images used as design elements on our home page, we reduced the size of the code from 20.9K to 9.2K. Now, this may not seem like a lot, but it would aggregate to quite a bit if our site generated heavy traffic.

Our 56 percent reduction in bandwidth usage is hardly relevant to a site that gets a few thousand page views a day, but large commercial sites get that much traffic in a minute or two. The most popular sites often get tens of millions of page views a day.

Saving 30K to 40K from each page view — plus a cached stylesheet that never needs to be downloaded again — can save you thousands of dollars per month. Ever see an IT guy get excited about a new design? You will.

Improve User Experience

Cold, hard cash is easy to quantify, but there are additional benefits to slimming down code. It’s no secret that a faster, more lively site will nearly always translate to a better overall user experience.

Huge interfaces squeezed through plodding modem connections have been a plague since the Web’s inception. The increasing dominance of broadband has only helped a bit. A hotel phone line plugged into a business traveler’s laptop may be the only tenuous link you’ve got to a new customer. Adopting clean, standardized code gives users a shortcut to accomplishing their goals at your site.

Justifying the Switch

These aren’t formulas for determining the ROI of migrating to standards, but they are some pretty good financial justifications. “It’s what all the cool sites are doing” shouldn’t be your only point when arguing for a switch to XHTML and CSS.

The economic benefits of standardization are tangible. Once we can quantify them, businesses will begin realize the true promise of the Web — interoperable content freely shared.


Tags:
Posted in Web Standards | No Comments »