But political groups are widely getting it wrong when it comes to a minor, but valuable, use of email addresses as identifiers.

The issue is that there’s more than one way to represent the same piece of information. For instance, you might write a phone number any of these ways:

• (555) 555-1234
• 555-555-1234
• 555 555 1234
• 555.555.1234
• 5555551234

Similarly, the same street address might be written in different ways:

• 123 Any Street, Apt. 4
• 123 Any St., #4

And so on. Any database is certainly going to recognize those phone numbers and street addresses as the same thing, so the same person doesn’t get 5 different phone calls and 2 different mailings. But the same thing doesn’t happen with email when people use sub-addresses.

I’ve written about plus-addressing before. I’m under no illusion that sub-addressing is used by a massive portion of the population, but I figure it’s probably used by at least a few percent of people — and for those people, it’s important. They use it for a reason: to better filter their mail (so they can find your message more easily!), to track how their address is shared, etc. These people will notice whether you respect their wishes and habits, and it will influence their impression of you. So it behooves you to play nicely with their addresses, especially since it’s so easy to do.

All it takes is two easy steps:

1. Your Web forms (and any other methods you use of collecting and managing email addresses) should respect sub-addressing. Subscription forms frequently reject + as an “invalid character” — but according to RFC, it’s not. Even more annoying is when a subscription form accepts + but the unsubscribe option doesn’t (and even worse when there’s no other apparent way to get an address off the list). For people who use sub-addressing, this is an unnecessary hassle — not to mention a potential violation of CAN-SPAM.
2. Your database should collate sub-addresses. In other words, if I’ve asked you to contact me at jdoe+x@example.com, you should contact me there. But if you also have jdoe+y@example.com and jdoe@example.com in your database, you should know that they’re the same user. The benefits of this will depend on exactly how you use those data, but I think it’s a good principle to start from. Importantly, whatever you do should be transparent and modifiable to the user. I can imagine, for instance, logging in as jdoe+x@example.com and seeing a message that says “We also have jdoe+y@example.com in our database. Would you like us to merge those identities?”

Bonus transparency best-practice: Don’t mask the TO: field — otherwise, recipients can’t tell where you’re contacting them.

By dint of what I do, I spend a lot of time working on the Web. Here are some of my pet peeves:

No links

People, it’s the Web. The very feature that makes it a Web rather than just electronic text is the existence of the hyperlink. Use it. Do not tell me where to find it. Do not tell me to google it. Google is not a replacement for the hyperlink. Just link me.

Here’s a blog post from an academic publisher that doesn’t use any links. The post is promoting a recently-published book with a remix contest. There are no links to the contest, to the book page, to online bookstores — nothing.

The contest is hosted on Facebook (a walled garden — another pet peeve). Here’s what the post says — I wish I was making this up:

We’re hosting the competition on their Facebook fan page. All you need to do is search for the event (Remix the Remixer) on Facebook …

Despite being a walled garden, it is possible to link to the event (although you’ll need to log in to access it). Did you seriously just tell me to search for it? And presumably this was written by the company’s PR department…?

Naked URLs

Related to the above are authors who give you the URL of the page they’re talking about, but just the URL — sometimes even without a link. Let me demonstrate:

Good:

Check out this cool search engine, Google!

Bad:

Check out this cool search engine, Google! http://www.google.com/

Worse:

Check out this cool search engine, Google! http://www.google.com/

No markup

Yeah, just paste a bunch of text into a Web page. Paragraph breaks, emphasis, citations — who needs that?

Ridiculous markup

I don’t even mean terrible design choices like grey text on a white background. I just mean straight up ridiculous markup. I assume this usually results from composing in a word processor and pasting into a Web page. For instance, every paragraph will be marked as class="MsoNormal" (a class which, of course, is never defined anywhere).

The UK PubMed Central Blog takes this a step further and marks up every word which is “misspelled”:

There’s no use for that; it’s just cruft.

And two faux pas

All of the above are errors for which I think there’s no real excuse. I’ll throw in two bonus pet peeves — I understand why people do them, but they still rub me the wrong way:

Content is not in the page

As in, “Check out this cool new document I wrote — here’s a PDF download.”

Anything that’s not (X)HTML isn’t as easy to use, copy, re-format, link to, etc. Moreover, it requires people to leave their browser (or at least to load a plugin).

