Advance planning is what you need to do before you start looking for someone to implement your site. The clearer you are about what you want and need, the more likely your site is to succeed.

Where to start from

The main place to start from is always what will best serve your intended audience.

A site is usually:

• directed at some group or groups,
• with the intention of doing something for and/or to them - meeting some need(s), solving some problem(s), being a resource of some kind for them,
• and which will benefit you and/or them in some way or ways

Once you are clear about these issues, the design and functionality of your site tends to fall into place.

For example:

• sites which are advertising something aspirational to people benefit from intensive professional design,
• while sites which are designed mainly to provide information or to support a community  need much less design, but much more solid content.
• A site designed to sell things directly to customers needs to be able to list goods and take orders and payments, and take account of design, since people will be buying with their eyes
• and a site designed to support a community may need ways in which users can communicate with one another.
• sites which address the confidential needs of a particular organisation will need ways in which information can be kept confidential.

Be aware of conflicts of interest

There are often conflicts of interest to sort out right from the beginning. For example, designers wish to be noticed by other designers, your organisation may be tempted to serve its own ends rather than those of visitors, and your technology suppliers may be out to sell you a particular solution.

Be aware of these pitfalls as you continue to develop your specification.

Be clear who is your site for and how it could serve them

Web sites appear out of an ocean of technologies, practicalities, standards, design and aims and objectives.

Before work can commence on a site, there are a number of key questions to be answered. Some you can probably answer yourself, others may require input from people with knowledge of the field.

• What is your site for?
• Who is your site for?
• What should it do?
• How should it look?
• Which standards should it adhere to?
• Which technologies should it use?
• Which packages should be deployed? 
• Who will do what during development?
• Who will do what after going live?
• What is the development budget?
• What is the on-going budget?

This is a list of underlying issues that most web sites need to comply with, to be modern and forward-looking (and possibly to get funding) You should clear/specify these issues with your designer and engineer right at the beginning.

Usually the site should:

• be accessible - that is it should be usable by people with a wide range of disabilities, and these days, with a wide range of devices, and search engines, as well people with good eyesight, computers and monitors
• be usable. A site is usable if people can do what they want easily, and if it is obvious to them how to do it.
• be standards-compliant. The standards are (X)HTML and CSS (cascading style sheets)
• respect the meanings of all the html mark-up.
• in particular, should use tables for the display of tabular data, not as a way of implementing layout features
• separate mark-up from appearance by using CSS
• work on older screens with a resolution of 800*600 as well as on more modern screens with much higher resolutions
• Work on a wide range of browsers, and a wide range of operating systems
• ideally, within limits determined by the design, should resize to suit higher screen resolutions
• be printer-friendly: when a page is printed, unnecessary elements such as menus should not appear, and the remaining content should fit the paper it is being printed on.
• also (and increasingly) be usable on very low resolution screens, such as mobile phones
• be updated on a regular basis
• have satisfactory and secure means to support updating, possibly by a number of people
• be secured against spammers, especially if it is interactive

Many of these issues are made considerably simpler if you implement your design through a CSS framework such as YAML, and the content through a professional content management system such as TYPO3.

It is unlikely that your objectives are unique, so it is a good idea to research sites which have similar aims and objectives.

View sites critically, particularly with regard to

• who the site is ostensibly designed for
• who it appears to be serving
• what its objectives appear/ought to be, and the way it does or don't meet them
  
• whether the site does what visitors may actually want to achieve by visiting it
• whether it make is easy or difficult for visitors to do what the site is aimed at achieving
• whether the design adds to, or subtracts from, the usefulness of the site

See what not to do

Before you start, you may want to look at good (?) examples of what not to do. Take a look at this site, which lists the horrors to avoid, and provides copious examples of poor practice.

Beware, though, this site is so fascinating you may never leave.

It is important to plan and manage resources, both human and financial.

The following roles operate in the production and on-going management of a website, and they all need to be accounted for in the planning process.

In some cases you will have the necessary skills in-house (allowing for some training, perhaps), and in other cases you may choose to out source the function.

Normally, for example, hosting will not be managed by you directly, and you are unlikely to want to develop a complex piece of software in-house.

Recognising that each of the roles exists, and assigning and managing them may make a lot of difference later.

For example, if you choose a host then decide that you want to use a content management system, you may find that the host simply doesn't provide the facilities which the CMS requires. 

In many cases, a single individual may take on several of these roles, or a single role may be allocated to a group of users, or some roles may not be relevant to a particular site.

The roles are as follows:

• Visitor - A person who views the site passively and anonymously from the front end.
• User - Person who interacts with the site through structures such as enquiry forms and guest books which are open to any visitor
• Member - Person who logs into the system, from the front end, and thereby gains functionality which is additional to that an anonymous visitor gets. 
• Contributor - responsible for generating the content of the site - the words and pictures. Contributors can be:
  • Front end - adding content through the public interface of the site - usually by way of structures such as Guest Books, Forums or Blogs
  • Back end - adding content through the administrative interface: usually the content of pages on the site which front end users cannot alter.
  • Other content owners/sources - for example commercial photographers and the owners of copyright texts.
