Understanding Website Development
(part 1)
Website development has come a long way since the mid-‘90s when the Web explosion took place. Early websites were often written by individuals and were text-only affairs; nowadays sites are frequently constructed by professional web design houses employing teams of developers as well as graphics artists, usability, accessibility, search engine and database specialists all collaborating to produce and maintain websites responsible for millions of dollars of annual revenue for their owners. Of course, not all website development and design is undertaken at this level; many design houses are manned by a few people whose duties frequently overlap. And there are millions of websites authored by individuals either for small businesses or, increasingly, as weblogs promoting the authors’ lifestyles and perspectives on life, politics, news.
Development OverviewUnless buying an off-the-shelf site or populating a template weblog, a professional web presence will invariably involve a number of development phases and site revisions before, during and after go-live. Following a preliminary meeting to gauge the size and scope of the project and gain an understanding of the business model, principle objectives are identified and, unless a vanity site, market strength and competitors are identified along with promotional and search engine strategies together with various metrics to establish a baseline against which to measure objectives success.
A decision will be taken whether to include a content management system (CMS) providing the client with a degree of autonomy to update certain areas of the site themselves rather than rely on the developer to supplement of change page content at a future date. A classic example of such a feature would be an ecommerce site with an administration back-end where product lines are updated, or the CMS may comprise a simple interface for staff to change news features, special offers or other promotional content.
Project Documentation
Irrespective of site size or complexity, a requirements document is set forth describing goals and objectives to be achieved by the website. Sometimes the client will have prepared the document prior to the initial meeting. This may be in the form of an invitation to tender with an outline of project scope or it may be a detailed requirements specification. Frequently, however, this task will fall to the developer to understand and embrace the content, issues raised and spirit of the meeting and deliver an interpretation as the basis for further discussion. The paper should also identify role responsibilities; an appendix identifying all project players against deliverables.
Once the requirements document has been – inevitably – revised and approved, a functional specification is drafted detailing how the points of the requirements document will be achieved on the website and its supporting mechanisms. This is a rather more detailed document itemising all site pages together with their purpose and user classification – whether for public consumption or visible only to site management staff.
A separate document, the functional implementation, will describe the high level mechanics of development against item ownership and schedule the development phases and deliverables benchmarks. It is basically an implementation timeline and may further be supported by a number of Gantt charts and dependencies relationships. The implementation document may also contain deliverables sign-off stages.
Such documentation may seem inappropriate for smaller ventures but more protracted projects will benefit greatly from clear statements of requirements, implementation, ownership and schedule. If and when a project goes of the rails the documentation will serve both as a reference to identify errant responsibility and as a focus to regroup and continue.
Site Schema
A site map or schema is rarely necessary for smaller initiatives but larger enterprises with multilevel menus and complex navigational structures requiring significant inter-site linking are best tackled with an adjustable schema. This may sound complex but reality finds Post-It notes on a whiteboard a valuable and flexible medium on which to experiment. Programs exist – basically flowcharting diagrams – which assist the developer visualise layout and structure at a later detailed level but these are far less flexible and interactive when brainstorming objectives and features, especially when presenting to a group of interested parties.
Once target aspirations have been identified the developer will then produce a wireframe model of the website – a skeletal monochrome schema – detailing functionality, navigation and content placement. The sophistication of the wireframe depends on the complexity of the site and may vary from basic Photoshop line drawn models to a working HTML site outline. The benefit of the latter, perhaps even for simpler sites, is the client will gain a better idea of functionality and can play with the interface, even though it is bereft of actual content (represented by Greeked placeholder text, often Latin, which gives an idea of content shape). Subsequent adjustments are usually required until the design meets both functional and usability requirements.
The developer now concentrates on delivering a working first draft while the client focuses on providing the site content, both illustrations and copy - the words on each page. However, before examining website development itself it is as well to provide a few words on hosting and the servers from which the site will be run.
