Situs vi latinisses abanet.

Before I start, I clearly have to say that almost all websites suck! Especially official websites, like websites of universities or government agencies, on such websites, you mostly find everything except what you are searching for.


Source: xkcd


So why is the title of this post then about British websites? Well, I recently had to deal with some of them, for applications for vacancies. They all require cookies and JavaScript - Cookies are understandable somehow, but JS is not! And for cookies, simple session cookies should be sufficient, and they should not be public. Some of the sites even have stuff by Google - I really do not want this (usually) on a university website.

But the worst part of all is when there are .doc-files. Why the hell would anybody want a .doc file on a website? Many .doc files can be viewed using LibreOffice, but mostly there are several problems with the actual design.

On some recent sites, such .doc files have been used as "forms" one should fill out and then send back per e-mail. Which is extremely annoying. Not everybody has MS Word, MS Word is pretty expensive, and not even everybody uses Windows or Mac OS X. And OpenOffice sometimes makes mistakes. So: Just do not use .doc files!

And in any case: Do not rely on your form being applicable to everybody. Have somebody to answer e-mails when there is a problem with filling the form. One example why is given here.

You might argue that it is easy to say what is wrong, but hard to say what is right. So, here are several suggestions on how to (probably) do it right. Of course, without any warrianty.

Firstly, of course, one should discuss what exactly "right" means. The first thing is, of course, that the software to fill in the forms must be free of charge, and available on all - well, at least the mainly used (including Linux!) - systems, so everyone can use it. Ideally, there must be an open source software product. But of course, it is useless to try to make something run on all systems - there are so much screwed up configurations out there, that this is clearly impossible. The obvious solution: let a human control it. There is no need to do much, just checking whether everything in some filled form is right, and if not, sending a mail requesting the missing information, should be sufficient. But please, let somebody who "knows about computers" do that! The least helpfull thing is a secretary, asking you why you "not just open it with Word".

One alternative for filling forms is the pdf form format. It works with many programs, also open source software. The problem is that it is not widespread yet, and ... sucks ... somehow.
Similarly, there are Google Docs. The main disadvantage is: Google knows what you write. But ... who cares?

A possibility similar to pdf forms are pdf files which can be changed with software like Okular, Xournal, or by just printing, filling and scanning them. The main disadvantage is that probably most people are too stupid to use them. They do not have a scanner (and do not know that most copy shops have one), they do not know how to properly print pdf files (!!), let alone annotating them.
Alternatively, png images can be changed using MS Paint, Gimp, etc.

Also widespread is the support of Flash and Java applets. Why ever one would need Flash or Java for filling a simple form, this should be something everybody can use. Of course, both base on closed source technologies, but both have open source alternatives with which one could try to stay compatible with. Explicitly stating and maintaining this compatibility would of course be necessary. An advantage of Java applets is that this is a comparably old technology, so it is comparably stable.

And now ... I come  to the "revolutionary" part, which some webdesigners would kill me for even thinking about: Using old technology that is widespread und has proven stable!

For example, it may not look as good as a well-designed Word document with a nice shiny header, but still, a simple text document (.txt) which is designed to be viewed using a monospace font, should be sufficient for most purposes. The advantage is that vitally every system can show them. One problem, however, is the encoding. You can request the user to use UTF-8, but many users do not know what that means. Requesting the users not to use special characters is hard, when for example his name contains them. Good editors like Emacs and VI allow annotations that indicate the encoding. Notepad supports BOMs. It may not be perfect, but it should work in many cases. A major disadvantage is that every user can freely screw up the form. But this can be done with .doc files as well.

Finally, there is one technology which is widespread, takes care of encoding, and can be viewed by vitally every device: Good old web forms and HTTP. The main disadvantage is that you cannot just pass a file to the user, which he then mails you, but you have to provide some server application. However, this is normally not an issue. Creating some CSV-Output, such that the user can proceed working with the form later, when uploading it again, as well as creating a beautiful PDF from its input to mail to some secretary, can both be considered as solved problems. And - surprise - you do not need any JavaScript for this.