handyfloss

I’ve read in a post in Genbeta [es], about a “service” for e-mail senders called SpyPig. It basically boils down to sending a notification to the sender of an e-mail, when the recipient opens it. This way, the recipient can not say that she hasn’t read it.

I will deal with two issues: moral and technological. Morally, I think this kind of things suck. I have received these e-mails asking for confirmation of having been read, and I never found appealing to answer. But at least you were asked politely. What these pigs SpyPigs do is provide a sneaky way of doing it without the recipient knowing. Would you consider someone doing it on you a friend? Not me.

Now, technologically, the system is more than simple, and anyone with access to a web server could do it. The idea is that the sender writes the e-mail in HTML mode, and inserts a picture (can be a blank image) hosted at some SpyPig server. When the recipient opens the HTML message, the image is loaded from the server, and the logs of the server will reflect when the image was loaded, and hence the e-mail opened. When this happens, the server notifies the sender.

The bottom line of this story is that HTML IS BAD for e-mails. My e-mail readers never allow displaying HTML messages, and show me the source HTML code instead (of course, I can allow HTML, but why would I?). So this SpyPig thing will never work for against me. And this SpyPig story is just one more reason not to allow displaying HTML in the messages you read. Of course, for the e-mails you send, consider sending them in plain text. Your recipients will be a bit happier.

For more tips on what NOT to do on web/e-mail issues, check the e-mail/web tips section in this blog.

5 Comments »

From my own site at ehu.es/isilanes.

Comply with the standards

Much like in spoken languages, Internet information exchange requires a common language, understood by everyone. In this case, our browsers will be the ones making the translation from that language (HTML) into images, colors and human-readable text. Much like spoken languages, there is an “Academy” taking care of what is and what is not correct. In this case, the academy is the World Wide Web Consortium (W3C).

Much like in spoken languages, HTML evolves and changes, but when changes are not incorporated in the standards, misunderstandings happen. To assure a Web page is correctly displayed by any browser, first standards are encouraged (I wish they could be enforced), then standard-compliant browsers are made. The Web should not be designed for a specific browser, rather browsers should be made to comply with openly known standards. For a discussion on that, jump to the Viewable with any browser site.

If you want to make your site as widely viewable as possible, and keep your visitors happy, you should really follow the W3C standards, because this way you really know that any standard-complying browser will display the page correctly. Is making a standard-compliant page difficult? Not really. First, you could follow the Accessible design guide at the Viewable with any browser site. Then, learning some HTML programming could help. Finally, you are encouraged to put a “W3C correct HTML” button on the product page, as you can see I have done on my ehu.es/isilanes page (orange buttons on the left hand side above). This page, for example, has been correctly coded in HTML, and its CSS is also correct, as you can test clicking the aforementioned buttons.

The code for the HTML-correctness verification:

<a href="http://validator.w3.org/check?uri=referer"><img
    src="http://www.w3.org/Icons/valid-html401"
    alt="Valid HTML 4.01 Transitional" height="31" width="88"></a>

The CSS button:

<a href="http://jigsaw.w3.org/css-validator/">
  <img style="border:0;width:88px;height:31px"
         src="http://jigsaw.w3.org/css-validator/images/vcss"
         alt="Valid CSS!"></a>

Recall that you can put the above buttons in your pages at early stages of page creation (when they are still incorrect), and use them yourself to see if what you have done so far is W3C-compliant. The resulting validation page (saying “OK” or “Not OK”), usually explains the errors you might have done rather understandably, and help in fixing them.

Minimize the size

Every time a web page is visited, the client (the browser of the visiting person) has to download the contents of the page to be able to display them. The more fancy pictures there are in your page, the longer it’ll take to load. The more crap that the client has to download, the slower the visiting experience for that person. If a page takes too long to load in your browser, what do you do? Exactly, you quit and go somewhere else. Human attention time span is short, and more so in the Internet, so don’t ask your visitors for the patience you didn’t have when making the page in first place.

Avoid Java, JavaScript and Flash

The problem here is dual: size and accessibility. The problem of the size is summarized in the previous section.

The issue with the accessibility is related to the fact that you should ask your visitors for as few resources as possible to view your content. If they need to get and install some fancy software to access your functionality, then this fact might discourage them and make them go away.

Remember always that it is your task to make it easy to access your content, not the visitors’ to find the suitable tools for that. Use JS or Flash if you absolutely need to, but only if you absolutely need to. Usually a clever use of plain HTML resources will give satisfactory results, and will be much more visitor-friendly.

Avoid proprietary formats

Innocuous as they might look, formats like MP3 and GIF are patent-encumbered, which means that their use should/could be restricted by the patent holders. Also, using them forces the browser (in the case of GIFs) and MP3 player makers to comply with restrictive patent requirements (like e.g. paying royalties).

The best way to eliminate software patents is to dump patented material altogether. Use Ogg Vorbis format to encode your music, and substitute your GIFs for PNGs. Recall that patented software is illegal to modify, improve or have security holes/bugs patched by third parties, without permission of patent holders, which makes the openly developed formats evolve much faster, and eventually become better.

For specific reasons to dump MP3s and GIFs, see the Wikipedia pages for PNG and Ogg Vorbis. In short: CompuServe developed the GIF format without knowing that the LZW compression algorithm it used was patented (by Unisys). Later, after GIF became popular, Unisys announced that they’d start enforcing the patent (charge royalties) to commercial programs capable of displaying GIFs. Something similar happened to MP3 and the Fraunhofer Society.

With Open formats you’ll never have any such problem, and the visitors to your page will never have to pay royalties for programs capable of displaying the contents of your site.

No Comments yet »