The concept of "sitemap" as intended by this website maintenance documentation differs from the "sitemap" (better termed, perhaps, as "sitemap-in-progress") that is created during a website re-design and development project. (It also differs, for that matter, from the "Sitemap" provided to a site visitor, on the live site: /sitemap.asp.)
That is, here we refer to a decidely complete rendition of all site pages, directories, artifacts, and every kind of special item, be they hidden, protected, only seen under error conditions, etc., etc. It is the website administrator's view of the site, and in practice is more often seen as a directory listing than a graphed sitemap on a wall poster, per se.
Still, it is helpful to have a visual aid to understanding the overall structure of the website, and to see from whence the naming conventions are established (more on that below). The small portion of such a "wall poster" as seen in the graphic below provides an example in which can be seen the horizontal site "levels" across two samples of vertical site "sections" (or "silos" as they are sometimes referred to).
One key premise for the design of the sitemap and directory structure for a site using this "XML-2-HTML" system, is that the hierarchy of directories be used in a reasonably rigorous fashion.
That is, each site section (Level 1) (e.g "About Millennium") is to have its own subdirectory, with the "landing page" as /index.asp, (thereby /about/index.asp). This should sound quite non-controversial.
Further, each site sub-section (Level 2) (e.g. "Core Values") should also have its own subdirectory, with its "landing page" also as /index.asp (thereby /about/values/index.asp). You would think this to be non-controversial as well, but in practice many sites, particularly smaller ones, may adopt "leaf-node" pages at this Level 2, putting in /about/values.asp instead.
That approach effectively cuts off further growth in this site sub-section, as it becomes more difficult to add pages there, whereas the approach taken with this system ensures you have a sub-directory to which you can later (optionally) add more material. Proponents of the "leaf-node" approach may argue there is less work in creating the page to begin with, and that they are "certain" there will never be a need for growth in that area. They may be right. But this website build system flatters the website as being the purveyor of information about a growing organism, and takes the approach that erecting a stronger foundation for growth will be worth the small additional effort to create it.
[D]More importantly, when simple and straightforward rules like these are followed, increased automation can be implemented. Elsewhere in this documentation is described how the NAV2.xslt can automatically create all site navigation, with the simple dependency on regularized directory creation and use of /index.asp "landing page" filenames.
Finally, at Level 3 (e.g. "Development Candidates") the same principles apply: create its own subdirectory and use /index.asp for the landing page there (in this case: /rd/cardiovascular/candidates/index.asp). This final subdirectory becomes the location where any and all Level 4 pages (e.g. "MLN519" in /rd/cardiovascular/candidates/mln519.asp) are placed. Again, as addressed above, this requirement may be regarded as more controversial yet, the creation of subdirectories rather than leaf-node pages down at Level 3, but the same arguments apply as to why we do so (including the automation of creating Navigation for Level 3, and the ensuring room to grow with more content at Levels 3 and 4).
![[Note]](images/note.png) | Note |
|---|---|
For the record, in fact the strict usage at Level 3 was not decided upon before some "leaf-node" Level 3 pages had been created. (Their existence as such is certainly benign.) Secondly, there is no Level 5. If beneath a Level 4 page you had occassion for further pages grouped beneath that, you would not have a navigation mechanism, per se, for linking to them, but would instead use in-body hyperlinks, and place the pages simply in the same subdirectory as the Level 3 and Level 4 pages. | |
![[Caution]](images/caution.png) | Caution |
|---|---|
Deeper developments in site navigation should be pursued only when a site has enough content to merit it (e.g. llbean.com and its many retail products, etc.). Various DHTML dynamic menu solutions could be supported by the same "NAV2.xml + NAV2.xslt" scheme, though the deeper the navigation, the more complex the code to automate its construction, and the less welcome "exception" cases will be to the processing. | |
Investors. Exceptions to the rule exist: the "Investors" section, actually hosted at CCBN.com, must of necessity adopt their navigation scheme, which uses the Millennium "Nav2" buttons for links directly to their several specialized reporting programs (e.g. http://phx.corporate-ir.net/phoenix.zhtml?c=80159&p=irol-stockinfo). This has the unfortunate effect of taking the "Investors" section out of the automated Nav2 creation process. But as the Nav2 HTML snippets needed to be provided to CCBN one-time only, this is not an issue. (Again, yes, the NAV2.xslt could (may yet be) modified to accommodate specific URLs like these in lieu of the expected default index.asp. See above Note for discussion.)
Job Search, U.S. and Non-U.S. The forked path introduced by this late-breaking site requirement created an interesting exception case. Both /careers/search/searchusjobs.asp and /careers/search/searchnonusjobs.asp needed to become Level 3 pages that did not get their own subdirectories, nor could they become part of the "Nav3" navigation. The reason for this was the requirement from another 3rd party Application Service Provider (ASP), BrassRing.com, which could accomodate one Nav2 HTML snippet only from Millennium (contrast that with the eleven Nav2 snippets used by CCBN.com). Therefore, the Nav2 could not reflect the usual Nav3 level logical presentation of the choice between linking to "U.S. Jobs" or "Non-U.S. Jobs," but instead had to maintain a single Nav2 HTML snippet appearance across any and all pages "beneath" that Nav2, and could display no Nav3 information—just the Nav2-level "Search for Jobs." Therefore, the fork to choose which set of jobs to search was moved into in-body hyperlinks.
Note Discussion: That there is a work-around in play here is fairly evident, from the nearly blank white character of the page. This is what your information architecture can inherently show you. For this "decision point" of presenting a simple navigation choice ("U.S." vs. "Non-U.S.") really belongs in some kind of navigation mechanism, not in-body hyperlinks. On the rest of this page, other than perhaps including a definition of what the two terms mean, there isn't much else you could do to fill it in better, to make the page "work harder" for you. The "content" here should really be "presented" in a couple of navigation buttons, but, we had constraints and instead had to use the body of a whole, otherwise empty, web page.
Near-Miss "Exception". Another Nav2 was "nearly" an exception as follows: The old site used the Nav2 button to directly bring up the "Career Video" popup window—a not unreasonable usage. The new site more strictly has the Nav2 button link to (as usual) a "landing page" /careers/video/index.asp which in turn has a simple in-body hyperlink the user then clicks to bring up the "Career Video" popup. One more click for the end user, but this usage keeps the Nav2 snippet within the Nav2 automated creation process. One fewer "exception."
Note Discussion: The straightforwardly defined "rigor" of this overall approach (subdirectories and /index.asp pages) could be seen as ensuring there is always a place to provide the user with information on your subject. If you are discovering that there is little or nothing to say on the provided page, perhaps the subject doesn't merit its own subsection? Perhaps it belongs aggregated under another, already established sibling section? Or, if after considering that notion and rejecting it, perhaps you will find yourself better prepared to articulate what it is that makes this topic different, and worth presenting for the visitor's attention.
Actually, in the particular case of the "Career Video," arguably we have a different issue to consider: the "something to say" here isn't lacking—it is the video itself. The (almost) blank white page preceding the video itself is the challenge. Today the page is providing the necessary in-body hyperlink (plus one icon screen capture), but it could be regarded as the place to provide a more expansive alternative experience of the gist of the video for those users who may not have the correct software, bandwidth, or time at the moment, to experience the entire video. That is, a few screen captures, a video outline (along the lines of the Powerpoint show displayed next to the running video), or a few "pullout" facts or statements in text could be placed on the page, in a way that complemented and did not compete with the video itself.
Note Information Architecture. The point here is less about the Career Video and its landing page, and more about how the somewhat rigorous use of the directory structure can help the website developer and maintainer to think about the information they have, from the overall viewpoint of the Sitemap, to implement a site that shows it off to best effect, and ensures a satisfying navigational experience that is coherent.
![[Tip]](images/tip.png)
As described above, each site section (and all subsections, recursively descending) correspond to a file system directory (e.g. /media, /media/news, /media/news/2003) to be used in URL addresses for site pages. This same structure is used to identify and name many of the artifacts used in assembling the site (graphics filenames; HTML snippets; etc.). But as a shorter naming convention, an abbreviated, three-letter version of these directory names is used.
These three-letter codes are connected together by use of the underscore (_), and are prefaced with the digit corresponding to the site level indicated.
So we have: NAV2_1abt_2val_on.gif, for example. The graphic (.gif) for the NAV2 button for the "/values" subsection (level 2) of the "/about" section (level 1), or, /about/values.
Another example: Nav2_1cli_2crd_3res_i.html, is the HTML module for the Nav2 snippet that (working backwards): goes on the "index" page ("_i"), for the sub-sub-section "Resources" (level 3), in the sub-section "Cardiovascular" (level 2), in the section "Clinicians" (level 1). Or, /clinicians/cardiovascular/resources/index.asp.
One more: pghdr_1car_2ben.html, is the HTML module that holds the "Page Header" for the "Benefits" page (level 2) in the "Careers" section (level 1).
The entire listing of these three-letter codes is seen in another part of the documentation.