Web Navigation


In part, the previous discussion of Content Development has outlined how the use of external CSS files allows the formatting of the webpage to be dynamically aligned to the capability of the receiving device. However, this dynamic capability typically requires Javascript to be enabled in the receiving browser, which then leads to another decision concerning the navigation options within the website.

What navigation options are required and desirable?

To some extent, how you answer this question depends on the nature and popularity of your website. For example, Wikipedia has thousands of pages on a multitude of subjects, but most users will probably find a specific Wikipedia page by entering the required subject, e.g. 'science', into a search engine and then looking up the associated Wikipedia page listed in the search index, which will typically be on the very first page. Alternatively, you might search on 'Wikipedia' and then use the local option in Wikipedia to search for 'science'. Either way, Wikipedia's status as a major website allows it to adopt a fairly simple navigation strategy. Of course, this navigation strategy is not necessarily the best approach for a website that nobody will know about or will fail to quickly find in the weighted ranking of any given search engine.

So what other navigation criteria might be taken into consideration?

Well, we might describe the nature of the website content as being analogous to a book. If so, we might consider the equivalent navigation capabilities of a book to find a given page through a table of contents or the sequential turning of each page or looking up a keyword via an alphabetic index. Of course, while all these facilities might seem desirable, there is a practical question to address at this point:

How are these options to be implemented?

As indicated earlier, the original Mysearch website was implemented using Microsoft Frontpage, which supported an automated hierarchical page navigation scheme. However, when Microsoft migrated towards Expression Web-Studio, it abandoned the idea of any obvious form of automated navigation. As far as it is known, there does not appear to be any product that now offers any comprehensive form of automated navigation, although there are several companies that offer software products that help build navigational trees by utilising Javascripts and CSS style sheets, which are then included into the HTML run-time within the <head> section. However, these products are typically limited in the type of navigation supported or are very expensive to purchase. Equally, many of these products are not that suitable for websites consisting of hundreds of pages, because they require the navigation tree to be built manually.

So what approach was adopted by this website?

Well, to some extent, the development of this website was free to experiment with a number of ideas, as it had no specific users to satisfy and no specific deadlines to meet. However, some consideration was given to the capability of the client devices, which might 'conceptually' be used to browse this website. First, it was decided that the design of the website would primarily be orientated towards broadband users, who would access the site via desktops, laptops or iPad-like tablets, i.e. devices with a reasonable screen size. As such, it was assumed that this type of user base would also enable the Javascript option in their browser and used a relatively recent version of one of the most popular browsers, e.g.

  • Internet Explorer
  •  Mozilla Firefox
  •  Google Chrome
  •  Opera
  •  Safari

In practice, most website designs probably have to make some trade-off between maximising the number of users who can realistically access their site against the complexity of supporting too many compatibility permutations. While backward compatibility support of users on slower connections and older browsers is an obvious problem, leading edge users adopting the latest versions of HTML and CSS only represent a minority in terms of numbers.

However, the key decision in determining the user specification for this website was the ability to use Javascript to meet all its navigational requirements.

However, it is highlighted that without Javascript being enabled, navigation of this website would be virtually impossible and therefore may not be a viable approach for some websites. So, having determining the capability of my 'users', it was now possible to define a range of navigational options:

  •  Main top-bar drop-down menu
  •  Up/down, next/previous page menus
  •  Expandable inset tree menu
  •  Expandable sitemap tree menu
  •  Keyword search facility

It is highlighted that some of the options listed above are a possible overkill, which were only developed in order to satisfy my own technical curiosity. However, each navigational option might be useful to different users at different times. For example, the top menu that run horizontally across each webpage allows first time users to quickly identify, and access, the main sections within the website. In contrast, the page menu(s) allows  sequential access to adjacent pages plus quick access to key pages:

  •  top - entry index.html page
  •  home - home for the current website
  •  up - goto the parent page, if available
  •  next - goto the next page, if available
  •  previous - goto the previous page, if available
  •  down - goto the first child page, if available
  •  sitemap goto a more detailed indexed description of all pages

While the inset tree menu on each page is quite sophisticated, as it remembers the nested level opened when switching to another pages, it is not necessarily that useful in most navigational situation. However, the same mechanism is also utilised by the sitemap, which provides an extended page description and hierarchical index, which allows any page to be accessed, and then returned from, in order to select the next required page of interest. Finally, while the search mechanism is not a local Javascript application, it is an important navigational option when trying to find any discussion using a certain keyword.

OK, but what about the implementation issues?

In order to support the navigation options outlined, it was decided to divide each webpage into logical sections using the HTML <div> tag, which then allowed the percentage [%] width of each section to be defined within an external CSS file so that the width can be dynamically adjusted to best suit the screen in use. The following HTML is only intended to be representative of the code, while the actual HTML source can be viewed online by using the view/source option on most browsers.

<div id="webpage">
<div id="header"></div> <!page title -->
<div id="topBar"></div> <!main drop-down menu -->
<div id="leftInset"></div> <!inset for position and tree menus -->
<div id="content"></div> <!main content section -->
<div id="rightInset"></div> <!inset for general comments -->
<div id="bottomBar"></div> <!bottom position menu -->
<div id="footer"></div> <!copyright statement-->

In many cases, ad-hoc web developers, like myself, start off having no specific idea about the potential size of their website, i.e. many sites simply grow and branch off in many different directions over time. However, in this respect, the Mysearch website had already identified its potential scope when being developed under Microsoft Frontpage. As such, it was recognised that any implementation had to support hundreds of pages, to which new pages might be added and existing pages re-arranged within some new hierarchy. However, this aspect of the discussion will be continued under the heading of Update Automation