I know why people do it: because it’s easier than preparing an (X)HTML version of the document (after already having made a PDF, Word document, or whatever). But it’s still irksome.

Deprecated / unsemantic markup

So you want to tell me about the book Moby Dick. Cool, let’s talk about it. But did you use the cite element — or did you use em or i?

If you used i (or span style="font-style: italic"), you told the computer that the text should be italic, but you didn’t say why. For anyone who wants to render the text in a way other than the one you intended (say, in audio), your markup doesn’t give the computer any useful information about what to do with it.

If you used em, you actually told the computer to emphasize the phrase “Moby Dick” — the same way you might emphasize Wow! or Awesome! Your markup is actually misleading now.

But if you used cite, you told the computer, “This is a citation to the title of work — render it as appropriate.” The standard way to do that in English is with italics, so unless you or the reader tells the computer to do otherwise, it’s rendered in italics.

I know why people do it wrong: we compose Web pages the way we’re used to composing text, where italics is italics. (Plus it’s just more tags to learn and remember to use.) But on the Web, rather than just making something italic, we can encode why, which gives more options to both the author and the user of how to render it, and makes it possible for computers to extract meaning from it.

I’m sure I’m not perfect when it comes to these and other Web-authoring rules of etiquette. (Plus, in email, I prefer top-posting or inline replies — gasp!) But I’m not trying to cast stones, just to call attention to problems — and, really, just to vent.

Email is my life, so I have to keep my inbox organized. That means a lot of filters and folders, tagging, and flagging as read/unread. I also use plus-addressing, which sometimes (when people share my address) means stuff ends up in funny places.

Bottom line: I do a lot of subscription management (subscribing, unsubscribing, changing my address, changing subscription options, etc.). And I’ve noticed that methods for subscription management are quite varied.

• Sometimes there’s a link, sometimes there’s a reply-to address, sometimes there’s both, and sometimes there’s neither.
• When there’s a link, sometimes it requires logging in (usually with a password I don’t remember), and sometimes it doesn’t.
• Sometimes there’s a confirmation email, and sometimes there’s not; sometimes I have to reply to confirm, and sometimes I don’t.
• Sometimes it simply says “click here to unsubscribe”, sometimes it says “click here to manage your subscription preferences”, and sometimes it says some other variation.

All in all, it’s not very standardized. (In fact, about the only thing that is standardized is that, when there’s information on how to unsubscribe, it’s usually at the bottom of an email.) That means more time figuring out how to make it do what you want.

There are actually some standards here. CAN-SPAM sets some requirements (although U.S. law only applies in the U.S., and there are questions about enforcement, to say the least). I wouldn’t be surprised if there’s also some RFC or other standard that exists — but if there is, it doesn’t seem to be followed significantly.

This shouldn’t be that hard. It’d save consumers a lot of grief (and, thus, senders — how many times have you seen a message posted to a public list, “Please remove me”?). Another motivation for senders to develop and apply the standard: they could use it as evidence that they’re “doing something” about spam (e.g. for PR purposes and to ward off further regulation). So can we get some of the major players in list software/e-mail marketing (e.g. Google Groups, Yahoo Groups, Mailman, L-Soft, Wired for Change, Lyris, Constant Contact, etc.) to sit down, maybe along with public interest groups like CAUCE or CIPPIC, and develop some standards? Then we can go about getting marketers to agree to use the standard — maybe something along the lines of the TRUSTe seal.

I’m not saying there should be only one way to do this. But if we can standardize the look and function, it’ll make things easier. Hopefully, we can also root out some of the more annoying practices (e.g. requiring login to unsubscribe).

Finally, maybe it could even use email headers, or something more than just text. Then we start moving toward semantic email, with the possibility for embedding functionality in client software.

Finally, the illusion of Google’s perfect single-mindedness as an organization is cracked. At last, one hand doesn’t know what the other is doing!

To be fair, Alerts is still in beta. (Hey, it’s only been around for three years, give them some time.)

Of course, Google Alerts is far from the only subscription service whose Web form struggles with plus-addressing. This is an unhappy fact I’ve noticed since I started using plus-addressing. Webmasters of the world: do not do this. It breaks an RFC, don’cha know.