handyfloss

Because FLOSS is handy, isn’t it?

  • Meta

Tips for creating Web content

Posted by isilanes on November 27, 2007

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.

Leave a comment