Planning a Website
Gaving Wraith starts planning a website...
Recently I was offered the job of making the website for an international congress planned for 2006. I took it, as I wanted to see if I could apply any lessons that I had learned earlier, from making the official website for the international congress of art historians in the year 2000. I hope that I am not biting off more than I can chew by publishing a diary of the business, warts and all, in RISCWorld. Perhaps readers may find something of use. As I have not yet had any concrete instructions from the congress organizers, all I can do at this stage is decide on the principles which I will want to stick to, and sharpen my tools in readiness. In case the organizers do not want these matters aired in RISCWorld, I will keep them anonymous for the time being. So, apart from styling myself.
I will say no more. If all goes well I hope to be able to talk not just about my plans for the website but about my interactions with those commissioning it, and about false starts, misunderstandings, problems overcome, and so on.
Generalities
Anyone who has ever made a website for somebody else has probably found themselves having to explain over and over again that the appearance of a web page depends on the computer, the browser and the browser settings of the person viewing the page, and that it is mostly outside the control of the author of the page. What is more, HTML was designed that way, specifically to separate content from appearance, the content to be put there by the author, the appearance by the reader. Thanks to Sir Tim Berners Lee, anyway that was the theory. Cue, at this point, a rant about the world wide web becoming a world wide war ground - browser wars trampling over Sir Tim's noble principles of universal access, each commercial faction intent on outdoing its rival in subversion by adding bells and whistles to their browsers. There is little point now in crying over spilled milk - after all, the wicked forces of commerce supplied the market far faster than the W3 Consortium ever could have - but even so HTML, which started out with such good intentions, is now a bloated mess. I am not talking about particular versions of HTML but the totality of all the versions, it is not practical to expect everybody to have the same browser, whatever Darth Vader may be planning. If the sponsor of your web site wants to fix the appearance of her message then she should be asking for PDF files and printing them on paper to be seen by human eyes, not HTML files to be interpreted on screens of varying graphical capability by browsers which cannot agree on any sort of standard for reasons of commercial rivalry.
These considerations have a particular force for me, because I am a fan of RISC OS. I like to use an Iyonix on which to make my pages. I generally use Oregano2 as my browser. Occasionally I use WebsterXL. I also have a RiscPC with RISC OS 4.02, on which I have Oregano, Fresco and Browse, and my wife has a laptop running Windows XP with Microsoft Explorer and Mozilla. It is important to view one's pages with as many different browsers as possible, and it can be quite hard to make them look acceptable in all of them without sacrifice.
I will return to the business of useful software later. Meanwhile I will state the principles which I think are appropriate, not for every website necessarily, but certainly for my provisional guess about the proposed web site for the congress.
- Accessibility - The site should be browsable by as many people as possible. This means avoiding features that require a particular browser or a particular platform, as much as possible. In other words, keep it simple. See also the rant on my web site on this topic.
- Orthogonality - Maintain orthogonality between content and furniture. By this, I mean that each page should have the same furniture (navigation bars, fixed headings, logos, etc) and that it should be possible to edit or extend both content and furniture independently.
Accessibility is a principle that I am sure is well appreciated by RISC OS users. Should one use frames? Should one use Javascript?
Frames can make good sense when the furniture to content ratio is high, because the viewer does not have to keep reloading the furniture. On the other hand, sites with frames can be a nuisance when it comes to downloading or keeping links to individual pages. Of course, if one uses frames for a site one still has to have a frameless version for those whose browsers cannot cope, or those who prefer not to have frames.
Javascript? JScript? ECMAScript? Which version? The variations are dizzying. For accessibility's sake it is probably best to avoid Javascript in any of its forms. I am sorry about this because I have a soft spot for it as an educational tool, and it offers a lot of interesting effects. However, Javascript can be implemented in very stupid ways. I heard a story about a salesman demonstrating a laptop to some respectable customers at one of the BETT shows a few years ago, he clicked a link unintentionally and found his customers open-mouthed at a very rude picture. His hand flicked to the back button in a trice, but nothing happened. He tried to close the window. Nothing happened. The JScript interpreter in his browser was allowing the script on the porn site's web page to alter the functions of these buttons, so all he could do eventually was press CTRL-ALT-DELETE. That is a truly dumb way for a browser to be implemented.
Orthogonality is a piece of jargon that may be strange to some readers. This is a principle not so much for what sort of HTML the website should comprise but for how that HTML is generated. It says that the overall design, and the parts of the website that are not the content, should be editable entirely independently of the content, and vice-versa. There is an ancient recipe for writing a book: write chapter 1; then write chapter 2; then rewrite chapter 1 to fit with chapter 2; then rewrite chapter 2 to adjust to the new chapter 1; then write chapter 3; then rewrite chapter 1 again, and so on. This is the spiral method of composition which requires that every change in one part should be followed by a cascade of changes everywhere else. Modular it is not. I learned from my efforts at website creation for the art historians that if you do not give sufficient thought or flexibility to the overall structure then your efforts are liable to degenerate into the spiral method.
Cascading style sheets give a limited form of orthogonality, at least for those qualities that can be determined by attributes in HTML tags. The trouble is that not all browsers understand them and they are limited in effect. You may be able to change the background colour of all the navigation bars on the site by altering a single item in a CSS file, but you cannot change them all from vertical to horizontal, nor can you parametrize a style by some property that varies from page to page. So how can you get orthogonality? This leads us directly to the question of how the HTML is generated, and to what software we need for creating the website.
Software
Obviously, you need a browser to view your pages (several, ideally) and you need software to upload your pages from your hard disc to the web site where they are to reside. I use the excellent FTPc program for this. You also need a text editor, to look at the HTML source of your web pages. I use StrongED, though I am sure Zap, or even Edit would do just as well. But should you create your HTML by hand in a text editor? Well that is what I used to do. I did this for the Art History site. I would make blank template pages, copy them and insert content by dragging text in from elsewhere. That worked well enough until I found myself needing to go back and edit the template, which is almost impossible to do easily once the content has been added, unless you start all over again from the beginning - back to the spiral method, in fact. Of course StrongED has an HTML mode (several) that lets you enter tags at the press of a button, and there have been dedicated tools around for some time, such as !HTML
, that perform the same function. Alternatively, there is TechWriter, which lets you design a document in a more or less WYSIWYG way and then lets you save it as HTML. Unfortunately none of these approaches gets us anywhere near the holy grail of orthogonality. HTML, indeed the very notion of markup language (text with tags in it) which underlies HTML, mixes up the content and the furniture inextricably. The shift to TechWriter is even a step in the wrong direction, because it is not the appearance of the document we want to specify but its abstract structure.
What we need is a magic ingredient that will let us specify a web page, or a website, in far more flexible high level terms than any markup language can. We need a simple but powerful specification language. For example, let us think about navigating round a site. If some uniform means of navigation is to be provided (an ansible, let us say, to borrow a word from science fiction), what data must it depend on? It depends first of all on a table of visible labels indexed by the pages that should be reachable from the current page, and it depends on the current page. So we would like to be able to describe an ansible as a function of at least these two variables, and possibly others that determine its appearance. That means that this hypothetical specification language must be flexible enough to talk about functions and indexed tables of things, at the very least. Then we will need a piece of software to create the website from its specification - a compiler whose input will be a high level description (possibly written in a modular fashion in many files) and whose low level output will be the HTML files that constitute the site.
In the next exciting issue of RISCWorld...My first meeting with the congress organizers and...does the the magic ingredient for orthogonality exist?
Gavin Wraith