• Editor/Moderator - responsible for approving content entered either from the front- or back- end.
  • Moderators screen contributions from the front-end, to prevent unsuitable material appearing on the site: they do not normally edit this material.
  • Editors manage back-end contributions, and this may involve rewriting.
• Administrator - responsible for deciding who can do what to what, and able to carry out a number of functions which may be dangerous to the site
• Designer - responsible for the general look and feel of a site.
• Engineer - responsible for installing, configuring and possibly developing, the functionality which the others above work with, and for realising the work of the designer in code.
• Vendor - the company that produces the base package(s) which provide the infrastructure of the site.
• Host - provides and configures the server from which the site operates.
• Owner ? The owner is in principle the person who commissions the site, and has the ultimate say over what appears on it.

Be aware of lock-ins

Be aware that exactly what you own, and particularly which rights you have, may depend on any contracts that you have with all the other people who have roles. This will particularly apply to proprietary (as opposed to open source) software, which may be supplied as part of a hosting agreement and make it impossible for you to move the site elsewhere if things do not work out.

Similarly, some designers (particularly those who specialise in Flash) may maintain copyright on their designs, even if you have paid for them, or may simply not allow you to edit your own site.

A considerable chasm opens up between sites which are said to be static, and those that are described as dynamic.

Static Sites

A Static site is one designed to display information and not much else. There may be a minimal capacity for users to send emails to people associated with the site, or to download documents or other files. but that is about all you can expect.

The main thing is that, once completed, the site's content is not expected to change very much over time.

Static sites are mainly stored directly as collections of html files, each of which encodes a page, and other elements such as graphics files and other pages, which are linked to the html pages by links.

It is the fact that such pages are encoded and consist of collections of files which usually imposes a barrier between the owner of the site, and the creation of content.

Usually a static web site is created using a proprietary HTML editor such as Dreamweaver, Microsoft FrontPage, Microsoft Expression, or Net Objects Fusion.

Alternatively, they may be constructed using technologies such as Flash, which may result in an appearance of dynamism (things flying all over the place, complex effects on menus, etc., etc.). But ultimately, the content, again does not change, however complex and sophisticated the design.

A professional designer is more likely to use Flash, Dreamweaver or Expression: the other packages make it easier to do it yourself, but are less flexible, and less easy for a professional designer to work with.

If you need to add pages to your site, or edit the information already there, you will need access to similar software, and need to have skills in using it. The key skills are a knowledge of HTML, and some way to process graphics, though there may be all manner of other obstacles.

In addition, there is usually no way to contain access to the site: there is one way in, and once you are there, you can do anything.

This often leads to a situation in which the designer of the site also becomes the editor, administrator and engineer, effectively locking the owner out.

This may or may not be a bad thing, but it:

• keeps you away from direct control over the site
• may leave someone else in a position to go on charging you for things you could easily do yourself, and
• makes it difficult for you to update or extend the site quickly.

There are, of course advantages to static sites:

• they use little processing power on the server, and so can be hosted very cheaply
• they may solve the problem you actually have, if that amounts to little more than needing an on-line brochure with a way for people to contact you
• The site (particularly Flash sites) can be more design-intensive

Generally it is not a good idea to base a community, or a corporate web site on a static model, because it makes it quite difficult for a group to co-operate on the production of the site, and it becomes almost impossible to support the interactive elements which make a site immeasurably more useful to a community than just the display of information.

Dynamic Sites

Dynamic sites have content which is (usually) stored in a database and then displayed through a template which gives the underlying data a look and feel. While static sites are a series of files which are delivered directly to web browsers, a dynamic site requires (more) software which runs on the server.

There are a large number of server-side packages (We give you access to 33 common programmes with your hosting, and there are many more you can download and/or purchase.) Most of these have specific functions, such as implementing a bulletin board, a customer relations management system, or an e-commerce solution.

The advantage of these single-task solutions is that they are designed to do a single thing well. The disadvantage is that they all tend to need to control access by means of passwords, and they do not co-ordinate with one another, so if you hang several off the same site, your users may have to log in several times.

Certainly, if your site can be encompassed by just one of these, it may well be the best solution for you. 

If you need several of these functions, and if your site also contains quite a large amount of information, a content management system is probably the ideal solution.

A content management system in the abstract is one that takes information from one or more places, structures and/or edits it, and presents it elsewhere.

An example would be a newspaper - or, rather, the complex organisation which originates, produces, and lands a newspaper on your door mat.

A Web-based Content Management System (CMS), is computer software which supports the process of delivering a web site, and in general, that runs on and from a web server, and stores the information displayed in a database.

Except for the simplest web sites, an organisation is nearly always going to want to base its site on a content management system (CMS) of some sort.

A CMS is designed to make it easy for you to be in charge of your web site's content. Your editors add content to the site, using interfaces that have the minimum of complexity consistent with the task to be accomplished, and mainly using word-processor-like interfaces.

Pages are constructed (in principle) as and they are needed by combining an (X)HTML template - effectively a page with blanks- with the content (which fills the blanks).

There are many content management systems, with greater of lesser functionality and flexibility, and which may or may nor be open source. Gate Seven mainly base sites on an enterprise-level content management system, TYPO3.

While TYPO3 describes itself as a content management framework, because it could be used for other content management tasks, we are interested its major use - which is as a web-based content management system, a system which provides support for the delivery of web sites.