Case study: initial site design phase
On this page: the details of how I designed this site. Obviously I haven't given away all my trade secrets, as I want people to employ me to do the job for them! A more informal narrative on the design is also available (see below), which attempts to answer the questions that other site designers might ask.
Why did I want to have a site at all? Apart from my personal satisfaction and the rather dubious motive of "well, everyone else has one", I wrote down a few reasons for making my site. I stuck the piece of paper on my monitor for a few days to remind me not to get side-tracked.
The most important reason was to demonstrate my skills to potential clients; secondary aims are to share my knowledge with others, communicate with friends, and to get the attention of those potential clients. (I don't have many illusions about the latter, since web searching is getting exponentially more difficult. Searches that used to work well for me in 1998 now turn up so much dross I can hardly be bothered!)
For a client's site, I would do an audience analysis in conjunction with this, but I was fairly clear in my mind what sort of visitors I was hoping to attract.
Some of the content I had already from unused bits of other projects, or general papers I'd written; some could be recycled with changes, and much had to be written from scratch. I started off with a rather messy spider diagram of what I thought might be on the site. I wrote every topic from that on a separate PostIt note in a sort of one-man brainstorm (which probably did 3M's sales a power of good!). Then using a piece of flip-chart paper, I used the PostIt notes to try categorising the topics. Any that didn't fit the aims, or I decided were not worthwhile, were weeded out.
I eventually came up with five main content sections, plus the "site services" (search, site map, help etc.) Fortunately this conformed to the rule of 7 +/- 2, being the optimum number of topics for most kinds of information. Having decided on my main sections for the site, I created a simple hierarchy of pages where it was obvious there would be more than one; finer subdivision was done as the content was developed (for example, the accessibility page I envisaged as one, but divided once it became clear it was too long).
I could have refined my flip-chart by recording more about each topic: for example, links to other pages, status and source of information. This is useful for working with clients, but I had most of the answers in my head in this case.
This activity came before any thought about what the site might look like or how it might work. Lots of people do it the other way around, which is why they may come unstuck when their site grows.
Update: To prove this very point: As often happens, after several years of growing like Topsy, the site rather lost focus, so I repeated my analysis of what the site should contain, and how it should be organised. Never be afraid to go back to basics like this: times and sites change, and you need to be able to cater for change. A web site isn't generally something to be made and put on the shelf.
I'm not a graphic designer, as you can probably tell, but I spent some time thinking about the image I wanted to project. I decided that since my primary focus was the content of the site, I would concentrate on accessibility and a fairly clean image - so, no Flash, no splash screens or entrance tunnels, no banner advertising, and a small coherent set of branding graphics.
In 1998, I decided to use fairly simple stylesheets to achieve a consistent look, and chose a black, white, dark red and grey livery, all browser-safe colours. I wanted to use one striking design element, and after a lot of looking, I came across the Tagliente font (designed by Judith Sutcliff) at the Will-Harris House site. I used this for the main logo, and a set of initials used in the navigation buttons.
Update: since then, I have gradually been refining the design, and in late 2003, I converted the site to a new blue-grey livery and different navigation buttons. But the beauty of my solution was that this was very simple to do: change the style sheets, make new logos and buttons, and edit the include files that make the buttons - only about one day to do and check. What took a lot more time was in converting the pages from HTML 4.01 Transitional to XHTML 1 Strict standards. But by doing that, I hoped to give the pages a few more years life before they need overhauling again: XHTML 2 (which has now been announced as HTML 5!) is not yet formally adopted.
Another redesign followed in 2008, further simplifying the overall look, and using more scripting to automate elements like the breadcrumbs and page meta information.
Once I had decided on the overall scheme of things, I had to think about how pages would look: what heading levels to use, where to put the navigation bar, how to lay out the text and so on. I settled on a navigation bar at the bottom of the page, in the hope that people might read the page before jumping somewhere else, and as importantly because pages starting with them don't read very informatively in search engine pages. In the early design, I used tables to constrain the line length to be comfortable to read on large monitors; latterly it's been possible to do this with CSS.
I originally came up with a plain layout for more detailed text-heavy pages, and a more decorative one with grey panels containing paragraph "labels" for general pages and the home page. However, the people who reviewed the site didn't like this second approach, saying it was confusing, so I abandoned it and redesigned the home page in a simple tabular way. Since then, it has been overhauled thrice; once with a complete redesign to make it easier to get straight into the meat of the site; the second time, a cosmetic change only; and this last time, a complete reorganisation, of which more below.
During the initial content analysis, I came up with a rough hierarchy of pages for the site, and this formed the basis for my understanding of the logical structure. If I was working on a site for a client, I would have formalised this in a block diagram, but felt it was overkill for myself. (As the pages were actually written, the detailed structure became apparent. In some places, some fine-tuning of how the pages related proved necessary.)
My first concern was to make the navigation easy to use, and as important, consistent throughout the site. So I made a couple of page templates and tested them till I was happy with the design. These would later be used to create each page with the same layout, so users would always know what to expect. The navigation bar gives access to what I decided were the critical pages: the five main content sections of the site, the search page, and the home page.
I developed rough guidelines for in-page and between-page navigation aids, based on the length of a page, the type of content (reference pages can be longer than summary or attention-grabbing ones), and the kind of relationship between pages (parent/child, sequence and so on). All such systematic links were to be given a distinct presentation with an icon.
The final task to make access easy was to decide on the "site services": search, a site map, a help page, and a switchable framed menu, which held a summary of the site map (since abandoned as it was hardly ever used). These are all common on well-designed sites, but I wanted to go one step further, so I decided to add a page specifically aimed at improving accessibility for all users. Of course, this depended on my technical design allowing for this.
In this case, the physical structure I chose pretty much mirrors the logical structure of the site, with page folders for each main section. Separate folders are used at the appropriate level to hold images, stylesheets, include files and so on. In a client site, it might also be necessary to take account of different owners/updaters of information, security requirements etc. when deciding on folders.
In a client intranet site, there will be a lot of work to do on clarifying the process for creating and maintaining the content, and on the supporting procedures that will be necessary. Since I am the sole person responsible for this site and already know the tools inside out, there was mercifully little of this to consider. It was fairly clear during the initial content analysis which pages would be static (i.e. written by me), and which would be served from a database.
At the other end of the scale, people commissioning a small web site for their business or organisation also need to think about maintenance, even at the start. I recently had a 'distress call' from someone who just wanted to change few prices on his site, and was being asked to stump up a considerable amount of money by his web designer (quite unethically, I felt). There are several ways to manage this - so make sure you have a plan and know how much it will cost to make day-to-day changes to the content.
Because this is an internet site, I wasn't able to design for a particular browser, but had to make a design that works in any browser, on any machine. Some of the issues I had to consider are listed on the accessibility page. Other things include using colour combinations that work on all platforms, not using client-side scripting or requiring any plug-ins to be used, and making sure that all links and meaningful images have alternate descriptive text.
I wanted to use some server-side programming, and chose to use ASP and an Access database, because I have some experience with both. (Given that I don't expect this site to have huge traffic, I don't think the lack of scalability will be a problem - of course, I'd be delighted to be proved wrong!) PHP would have been an equally good choice, and now we have ASP.net as well.