Australian Library and Information Association
home > alianet > ALIAnet technical notes
 

[ rss feeds | aliaNEWS | chat | home pages | logs | web cards | web surveys | technical notes ]

ALIAnet technical notes

Our twenty major design principles...

  1. Our overall design philosophy is one of simplicity - offering a balance of text and images (and white space) which appeals to those whom we consider our primary audience. Our style may not be appropriate for some sectors of the web community, but it is what our visitors want and need.

  2. Site maps are useful for navigation - though we try to avoid the need for constant reference to a map by having a directory structure that is robust and expandable. It has stood the test of time, in that we have made very few changes to the structure in more than ten years. By careful planning and anticipating growth, file names and directories can remain as first published - thus permitting regular and consistent navigation.

  3. We believe that the vast majority of users of this site have machines capable of running at least Netscape 4.0 or Microsoft Explorer 3.0, and have a monitor screen capable of showing at least 640 pixels x 480 pixels, in 256 colours or more. This we consider a bare minimum for full enjoyment of the web. We create pages using a multitude of platforms and screens and recognise that in particular some Windows-based machines trying to cram 800 x 600 pixels into a small and low-quality 14" monitor may not see things as well as they could hope.

  4. However, we also recognise that a handful of diehard users have only text-based access to our site (using Lynx or other text-based readers), and therefore we provide text-based links in preference to graphic-based client-side image maps.

  5. Regardless of people's browser habits, we build the site with W3C validation, which means that the pages conform to guidelines on the use of html and cascading style sheets - making the site accessible to as wide a range of people as possible.

  6. We build for accessibility - for as many people as we can. In concert with good html coding, we build to conform to site accessibility guidelines, such as Bobby.

  7. We try to keep all of our pages under 25Kb in size, unless the page requires a large image to be portrayed - in which case we give advance warning that the page will take time to download.

  8. By using only a handful of small image elements, moving from page to page is very fast due to internal client-based caching, and therefore speed and ease of movement around the site is enhanced. This feature we use throughout the site - and remains the single most successful method of speeding delivery of pages and images.

  9. People visit our site by starting from a variety of locations (pages). We make no assumption that visitors only come through the front door (home page). We provide navigation tools such as a breadcrumb trail that allow traversing of the site, and not just a sequential read.

  10. The 'underline links' function of browsers is vital to navigation. We build pages so that all links are well-defined, and not hidden via style sheets or confusing choices of colours for links and text.

  11. Our filenames and directory/folder names reflect our general design philosophy - in that they are as full and clear expression as possible without detracting from the information flow. We prefer to use lowercase filenames wherever possible, and we link descriptive names with a full-stop (period) or dash, such as 'technical.notes.html', rather than 'technical_notes.html' or 'technicalnotes.html'. By choosing to use lowercase throughout the site, no ambiguity surfaces, and by using longer filenames, we avoid having to translate the filename to try to understand the content.

  12. Although our bandwidth is now equal to or better than university or full-commercial capacity, visitors may be working from a machine that has a slow dial-up connection. Pages therefore need to have minimal 'adornments' such as coloured bullets, large images, fancy graphics, javascript, animated gifs, etc... Keep it simple and everyone is happy.

  13. Frames are a complete waste of effort - unfortunately. They are non-intuitive and create a variety of difficulties for many users. Navigation becomes a nightmare, and for anyone who creates a new browser window to avoid frames will know exactly what we mean here! We avoid them.

  14. Cascading style sheets were meant to be the saviours of web designers - but unless planned extremely carefully, can fail in delivery. We've been very careful to implement style sheets that do not interfere with site viewing, nor to make the style sheets responsible for positioning (which is worse than using tables). Style sheets should not make a site impossible to use if the user chooses to NOT use your chosen style sheet.

  15. Icons as bullet points are mostly redundant, and we avoid their use wherever possible. We prefer to make the text an inviting reference in itself, rather than rely on adornments. HTML has many strengths, one of which is the ability to set out bulleted information well.

  16. All images used on our site are made as small as possible, and are html-tagged to show height and width, as well as an 'alt' name. This speeds loading of the information content of the page (technically, the text on each page is brought to the screen first, as the image boundaries are fixed and known - without the tags, the images have to appear before the text flows around them). These tags are essential on a small-bandwidth site.

  17. We assume that visitors would like to have a more interactive experience than just reading text, and where possible will provide the in-built tools to interact with the page: such as the provision of forms, pictures (if helpful) and e-mail links. This aspect is being developed continuously.

  18. We do not believe that plug-in technology offers a truly 'interactive' experience. The use of plug-ins demands more from each user, and requires limitless patience and makes a higher assumption about the capabilities of the client browser, and indeed the user! We begrudgingly provide PDF files (which are suitable for printing, but not reading on screen), and always try to offer an html alternative.

  19. Information is updated as soon as we receive or generate it. If visitors wanted to read three-month-old material, they would sit in a doctor's waiting room browsing the magazines. Older material is reviewed regularly to see if we can improve on it. However, bearing in mind that more and more material is being posted as reference material, much will remain untouched for long periods of time.

  20. Above all, we want the experience of browsing ALIAnet to be an information-rich and rewarding experience. We want people to come back and we want the site to grow (not to turn into a cobweb). Suggestions and visitor feedback is heartily-encouraged - and we make good use of all comment. Let us know what your thoughts are: without you - the user - this site would be pointless, worthless and futile. With your input, it can be something that rewards and benefits all who use it.

l back
ALIA logo http://alia.org.au/alianet/technical.notes.html
© ALIA [ feedback | update | site map | privacy ] it.it 3:34pm 29 May 2007