[3D Rendering Tutorial]
Web Site Navigation / StructuringTom Arah looks at the best way of setting up the structure and navigation for your Web site designs..
The most common mistake designers make when shifting to the Web is to continue thinking in terms of sequential pages. With hypertext there isn't a single reading line through the material but rather a multiplicity of options with the end user deciding which information is read and in what order. To a huge extent the Web designer's job boils down to facilitating this choice by providing a clear structure to the site, and clear navigation through it.
The first step in this task is to work out the broad divisions of information that you want to provide to your browser. The second step is to put that plan to the back of your mind, as you instead work out how your end users will be thinking. For my own site, for example, I automatically began by posting all my reviews, articles and tutorials to their own sections before realising that, while some discerning users would be fascinated by everything I wrote, others would be more selective. As a result I added extra site sections for each of the four different software categories that visitors would be interested in - DTP, photo-editing, vector illustration and Web design - and a What's New section so that regular browsers can quickly find recent pieces. With an introductory Home section and a forwarding Links section, the total number of categories is already rising above the optimal eight that can happily be kept in short-term memory.
The typical Web tree format is built on vertical parent and child and horizontal sibling relationships from a few top-level pages.
When you have decided on the basic structure of your site you are ready to begin preparing the navigation to make it accessible. You could set up links to your main site section pages from a single master home page, but it's tiresome having to visit the same page repeatedly and needlessly. Instead it's much more efficient to be able to instantly jump to any of your main top-level pages. The solution is to provide constantly available links to each of the top-level sections throughout your site, most commonly as a horizontal bar across the top of each page. As these major sections should only be changed as a last resort - so that regular users always know where they are and where they can go - setting this up isn't too much of a problem as you can simply reuse a single master template page.
Below the limited number of unchanging site sections, things begin to get more complicated. Obviously the information you provide on your site will change and grow over time so your structure and navigation has to be flexible and scalable. This is where the Web's typical tree, or rather root, structure comes in with parent pages having multiple children and each child capable of having children of its own. This underlying parent/child system is very efficient for both end user and author. As an end user, for example, you can quickly drill down through even encyclopaedic sites to quickly locate a particular piece of information. Crucially, maintaining and updating the site is also straightforward as to add each new page all you have to do is to add a single link at the right point in the chain.
Vertical drill-down navigation is certainly streamlined when first honing in on an area of interest, but as soon as the item has been located, the system loses much of its efficiency. In particular when you hit the bottom pages of the pile there is often no other option but to hit the Back button so that you can jump to another related link from a previous parent page. Such purely vertical navigation results in an experience more like purposeful pecking than true browsing and leaves the end user doing the majority of the legwork. The inevitable result is that your browsers are likely to look elsewhere and so miss out on other relevant information on your site.
To avoid this the designer's second priority, after ensuring that all information is easily locatable, is to keep the browser reading for as long as possible by constantly prompting them with links to other relevant information. If a reader has drilled down to my Illustrator 8 review, for example, I also want them to see how it compares to reviews of earlier versions and of other relevant programs like Corel Draw. Of course hyperlinks can link to any page, so what's the problem with providing links to other pages on the same level? The problem is maintenance. With a simple vertical drill-down structure each page only needs one parent-child link, but with sibling links this page-independence goes out of the window. Now whenever I review a new package I should also add a new link to it on every other review page! Keeping such horizontal links up to date is the single biggest bottleneck in Web design.
It was to solve exactly this problem that Netscape came up with the idea of frames with Navigator 2. Using the <FRAMESET> element and its ROWS and COLUMNS attributes allows the single Web page to be split up into separate <FRAME> elements each of which loads its own URL. The main use of this is to create static areas of the screen to hold permanently available navigation bars. A horizontal frame at the top of the screen can store all top-level links, for example, while a frame down the left-hand side can store links to child pages or, more importantly, sibling pages. Clicking on the links in one frame can then be made to target another so that clicking in the side navigation bar updates the main content frame. For my site, for example, this means that visitors can instantly jump to any other relevant review that catches their eye, while I only have to keep the relatively few master navigational frames for each site section up to date rather than the links on every single page.
The main use of frames is to provide constantly accessible sibling links on all pages.
The leap forward in terms of authoring usability was so huge that frame-based design quickly spread despite serious end-user criticisms. The Web design guru Jakob Nielsen on his site www.useit.com was especially harsh, picking out the use of frames as his worst possible design error as "frames break the fundamental user model of the Web page." Neilsen objected to frames on a number of grounds all of which came back to the underlying reliance on framesets rather than separate independent pages. "All of a sudden, you cannot bookmark the current page and return to it (the bookmark points to another version of the frameset), URLs stop working, and printouts become difficult. Even worse, the predictability of user actions goes out the door: who knows what information will appear where when you click on a link?" Perhaps worst of all was the fact that, as frames weren't in the official HTML specification, their use immediately split the Web into supporting and non-supporting camps.
Time is a great healer, however, and nowadays as Nielsen acknowledges things are very different. Netscape 3 fixed the problem with the Back button to make retracing your steps simpler while version 4 reduced the problems printing frames. Explorer 5 has taken things further still with the ability to correctly bookmark your current frame set-up and to archive the entire frameset to disk. Aesthetically too, the use of larger screens and the NOBORDER attribute have led to frame-based designs that are at least as attractive as their page-based cousins. In fact the TV-style channel-hopping metaphor that frames introduced has now become so commonplace that, rather than confusing users, it now rivals drill-down navigation as the dominant means of information access on the Web. Most important of all, browser support is no longer a serious problem as the frame elements have finally made it into the official HTML 4 specification.
Ironically, though, as the acceptance of frames has grown so has my disillusionment. My objections are purely pragmatic and selfish. To begin with the main purpose of any site is to generate and keep traffic, but frames have severe problems in this regard. In particular, because you can't link to a particular set of frames within a frameset, Webmasters can't add links to individual pages of interest. In fact it's worse than this as they can still link to the main content frame page's URL which means that the page will appear without any navigational frames around it. Far worse is the fact that this is also the case for all search engine generated hits. This means that a large proportion of my casual site visitors aren't seeing my easily navigable frame-based site at all but rather the odd completely orphaned standalone page!
Even more irritating is the amount of work still required in maintaining a frame-based site. When I add a new photo-editing review for example, I have to remember to update each of my review, photo-editing and what's new content frames. I also have to ensure that each link is targeting the correct frame. Generally this shouldn't be too much of a problem as you can set a default target for each frame or use the in-built "_blank", "_self", "_parent" and "_top" targets to load into a new window, the same frame, the parent frameset or overall frameset. Even so, it's still easy to make mistakes especially if you are creating your links externally in a Web graphics program like Fireworks. If you want a link to update more than one frame simultaneously, things get even more difficult as the only way this can be done is through nested framesets. The end result is a massive leap in complexity in which 90% of the navigational errors I have to tackle are caused solely by the use of frames.
All told, I'm a belated but born-again convert to the frame-free single-page approach to Web design, but at the same time I haven't got the time or patience to manually update all the pages that need it. Obviously what I need is an automated approach. That's where technologies like ASP and programs like Drumbeat can come in. With a fully database driven-solution all the links on the final page can be determined on the fly so that, once set-up, you can automatically include all the relevant sibling links on pages as they are generated. In fact with the use of forms and artificial intelligence you can even tailor the links provided to the individual tastes of the current browser. Such customised navigation is undoubtedly the ideal for the end-user, but for the average Web designer it's both too complex to set up and too restrictive in terms of layout control. Generated pages also have even worse traffic problems than frames because there's nothing for the search engines to index.
Server-based automation isn't yet a practical option for the majority of information-only sites so it's down to the major authoring applications to come up with a solution. All three of the main applications have come up with a similar approach with Dreamweaver's libraries, GoLive's dynamic components and FrontPage's IncludePage WebBot. Essentially these are separate HTML pages that are automatically incorporated into other pages whenever they are posted to the server. The huge advantage is that edits to the single master file are immediately reflected in all the pages in which it is embedded. In particular, by embedding a single sibling links navigation bar in multiple files you can keep the links in hundreds of pages up to date by updating just one page. The system offers all the navigational benefits of frames but, crucially, maintains the final page independence of the posted site.
If you're currently contemplating producing a frame-based site I would strongly recommend looking into an embedded HTML solution instead, but the system certainly is ideal. To begin with it's inherently complex and smacks of being a workaround. To update my site by posting a photo-editing review, for example, I would have to create three copies of the page for each of the reviews, photo-editing and what's new sections and then update each of the three content link component pages too. Also, when I came to post my review to the server, every other page that includes these component pages would also have to be updated and reposted. A far more fundamental criticism is that the system still depends on the author manually structuring the site and manually adding and maintaining links.
For so-called visual authoring packages that just isn't good enough and again each of the three main authoring packages has come up with a similar attempted solution in the form of DreamWeaver's site map, GoLive's site tab and FrontPage's navigation view. In each case these show the site visually in the form of a structured tree diagram in which you can add, delete and reorder pages. This visual structuring is another big step forward, but it does little in terms of controlling navigation. With GoLive the logical links between the pages in the site structure are stored as a to do list in the Pending tab of the Page Inspector for later action. With Dreamweaver you can go one step further and automatically add actual links with the Link to Existing Page command but these have to be added one at a time and appear as simple text links at the bottom of the page which then need to be sorted out. The end result is that the dedicated site views of the two main applications used by professional Web designer are really only useful for the initial storyboarding of a site, but pretty useless from then on.
The Dreamweaver site map can be used for storyboarding and for setting up basic links.
To begin with FrontPage 2000 looks even worse with no linking commands in its navigation view at all. What makes all the difference, however, is another of FrontPage's dynamic Webbot components: the automatic navigation bar. When you insert one of these into your page you are given the option of automatically including links to parent and child pages, to the top level pages or, crucially to sibling pages. Suddenly, in combination with the navigation view's visual site structuring, the whole problem of setting up navigational links for your site just melts away with the authoring application left to do all the hard work. Even better the maintenance of all links becomes completely automatic as you add, delete or move pages.
FrontPage 2000's automatic Webbot navigation bars can take care of controlling your links both to parent, child and sibling pages.
That's only the beginning of the advantages. FrontPage's automatic navigation bars can also be tied in with its shared borders feature which means that you can quickly set up every page on your site to share the same automatic navigation bars at the top, bottom, left and right of the page. Most powerful of all is the way that these shared borders can be tied in to FrontPage's professionally designed themes. The links in the navigation bar automatically pick up the current site theme complete with font, colour and point size and can even be rendered as automatically generated graphics and even interactive rollovers. Suddenly it's not just the navigation of the site that is taken care of but its whole look and feel. Even better, whenever you feel that your site is in need of a makeover, all you need to do is to fine-tune the theme and drag some pages around in the navigation view and you have a completely fresh site to post!
The integration of FrontPage's automatic navigation features with its shared borders and themes means that the structure, navigation and even design of the site all flow naturally.
Sadly it's not all good news. Trying to put FrontPage's controls into action on a reasonably sized and reasonably complex site soon reveals its limitations. For my site, for example, I have a number of wish list requests: I want to be able to have different colour coding for different sections and different border arrangements at different depths; I want to be able to have essentially the same page appear in different sections, but with different sets of appropriate navigational links in place; finally, I want to be able to create true random access navigation bars by point and shooting in the navigation view so that I can set up individual navigation bars with links from one page to any other anywhere in the site. Far more limiting is the fact that FrontPage offers no hands-on control over the power it already offers so that, for example, it's not even possible to control the width of the shared border. In the end FrontPage takes so much control of the site creation process that it doesn't leave enough for the author.
Ultimately the FrontPage fully-automated solution proves even more limited than the frames and embedded HTML solutions and it's the approach I would currently feel most reluctant to use on a real world site. However, it's important to recognise that the problems with the FrontPage system are all in the implementation rather than inherent. The fact is that, having seen the benefits of a truly automated navigation system in action, I'm incredibly reluctant to go back to the old manual ways. A reliable and fully thought-through FrontPage-style system would finally combine the best of both frames and embedded HTML. More than that it would open up a whole new approach to Web authoring in which the previous chores of setting up and maintaining consistent navigation and design would flow naturally and easily from the simple task of visually structuring the site.
Unfortunately, it's not just Web designers who have to remember to put structure and navigation at the heart of everything they do - the developers need to learn exactly the same lesson.
Hopefully you've found the information you were looking for. For further information please click here.
For free trials and special offers please click the following recommended links:
For further information on the following design applications and subjects please click on the links below:
[3D], [3ds max], [Adobe], [Acrobat], [Cinema 4D], [Corel], [CorelDRAW], [Creative Suite], [Digital Image], [Dreamweaver], [Director], [Fireworks], [Flash], [FreeHand], [FrameMaker], [FrontPage], [GoLive], [Graphic Design], [HTML/CSS], [Illustrator], [InDesign], [Macromedia], [Macromedia Studio], [Microsoft], [NetObjects Fusion], [PageMaker], [Paint Shop Pro], [Painter], [Photo Editing], [PhotoImpact], [Photoshop], [Photoshop Elements], [Publisher], [QuarkXPress], [Web Design]
To continue your search on the designer-info.com site and beyond please use the Google and Amazon search boxes below:
|designer-info.com: independent, informed, intelligent, incisive, in-depth...|
All the work on the site (over 250 reviews, over 100 articles and tutorials) has been written by me, Tom Arah It's also me who maintains the site, answers your emails etc. The site is very popular and from your feedback I know it's a useful resource - but it takes a lot to keep it up.
You can help keep the site running, independent and free by Bookmarking the site (if you don't you might never find it again), telling others about it and by coming back (new content is added every month). Even better you can make a donation eg $5 the typical cost of just one issue of a print magazine or buy anything via Amazon.com or Amazon.co.uk (now or next time you feel like shopping) using these links or the designer-info.com shop - it's a great way of quickly finding the best buys, it costs you nothing and I gain a small but much-appreciated commission.
Thanks very much, Tom Arah
[DTP/Publishing] [Vector Drawing] [Bitmap/Photo] [Web] [3D]
[Articles/Tutorials] [Reviews/Archive] [Shop] [Home/What's New]