Improving the email interface

Want an improved email interface? Then build it.
There’s been an ongoing discussion about adding thumbs up / thumbs down style buttons to email clients. While I am dubious this is a useful feature or something that recipients will use, if there are others in the industry that think it would be useful then I strongly suggest they go ahead and create it.
In fact, there are a couple things that have been asked for in email interfaces that aren’t currently provided. Last October I blogged about adding an unsubscribe button to email clients.

Now, many email clients have not implemented an unsubscribe button, but I’m told it’s not difficult to write plugins for many common email clients (mail.app, thunderbird, outlook). I think that if a few senders should get together and write the unsubscribe plugins and make them freely available to recipients. If the tools are out there, and the recipients want them, then they’ll be used. There’s nothing stopping senders from creating the tools they want created. Hire a few developers and get it done. You’re the marketers, market the benefit to the recipients to use your tools to improve everyone’s life.

The same thing goes for a thumbs up / thumbs down mechanism. If you write it, and it is useful (and useable) then users will demand that the proprietary interfaces provide the same functionality.
In the blog post I initially made that suggestion one of the comments said

To suggest that email marketers ought to get together and write plug-ins for popular email clients in order to fix the problem misses the point – this is a feature that ought to be a standard part of the software/web interface, as a plug-in it’s subject to vagaries like incompatibilities when the software is upgraded (see how many Firefox plug-ins show errors immediately after an upgrade).

Which shows some gross misunderstanding of how feature development works. Every feature started off with someone saying the mail client needs to do X either because they wanted the feature or because their users were asking for it.
In the case of unsubscribe buttons, or thumbs up/down buttons, end users aren’t currently asking for the functionality. That’s not to say they wouldn’t use it if it was there, just that they aren’t asking for it. The way to get the functionality inserted as a standard part of the software/web interface, is to get users to ask for it. In order to get users to ask for it, the best way to start is to create a plug-in that they like and use. If they like it in their Outlook interface at work, then they’ll ask for it in their webmail interface at home.
Many plug-ins are written by a single coder as a hobby or functionality they wanted or needed for their own mail. This is why there are maintenance failures this is a hobby or labor of love and real life™ interfered in the upkeep or the functionality was no longer needed by the maintainer or any number of reasons. This can trivially be resolved by someone being paid to maintain the plug-in and keeping up with the new versions of mail clients throughout the development cycles.
Is this guaranteed to lead to the email interface improvements senders are asking for? Of course not, nothing is guaranteed. But I can assure you that actually creating the protocols and buttons and interfaces will lead to widespread adoption faster than simply waiting for someone else to do what you want.