ICT4LT
Module 3.3ICT4LT
Module 3.3This module follows on from Module 1.5, Introduction to the Internet, and Module 2.3, Exploiting World Wide Web resources online and offline, both of which are concerned mainly with the Web as a resource and how it can be exploited in the languages classroom. This module aims to introduce the user to the process of creating Web pages. It includes sections that look in detail at how websites work, at HTML, Web authoring tools and website design. Section 8 includes representative case studies of websites designed by language teachers.
It is recommended that the newcomer to Web authoring begins by taking a look at Davies G. (1999) The Internet: write your own Web pages: http://www.camsoftpartners.co.uk/webcreat.htm
This Web page is designed to be read from the printed page. Use File / Print in your browser to produce a printed copy. After you have digested the contents of the printed copy, come back to the onscreen version to follow up the hyperlinks.
Main author: Fred Riley, University of Nottingham, UK.
Additional material supplied by Graham Davies, Editor-in-Chief, ICT4LT Website.
In essence, a website is simply a collection of documents, or Web pages, stored on a server, with a main entry point (the homepage) and an address (URL). The documents are written in a special markup language called HTML (Hypertext Markup Language), the most important feature of which is the ability to create hyperlinks to other Web pages.
To create your own website, you need to:
And that's it, essentially. As always, the devil lies in the detail, which will be explained in the rest of this module.
The WWW is based on a client-server model. A server is a machine or program on a network which holds resources (Web pages, data, software) which it will serve to a client machine or program on request. In the case of the Web, browsers are clients which request files from Web servers. When you click on a link in a Web page, or enter a URL in your browser, the browser sends a message to the server asking it to supply the file whose address is given in the URL. The server will then send a copy of the file to your browser to display or, if it can't serve the file - perhaps because it doesn't exist or access to it is restricted - it'll send an error message.
For example, if you click on the URL http://www.camsoftpartners.co.uk/websites.htm your browser will send a request to the Web server running on the computer (also referreed to as a host) located at the address www.camsoftpartners.co.uk, asking it to send the browser a copy of the websites HTML document. On receiving the request, the Web server will look for the file, check that its file permissions have been set so that it's accessible to the public, then send a copy of websites.htm to the browser, which will interpret the file as a HTML file and thus read the HTML markups in the document and display it fully formatted in the browser window.
It's important to understand that the Web operates on the client-server model, given the loose use of phrases such as "logging on to a website" which are bandied about in the media when discussing the Internet. When you access a website your browser doesn't "log on" to it, but rather just requests a copy of a file or files. Once the file(s) have been sent the client-server transaction is over - finished.
In contrast, if you use telnet or ftp (see Glossary) to connect to an Internet server, you have to log in with a username and password, and a continuous client-server connection is maintained until you log out, or the host logs you out.
In order to act as a server on the WWW, a host computer needs to be running a Web server, which is software which allows the computer on which it's installed (host) to serve website files to browsers. It's this software, not the host computer, which receives and processes requests from the browser. There are quite a number of Web server packages available, but by far the most common is Apache (http://www.apache.org), which runs on Unix/Linux and Windows computers, and which is open source software and hence is free to the public. A list of other servers can be found at ServerWatch: http://www.serverwatch.com
Unless you're in the unlikely situation of having to set up a network server from scratch, you won't need to obtain and set up Web server software. This will have been done for you by your local systems administrator (sysadmin), or by your Internet Service Provider (ISP). However, you may need to use server directives (server configuration instructions), particularly if you want to set up features such as user authentication on your website, so it can be important to know which server software is being used and where you can find documentation on it.
To create a website, you'll first have to create Web pages in HTML, or HyperText Markup Language. HTML is not, as is commonly misunderstood, a programming language, but rather a text-formatting language. HTML documents are plain text (ASCII) files with HTML tags placed amongst the text, and these tags instruct the browser how to present the text they enclose. For example, the following simple HTML fragment:
Using HTML you can produce <b>bold</b>, <i>italic</i>, and <u>underlined</u> text and, most importantly, you can create hyperlinks to other Web pages, such as the <a href="http://www.eurocall-languages.org">EUROCALL</a> website.
looks like this when rendered by a browser:
Using HTML you can produce bold, italic, and underlined text and, most importantly, you can create hyperlinks to other Web pages, such as the EUROCALL website.
It could be said that, in effect, HTML is the WWW. The essence of the Web is hyperlinking, the way that a document can contain direct links to other documents, whether on a local server or remote Web server, and this is the central feature of HTML, hence the Hypertext part of the acronym HTML.
Tip: You can view the HTML code of any document showing in your browser by choosing View / Source from the browser menu. If there are multiple frames visible, you can view the source of the document showing in the frame by right-clicking the mouse over the frame and choosing View / Source from the popup menu. Seeing how other authors have put together their Web pages is an invaluable help when learning HTML.
HTML has gone through a number of versions since it was first created back in the early 1990s and now comprises hundreds of tags, many of which have attributes (or sub-tags, as you could think of them). A tag is a code enclosed within the < and > characters which determines the formatting of subsequent text until (usually) a closing tag is found. Tags normally, although not always, come in pairs - an opening and a closing tag - and the text enclosed within each pair is formatted accordingly. For example,
<b>This is bold text</b> and this is plain.
will display the text
This is bold text and this is plain.
The opening tag, <b>, says "make all text after me bold until you find the closing tag", so if the closing tag is omitted, a common mistake amongst novice HTML authors, all text after <b> will end up in bold. The case of HTML tags is immaterial.
HTML tags are instructions to the browser as to how to display the enclosed text. When a browser reads a HTML document it parses it to find the tags then displays the text according to the tag instructions. Note that it is up to the browser as to how the tags will be interpreted. For example, text enclosed by the Header 1 (<H1></H1>) tag can be displayed in any font face and size that the developers of the browser decide. In practice, most browsers interpret most tags similarly, but there are important differences in the way they display some tags, such as tables, which can get Web authors pulling their hair out in frustration at times.
You can apply a wide range of text formatting in HTML, although by no means as wide a range as in a word-processing application. This is an important point to remember, that HTML formatting is far less versatile than that found in word-processing applications. Many authors are disappointed when they find that the fancy pages they've created in Word or PageMaker don't translate to HTML. It should be remembered that HTML was invented by scientists at CERN in Switzerland, led by Tim Berners-Lee, and they were more concerned with content rather than presentation. This situation is being partially remedied by the introduction of Cascading Style Sheets (CSS) in the HTML 4 specification - see http://www.w3.org/TR/html4/present/styles.html
Common formatting elements used include:
You can also use images (in GIF or, more commonly, JPEG/JPG formats) in HTML documents, including image maps which are "sensitive" pictures containing hotspots (links), and you can divide the browser client area (the area in the browser window in which the document is displayed) into independent windows, or frames, each displaying a separate HTML document.
For a full list of HTML elements, see:
Many HTML tags have attributes which govern how the tag is interpreted. For example, in the HTML fragment:
<img src="../images/home01.gif" alt="English homepage" width="40" height="40" border="0">
the tag is img, which displays an image file, and its attributes are src, alt, width, height, border, which dictate where the image is to be found, how to display it, and what popup text should appear when the mouse is passed over the image.
If HTML were purely a paragraph and character formatting language it would be of no use from a networking viewpoint. The central feature of HTML is the ability to create hyperlinks to other documents, and this is done using the anchor tags <A> and </A>. These define the enclosed text or image to be a hyperlink to another page. For example:
The code <a
href="http://www.cilt.org.uk/" target="_blank">CILT,
The National Centre for Languages</a>
appears in your browser as
CILT, The National Centre
for Languages
and the link will open in a new page, because of the use of the code target="_blank"
The <a></a> markup pair define a section of text which will appear as a hyperlink (usually underlined) in the browser, and the HREF attribute defines the URL to which the link points.
Microsoft has created HTML tags and extensions to existing tags that fall outside the official HTML standard, with the result that they will often only work in a particular browser and/or browser version. For example, the <MARQUEE></MARQUEE> tag, which displays text in a bar scrolling from left to right (or vice versa), is specific to Internet Explorer. Such tags can be a real nuisance to the Web author as, if s/he uses these, either by accident or design, s/he may find that a page which displays fine in Internet Explorer looks a complete mess or doesn't even load in other browsers. The novice Web author (and, in this writers opinion, all Web authors) should stick to standard HTML tags as defined by the Worldwide Web Consortium - usually referred to as the W3C: http://www.w3.org
With the profusion of WYSIWYG (What You See Is What You Get) - or more strictly speaking visual - Web authoring tools on the market, which claim to enable the user to create Web pages and websites without ever seeing a single HTML tag, many people ask why you should bother learning HTML in the first place. If you can create a Web page as simply as you can write a normal word-processor document, then surely only masochists or would-be nerds need to learn HTML? There are some simple answers to this question:
Even if you never intend to code directly in HTML, a basic understanding of HTML tags, and the principles of markup, will be of invaluable help to you when using a visual editor.
There are many, many HTML tutorials available on the Web and in book form, certainly more than could be listed in this module. Search for "HTML tutorials" at Yahoo! (http://uk.yahoo.com/) or Google (http://www.google.co.uk/) and you'll see what we mean. Additionally, nearly all HTML editors come with their own tutorial and tag reference. The problem isn't finding learning materials for HTML, it's finding good learning materials. The following selected sites contain good, user-friendly tutorials for the beginner, and aren't covered in banner ads or have content skewed towards E-commerce:
| Title | Notes |
|---|---|
| HTML Code Tutorial: http://www.HTMLCodeTutorial.com | A helpful and very comprehensive guide to creating Web pages. |
|
An Interactive Introduction
to HTML and CGI: |
A very good tutorial in HTML and CGI scripting, which allows you to try out code using forms on the website, hence the "interactive" part of the site title. |
| HTML Tutorials
for the Complete Idiot: http://www.myhtmltutorials.com |
A very friendly and informal tutorial primarily aimed at those creating personal Web pages, but applicable to all users.Written by Jeff Walters. |
| Learning HTML: http://www.trainingtools.com/online/html |
A beginner's training course in HTML. |
There are also literally hundreds of books on the topic, aimed at different audiences and written in different styles. A vast array of books is available, so we cannot in fairness recommend any particular book, but try a search in Google, e.g. for html tutorial books or similar keywords.
Don't try to memorise all HTML tags and their attributes. This is an impossible task, as there are more tags and attributes than a pomegranate has pips. Instead, familiarise yourself with what various tags can do, and always keep a detailed HMTL reference on your (physical or virtual) desktop so that you can quickly and easily look up the tag or attribute you need. The table below has three references which I've found useful:
| Title | Notes |
|---|---|
| The Bare Bones
Guide to HTML http://werbach.com/barebones |
A good concise HTML tag reference for experienced authors, with detailed syntax and examples. Tags are sorted by type (page, frames, table, etc). |
| Web Design Group
HTML Help http://www.htmlhelp.com |
This site, dedicated to authors who want to create non-browser-specific sites using standard HTML, contains a heap of useful resources, including a full HTML 4.0 reference, style guides, tutorials, a Web authoring FAQ, and links to HTML validators. HTML Help is also bundled with the free HTML editor 1stPage (see section on HTML Editors below). |
Use a code-based HTML editor whilst learning. When learning the basics of HTML, it's essential that you be able to see the HTML itself, so you should use a tool which will allow you to do this, rather than a WYSIWYG tool which "protects" you from the HTML. The free editors Arachnophilia (http://www.arachnoid.com/arachnophilia/) and 1stPage (http://www.evrsoft.com) are excellent for this purpose, or if you really want to get down to basics you can use a simple text editor such as Notepad (Windows) or TeachText (Macintosh).
Learn by example. If you see a Web page which you like the look of, copy it to disc, or use your browser to view its HTML source, and examine the HTML to see how the author's achieved the effect(s) you like. This is perfectly legal and above board: HTML is not copyrighted or owned by anyone. Copying someone's content may be a breach of copyright, but copying how they format and present that content is not, and has been a method of learning HTML which has been used since the WWW came into being. To use the current jargon, think of it as adopting good practice. See Section 9, Copyright issues.
Viewing the HTML source. In Microsoft Internet Explorer you can do this by choosing View / Source from the menu bar.
This section will look at what are coming to be known as Web authoring tools, but which are still commonly referred to as HTML editors. They are basically aids to developing Web pages and websites, and range widely in both sophistication and cost, although some, thankfully for beginners, are free. It must be emphasised that you do not need a HTML editor to write Web pages or develop websites. They are labour-saving devices which speed up, often considerably, the development of pages and sites, but they are not a prerequisite.
HTML editors can conceptually be divided into two categories: code-based and visual (WYSIWYG).
Code-based tools enable the author to directly edit the HTML code of Web pages, so that you actually see the raw HTML whilst writing and editing documents. Of course, you can do this in a simple text editor such as Notepad, but code-based tools include a variety of features to help the author, including:
The table below lists freeware code-based editors. The author has experience of Arachnophilia and 1stPage.
| Title | Notes |
|---|---|
| 1stPage 2000 http://www.evrsoft.com |
One of the best freeware editors available, with a similar interface to Homesite and nearly as many features, although the documentation is patchy and it has a few minor bugs. You can run it on four levels, from Easy to Expert, making it a good tool for novice Web authors. Review on WDVL at http://wdvl.internet.com/Reviews/HTML/1stPage2000.html |
| Arachnophilia http://www.arachnoid.com/arachnophilia/ |
A very good editor for Windows, available for free under the wonderful 'careware' concept (see the website for an explanation). An excellent tool for both beginners and experts, with an uncluttered interface, and with some very useful features, such as RTF import. |
| Brooklyn North HTML Assistant http://www.exit0.com |
One of the first ever editors. A commerical package, but available for trial for a limited period. |
Visual, or WYSIWYG, Web authoring tools allow you to create Web pages and sites without coding in HTML. You insert content into your page as you would in a word-processor, and the editor converts your content into HTML behind the scenes.
Visual editors are clearly very attractive to the novice author, particularly if s/he wants or needs to develop a website quickly without having the time to learn the ins and outs of HTML. They can also be very useful to experienced authors, particularly when it comes to page design and layout. It's a lot easier to draw a table in, say, Dreamweaver, and resize it as you like it by dragging table and cell borders with the mouse, than it is to insert table tags into your document in Arachnophilia, adjust the table by typing different numerical values into the table tag attributes, and hit the preview button to see the effect of the changes in the external browser.Visual editors often also come with 'ready-rolled' site and page designs which you can adapt for your own use, particularly useful if you're in a hurry.
Inserting links, images, lists, tables, frames, and other Web page features, is very easy in visual editors, and of course you see the page without all the eye-straining clutter of HTML code to distract from the page content, which is primarily what a visitor to your site is interested in.
Most visual editors do allow you to directly edit the HTML if you so wish, although it has to be said that some are friendlier on this score than others.The HTML that editors create also varies in its quality. Dreamweaver is widely acknowledged to generate "clean" HTML, conforming to W3C standards and lacking extraneous tags, whereas Front Page creates "dirty" HTML, full of proprietary and extraneous tags which make the resulting document difficult to edit in another package and which adds to the size of the document, or its 'weight' as it's sometimes known.
The whole point of visual editors is ease of use. The author is shielded from the HTML code, such that in theory, and according to commercial publicity, the author never needs to see a single HTML tag (in practice, every author needs to directly edit HTML at some time or other, no matter how good the visual tool). The author is thus free to concentrate on page and site content and design, and can thus, hopefully, get a website up and running faster than an author using a code-based tool. This process is helped by a standard and very useful feature of all visual editors, which is direct uploading of your website files to your online Web account.
This ease of use, though, comes with a cost. Visual editors are far more expensive than code-based editors and far more demanding of computer resources. We use Dreamweaver to create and maintain the ICT4LT website, backed up by Xenu Link Sleuth (see Section 6.3.3), for checking broken links.
There are a number of freeware visual editors. For example, Google offers its own facility: http://sites.google.com. Commercial packages include:
| Title | URL |
|---|---|
| Front Page | http://www.microsoft.com |
| Dreamweaver | http://www.adobe.com/uk/ |
| GoLive | http://www.adobe.com/uk/ |
CNET and ZDNet contain regular reviews of products such as those listed above:
http://www.cnet.com
http://www.zdnet.com
As with any other software application, or even physical tool, you have to choose the appropriate tool(s) for both yourself and the job in hand. You can't say that any one application is definitively the best Web authoring package as this is plainly a subjective judgement. You can try to be objective by listing a tools features, but just because tool can do everything under the sun apart from feed the cat doesn't mean that it's the most appropriate, or even a good, tool for the job - to take an extreme example, you don't need a high-end desktop publishing package to write a shopping list. When it comes to Web authoring tools, they all, in the end, do the same job - creating websites and HTML pages - so you should choose the tool(s) with which you feel most comfortable working.
That's not to say that there aren't consensus judgements amongst Web authors as to which packages are better than others. On the WDVL discussion list (http://www.wdvl.com/WDVL/Forum), a forum for Web authors, Dreamweaver is often spoken of well, whereas it's rare to read praise for Front Page. In the final analysis, though, tool selection remains an individual choice. You may indeed find, as many other Web authors have, that a combination of tools is best. For example, you could use the visual capabilities of Front Page to 'draw' framesets and tables, adjusting their size and properties until they're as you want them, then add content to the document in a code-based editor.
As the number of HTML editors continues to mushroom with the explosive expansion of the WWW, the need for reviews and assessments of tools becomes ever more pressing. Fortunately, many comparative reviews are now published on the Web, and whilst all reviews are subjective, they make a useful starting point for a novice Web author looking to choose appropriate package(s) to use. Good starting places for finding reviews on the Web are:
| Title | Notes |
|---|---|
|
Web authoring tools review
at ZDNet: |
Contains regular reviews of Web authoring tools - and other software products |
|
HTML editor reviews at Yahoo: |
Search for "HTML Editors" |
Comparative reviews are regularly published in popular computing magazines, so it's always worth browsing the magazine racks of your local newsagent.
There are also a number of tools designed for creating interactive exercises on the Web, for example:
See:
You can embed WAV, MP3, AVI and MPG files directly into a website and make them accessible via a clickable piece of text or an icon:
Software for creating and editing sound files: Audacity is probably the most widely used package for this task. See Section 2.2.3.3, Module 2.2, headed Sound recording and editing software.
Software for creating and editing video files: Windows Movie Maker is probably the most widely used package for this task. See Section 2.2.3.4, Module 2.2, headed Video editing software.
Adobe's Flash Professional authoring tool and its companion (free) plug-in Flash Player offer more efficient ways of integrating text, graphics, animation and audio and video clips into a website.
A well-designed website is more than just a collection of linked Web pages - it's a coherent structure which is easily navigable and where any piece of content can be found with the minimum of effort on the part of the user. Websites, their authors, their purposes, their content, and their target audiences, are so varied that there is no template which you can follow to guarantee a good website. There are a few basic principles that should be followed - see Section 5.1.
The most important rule which you should follow is: Design your website before you write a single Web page. You should have a clear picture, on paper or on screen, of how your website is to be organised, before you insert any content. That's not to say that this design should be cast in stone, immutable - on the contrary, a website's structure will change over time as content is added or removed - but to start on a site without a clear idea of how it will be organised is a recipe for creating a website worthy of inclusion in the infamous Web pages that suck, website, a collection of links to badly designed Web pages that serve as a lesson for all would-be Web designers.
Particular attention needs to be given to the way in which text is laid out and to fonts and colours: see Section 3, Module 3.2, headed General program design principles. As we point out in Section 9.9, Module 1.5, it is better to print an article containing a lot of text and then sit down in a comfortable armchair and read it. If your text is meant to be printed out then make sure that it will look as good on the printed page as on the screen.
By far the best exposition of practical guidelines for Web authors can be found in the Web style guide: basic design principles for creating websites by Patrick J. Lynch and Sarah Horton - the Web author's "Bible". This contains useful guidelines on site, interface, and page design, and is the reference which every Web author should consult before designing her/his website. As the Web Style Guide is so comprehensive, and so widely used, we won't duplicate effort by going into design guidelines in detail in this module, but will rather concentrate on a few specific guidelines which are well worth keeping in mind during the design process. Jakob Nielsen is another well-known authority on Web design - see Jakob Nielsen's Website.
Every website should have a homepage, that is a main point of entry to the site, ideally with an easily remembered URL such as www.mydomain.org (although in practice this can be hard to achieve). It doesn't have to be the only point of entry to your site and, indeed because of the way search engines index sites, it's quite likely that users will end up entering your site from a point other than the homepage, but it should be the main entry point, the URL of which you'd give in response to the question: "Where can I find your website?" It should be the main landmark in your site, and the user should be able to go to the homepage from any point in the site with a single click.
The homepage should be simple and short, ideally short enough so as not to need scrolling - and free of silly animations that take ages to load. The homepage is just an entry point to the site, and really doesn't need much content. Sometimes, a homepage just consists of a company logo which you click on to enter the main site, although that's a little minimalist for most people's tastes. More often, the homepage consists of a logo, perhaps a one or two line description of the website, and links to entry points to important sections of the site. If you're designing your site as a hierarchy, you can envisage the homepage as the pinnacle of the hierarchy, containing links to second-level pages. Or you could think of the homepage as an opening menu, although such terminology is currently unfashionable. The Open University's homepage is a good example of a concise site entry point.
Conventionally, the homepage is called index.htm or index.html. Although you can call it whatever you want, many Web servers will automatically look for an index file in a directory, so that you don't need to specify the filename in the URL. For example, the full URL of the ICT4LT homepage is http://www.ict4lt.org/index.html but the Web server software (the very popular Apache, http://www.apache.org/) will look for an index.htm or index.html file on a website if a filename isn't specified in the URL. So, rather than having to specify index.html in the URL, we can just use http://www.ict4lt.org, which makes for a much snappier, easier to remember and easier to type, URL.
A site which can't be navigated is worse than useless. A common danger with any hypertext system such as the WWW, which is inherent in such a systems non-sequential nature, is that of being "lost in hyperspace". After just a few clicks you can find yourself deep into the system's structure, viewing a document unrelated to that which you viewed when you first entered the system, and if you don't have any fixed landmarks with which to orient yourself you'll become completely lost, and in the case of the WWW may well end up in a completely unrelated website without knowing it.
In any website of more than one page, therefore, it's essential to have some sort of navigation aids for the user consisting, at the most basic, of links to important site landmarks: at the very least the homepage, and usually to entry points to sections of the site. More sophisticated navigation aids might include a site map or a full-blown graphic diagram, an index, and a site search engine. Commonly, such aids take the form of navigation bars positioned on one of the sides of the browser window, but you could more simply place landmark links at the top or bottom of each document to obviate the need for creating tables or frames.
If many of your Web pages will contain the same resource(s), such as an organisational logo or commonly-used images (e.g. blue balls for bullet points), it's wise to put these in a single directory to avoid duplication, and to make site maintenance easier. It's very common to set up an images directory purely for images to be used on the site's pages, and to link to images in that directory from any other page in the site using relative links, eg:
<IMG SRC="images/logo.gif">
This means that you don't have copies of the same image scattered around the website, which not only saves disc space but means that, if the picture needs changing, only one copy needs to be edited.
A relative link is distinguished from an absolute link. In an HTML document a relative link indicates the location of a file relative to the document, whereas an absolute link specifies the full URL. For example, the relative link of this module to the ICT4LT homepage is ../en/en_mod3-3.htm whereas it's absolute link is http://www.ict4lt.org/en/en_mod3-3.htm. It's generally better for Web authors to link to files within the same website using relative links rather than absolute links, as this makes site and file maintenance easier.
Visitors to your website should be able to find out the following information at your website:
See Section 6, Module 1.5, headed Evaluating websites. Visitors to your site, especially teachers, will base their judgement of the value of your site not only on its general look and feel but also on the quality and reliability of the content. See the ICT4LT CALL Software and Website Evaluation Forms.
An increasing amount of material is now made available on the Web rather than in printed form. This has raised the issue of how it should be referenced in a bibliography. Hard-and-fast conventions regarding the bibliographical referencing of Web pages are only slowly emerging. This is what we recommend:
You will find information on bilbiographical referencing at the bottom of each of our Web pages.
You've created your site on disc, but in order to expose it to the wide world of the WWW you need to make it available online. To do this, you'll need to obtain a Web account on a computer (i.e. a host) connected to the Internet running a Web server, and then to upload your website to the account.
Depending on your circumstances, there are a number of ways of getting filespace on a Web server:
If you are setting up a new website you will need to find yourself a domain name. Domain names start with http://www, which is followed by a dot and then a name that you choose for yourself, e.g. the ICT4LT website's name is http://www.ict4lt.org. Domain names - i.e. the bit following http://www - always have two or more parts, separated by dots. The part on the left side is specific and the one one the right is more general. The ICT4LT website's domain name is divided into two parts, ict4lt and org, the former being our project name and the latter indicating what kind of body we are: org = organisation. Universities in the UK always end in ac.uk = academic UK. Companies can normaly be identified by .com, and UK-based companies can often be identified by co.uk. So how do you choose a domain name? First, you have to check that your chosen name has not already been used by someone else. You can do this via most hosting service providers or by looking up the name at a domain name registration site, e.g. Nominet, which registers and records UK domain names, or Register.com, which registers and records domain names worldwide. Having found a suitable name, you then register it before anyone else has a chance to grab it. You then find aan ISP or hosting service (see above) that will sell you or give you adequate Web space for your registered name, and then you can upload your site: see Section 6.2.
If you want to add interactive features to your website, such as forms or search engines, then you'll probably need to use server-side CGI scripts - that is, programs located on the Web server which process form data. If so, then you should check with your Web account provider that you'll have a CGI directory (usually referred to as cgi-bin) at your disposal.
Unless you've chosen the DIY website hosting route, you'll need to upload your website files to your Web account. This is accomplished using FTP (File Transfer Protocol). In the not so distant past this would have required typing abstruse commands, but these days you can easily get hold of FTP software which runs in a Windows or Mac environment. Many Web authoring packages, e.g. Dreamweaver, or Front Page, incorporate an FTP facility so that you can automatically upload files by just pressing a button, without having to use a dedicated FTP application, which is sometimes known as an FTP Client. This is especially useful when you just want to upload files you've changed since the last site revision.
If you've subscribed to a hosting servive, it's quite likely that they'll have user-friendly procedures for uploading your website. You should check your hosting service's documentation for details.
If you need to use a FTP client to upload, by far the best client for Windows is WS_FTP. For the Macintosh, one of the most popular clients is Fetch.
A user-friendly, practical introduction to FTP can be found at The HelpWeb: a guide to getting started on the Internet.
It's important to test your site both on disc and online. In particular, you should check that:
Most HTML editors now have an internal browser, so that you can switch between HTML view and WYSIWYG view, which is handy to use when writing pages. To be sure that the pages display as you want them to be viewed you should open them in a range of external browsers. You should also ensure that your site is accessible to visually-disabled users.
The proof of the pudding, though, is testing your site live, as you can only see if it truly works as it should by uploading it and putting it online. Even experienced Web authors occasionally find that, say, links that work when they run their site from disc give a "Not found" error when it's run on the Web server. So, even if your site is working perfectly on disc, you should upload and test it before announcing its existence to avoid embarrassment.
Useful tools for testing your site are HTML Validators. These are programs or websites which check your HTML against various standards, such as compliance with official HTML standards, viewability in particular browsers etc.
Accessibility of websites to people with special needs is an important consideration, which is now governed by legislation in the UK. The Special Educational Needs and Disability Act (SENDA) of 2001 covers educational websites and obliges their designers "to make reasonable adjustments to ensure that people who are disabled are not put at a substantial disadvantage compared to people who are not disabled."
See also The World Wide Web Consortium (W3C)'s Web Content Accessibility Guidelines.
A few HTML editors incorporate validators, but you're better off validating your pages using online validators, such as the W3C Markup Validation Service.
A common cause of errors in a site when it's put online is the case-sensitivity of Unix systems, on which most Web servers reside. Unix is an operating system like Windows or Mac OS, but unlike these it is case-sensitive. On a Unix system, the filenames myfile.htm, MYFILE.htm, Myfile.htm, myfile.HTM, etc, are treated as separate files, whereas in Windows they would all be equivalent and represent just one file. So, it's important to preserve the case of file and directory names when uploading website files to a Unix system, and to make sure that the case of filenames used in a links and tag attributes is the same as that of the file on disc. As a rule, it's a good idea to decide from the outset to use only lowercase file and directory names.
You need to check your site regularly for dead links. The Web is, unfortunately, not renowed for its stability and consistency. Links that you have made to interesting and useful sites will suddenly cease to work because the site you have linked to has changed its URL, moved or just disappeared. This phenomenon is sometimes referred to as linkrot (see Glossary). Linkrot is a growing disease: see Jakob Nielsen, Fighting Linkrot, Alertbox, 14 June 1998. See also Section 9.1, Module 1.5, headed Dead links - linkrot.
The main reasons for linkrot are:
Most Web authoring tools (see Section 4.2) include a facility for checking links. At the very least such tools should be able to check for internal links.
As for external links, you may have to use a link checker. The following freeware tools have proved invaluable in helping to maintain ICT4LT:
Xenu Link Sleuth is a free software package that checks websites for broken links. Link verification is done on "normal" links, images, frames, plug-ins, backgrounds, local image maps, style sheets, scripts and Java applets. It displays a continously updated list of URLs which you can sort by different criteria. A report can be produced in HTML at any time while link checking is in progress.
There are a couple of lessons to be learned, e.g.
Keep a note of all useful sites and pages that you find, indicating the name of the person responsible for creating them and what they contain. If a link goes dead then you may be able to find the information again using a search engine.
Once you have created a site containing lots of links, make sure that it is properly and constantly maintained - which is labour-intensive but important. There is nothing more irritating than a site containing dozens of dead links.
Scott Windeatt wrote the following in a personal email. I know he won't mind being quoted:
Maybe we shall see the emergence of a new profession - the Web archaeologist, who trawls through websites and excavates individual caches, digging-up the long-lost home pages of forgotten Internet ancestors.
Maybe this kind of person already exists.
You may be able to retrieve the contents of a dead link by entering its URL into the Internet Archive (aka the Wayback Machine) at http://www.archive.org/. This enormous archive keeps records of revisions of websites at various stages in their lives. It is not 100% complete, but we have found it to be remarkably efficient at recovering old documents that we thought had been lost forever.
Keep us posted if you find any dead links at the ICT4LT site. We have had a couple of unpleasant experiences, which are documented on Graham Davies's Dodgy Links Web page.
The HTMGoodies website is aimed at Web authors and deals with all the issues involved in designing, developing, and maintaining websites. It's a comprehensive resource for the Web author, from novice to expert, with resources and tutorials on every Web-related topic you can think of.
Many schoolteachers have succeeded in getting to grips with Web authoring tools such as Hot Potatoes and Quia: see Section 6, Module 2.5. The following sites are examples of work produced by secondary school teachers in the UK. See also Graham Davies's Favourite Websites page, where many other websites produced by language teachers are listed.
The Ashcombe School's Modern Foreign Languages website: A wealth of resources for teachers and students.
Languages Online, Royal Grammar School, High Wycombe: A large collection of interactive materials for secondary school learners of French, German, Spanish, Italian and Latin.
St Peter's School, York: An extensive site for Modern Foreign Languages. Numerous resources and links to all things language-related, including interactive exercises, topic-organised links to sites useful for AS French research, links to French media sites and to other language practice sites.
When creating your own website, it is most important that you pay attention to copyright, especially if you intend to make your website accessible to the general public. For example, if you make use of materials (e.g. text, images, soundfiles, video files) from another website make sure that you seek permission from the owner of the site if it is not clearly stated that the materials are copyright-free.
If you include a link to someone's site it is normally polite to request permission - they may be delighted that you have asked them and will return the compliment by linking back to your site. They may, however, insist that their Web pages appear in a new window with their URLs clearly displayed in the address line - i.e. rather than in a frame - and they may impose other restrictions.
Be particularly careful about using other people's logos. You should always seek approval and there may be rules relating to its maximum/minimum size and its colour(s).
When downloading materials or copying from another website, don't assume that just because the materials are publicly available on the Web you can do whatever you like with them. Copyright infringement is a growing problem, which we refer to in:
If someone has assembled a list of links at their site, the list itself may constitute an original work and be subject to database right and/or copyright, so you cannot simply lift their list and paste it into your own website. The same rule applies to bibliographies, lists of films, etc.
Above all:
Finally, include your own copyright notice at your website, indicating information about the copyright owner, the date(s) on which the materials were created and your terms of use. See our Copyright notice as an example.
See our General guidelines on copyright, which is a general introduction to copyright, drawing on a variety of sources.
Davies G. (1999 - regularly updated) The Internet: write your own Web pages: http://www.camsoftpartners.co.uk/webcreat.htm
Horton S. (2000) Web teaching guide: a practical guide to creating course Web sites, New Haven: Yale University Press.
Lynch P.J. & Horton S. (2002) (2nd Edition) Web style guide: basic design principles for creating Web sites, New Haven: Yale University Press.
See also Section 7.
If you wish to send us feedback on any aspect of the ICT4LT website, use our online Feedback Form or visit the ICT4LT blog.
The Feedback Form and a link to the ICT4LT blog can be found at the bottom of every page at the ICT4LT site.
Document last updated 11 December 2011. This page is maintained by Graham Davies.
Please cite this
Web page as:
Riley F. (2011) Creating a World Wide Web site. Module 3.3 in Davies G. (ed.)
Information and Communications Technology for Language Teachers (ICT4LT),
Slough, Thames Valley University [Online]. Available at: http://www.ict4lt.org/en/en_mod3-3.htm
[Accessed DD Month YYYY].
© Sarah Davies in association with MDM creative. This work is licensed under a
Creative
Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
