It seems these days that everyone has a website. Some are plain, others flashy; some use frames, others tables; some even play music when you load them.
I'm a web designer from the old school. When I started designing web pages, I didn't have a graphical web browser at home, and a 14.4k modem was blazingly fast. I spent many late nights in the office working with the high-speed LAN connection and the graphical browsers to design my pages. Sitting here with my 1.5M connection and looking back on those days, I don't know how I managed, but somehow I did. I had to design my pages so they were quick to load (28.8k modems were standard at the time) and so they looked good in plain-textas well as in a graphical web browser.
Things have changed a lot since those days, but my opinions on what a website should be haven't. When designing a website, there are four main facets to be aware of though not necessarily in this order: quality, content, size and speed. All of these facets are intertwined, so they are not addressed individually in this article.
To or not to <blink>
If you've been online for any period of time, I can guarantee that you've seen some badly designed web pages. Sometimes they leap out at you with blaring sounds or jumping images, and sometimes they're nearly impossible to read because of colour selections. These are all things that are easily avoided in web design, and the avoidance of them is appreciated by web aficionados.
One excellent reason to avoid such devices is time. When I designed my first web page, I created a music page that had thirty second sound clips of my favourite songs. In the code of the page, I made it so that all of the clips loaded automatically when the page was accessed so visitors wouldn't have to wait for them to download when they clicked on them. This was a mistake. Every time I tried to access my own page from my home connection, it would crash my poor computer so completely that I had to reinstall the modem. After three attempts, I removed the automatic loading of the sound clips. Eventually I removed the sound clips completely from the site and simply provided links to the band sites.
Now this isn't going to happen often any more with faster and more reliable modems and computers, but the basic premise is still the same. There are still a lot of people out there who haven't had the chance to upgrade their computers to the fastest available, and many people still use 28.8k or 33.6k modems. If the web page takes more than 30 seconds to load, most web users will not wait. The point of having a web presence is so that people look at your page. If the main page is too complex, your web presence is essentially worthless.
Thinking outside the box
Another device that has been used and over used is the frame. I've seen some very tasteful sites designed with frames, but it's very easy to misuse frames. The nature of frames often assumes a certain window size in order to look the way the designer intended, and until about two years ago, many browsers did not support frames. Depending on the designer, each frame can have its own scroll bars which can easily confuse web neophytes. However, if the designer is concerned about accessibility and ease of use, it is possible to design a very nice page with frames.
My personal preference instead of frames is tables. With tables you can accomplish almost the same things as you can with frames, and in my opinion it makes it easier for new users to navigate. With tables you can't get lost with frames inside frames--something that is easy to do when browsing a poorly designed frame site. Another perk with tables is that most current text-based browsers will recognize them, and the page will still be functional; frames are not supported in text-based browsers. Once again, though, this is me from the old school, and I like my pages to be visible no matter what browser someone is using whether it be Netscape, Internet Explorer, Opera, Lynx, or any other browser.
How do you spell that?
Call me old-fashioned, but I enjoy reading documents that follow the basic rules of grammar and spelling. I admit that I'm not perfect myself in accomplishing it, but giving a good college try is a far cry from facing it with an apathetic "I don't care" attitude. I'll give anyone the benefit of the doubt at first, but chances are I won't spend much time perusing their web site. I've stopped reading certain authors and journalists for the same reason.
Most current word processors have relatively extensive dictionaries and will often check basic grammar as well. In my opinion, there's no excuse for the poor quality prose that is proliferating on the web. There are times when dialectical or grammatical liberties can be taken, but these times are generally not found on your average web site. When reading stories (just imagine a novel by Irvine Welsh written in dialectical brogue) or dialogue, I almost expect to find these liberties, but I find myself being overwhelmed by them when reading an article or a web page. If a visitor to your site has to think too much about the content of your prose, they'll lose interest quite quickly and likely won't be back.
It doesn't take much time to run your prose through a spell-checker or to have someone read it over. The ease of publishing on the Internet has almost taken out the middle man: the editor. In the world of fiction writing online, there are people who offer their services as "beta readers". The responsibility of these people is to read over the story for grammar, spelling, and continuity. In the world of web publishing, everyone who wants to have a good web site should have someone who is willing to beta read for them before the site goes live. It will be a refreshing change to read clean prose on the web.
Behind the scenes
The word "code" itself can be a daunting one, but the code behind web pages is actually quite simple. Writing Hyper-Text Markup Language (HTML) is essentially like writing a letter with a word processing program, except the commands are not implied. In other words, if you want to start a new line, the command has to be placed at the line break point. Web browsers do not recognize carriage returns.
One of the best ways to get a feel for the code is to look at the source on web pages. Click on View then Source on the menu bar of your browser to view the source of this page. There are also many code reference sites to be found; the one I find most helpful is Kevin Werbach's Barebones Guide to HTML (http://www.werbach.com/barebones/barebone_html.html). Some internet providers also offer classes in basic and advanced web design. Check with your ISP to see if they have such courses available.
In parting, I will leave you with a few pieces of advice for designing your web page:
1. When coding HTML, always finish what you start. Close the tags you've opened.
2. Check the colours on your page to make sure it's readable.
3. Once you've uploaded your page, look at it to make sure there are no broken tags or images. Check it with different browsers and on different operating systems if you can.
4. When in doubt, look it up. Merriam-Webster is online with a dictionary and thesaurus (http://www.m-w.com); the Barebones Guide has hundreds of code references. If you can't find it, ask a friend or colleague.
5. There's nothing wrong with a work in progress. I don't know if any web site is ever completely finished.
6. Above all, have fun!
This is the end, my only friend, the end
Thanks for reading. If you have any questions or comments, feel free to contact the turtle