Comments on Site Diagrams: Mapping an Information Space

Mike G — Fri, 26 Jan 2007 14:52:06 GMT

How do these techniques differ for large scale websites? The example shown is a fairly small site in scale (as it would have to be for example purposes). What if you were creating something along the lines of a full-service computer parts ecommerce site. The breadth of the level two tier alone would be mind-boggling, with 20-30 categories as well as product features all appearing on the homepage. It’s beyond me how you could site map something to the degree of Amazon, even in its infant stages. Would this be the process they would follow? Would they utilize shortcuts such as grouping the categories?

Jason Withrow — Fri, 26 Jan 2007 14:52:06 GMT

Andy – I agree; it’s definitely a trade-off. It just depends on the author’s desired goals and what the audience(s) will find most useful.

There have been a lot of excellent suggestions, so perhaps a second article should be written to explore some of those specific areas and provide more examples. Is there interest in a follow-up article?

Andy Kirkwood — Fri, 26 Jan 2007 14:52:06 GMT

Removing the leading ‘1’ for the homepage, makes it easier to use (read) the code as a short-hand for the content. Guess it’s a trade-off between communicating the general nature of the destination-content vs. the page Level.

Perhaps adding an example to the diagram that shows how to accomodate a section that is not a page would be useful.

Jason Withrow — Fri, 26 Jan 2007 14:52:06 GMT

Although the reference to the home page as 1 is redundant, having it there keeps the level numbering consistent with the number of digits involved. For example, 1.1.1 is a Level 3 page and 1.2.2.4 is a Level 4 page. If we eliminate the home page digit the reader has to add one to the number of digits to determine the level.

In regard to the second issue, the conflation of ‘pages’ with ‘sections/directories’, the icon used for ‘Company 1.1.1’ identifies this as a page. If a differing section label led to this page I would identify that as ‘Company (Company Overview) 1.1.1’, with ‘Company Overview’ being the section label used to reach the ‘Company’ page. If we had a section label that did not lead to a web page I would represent that by grouping the sub-pages in that section in a dotted box given that section label.

Andy Kirkwood — Fri, 26 Jan 2007 14:52:06 GMT

A suggestion regarding numbering of sections back to the homepage (as level 1). It might be more productive (for the end-client) to consider the homepage as a ‘wrapper’ to the site proper, similar to the cover or contents page of a book, and as such un-numbered.

Page numbering would then begin at the section level. Rather rather than 1.1, the ‘Company’ section would be numbered 1 (ref. Fig. 5), ‘Mission & Values’ would be 1.2, ‘Executive Team’, 1.3, etc. Where showing cross-links, the numbers would then begin with a unique ‘parent’ section ID rather than the redundant reference to the homepage.

A common issue structure diagrams is the conflation of ‘pages’ with ‘sections/directories’. With reference to Fig. 5, it is not clear if the ‘Company 1.1.1’ page icon represents a page of content, a section label, or both. If navigating to the ‘Company’ section of this site would the first content page be ‘Company 1.1’ or ‘Company Highlights 1.1.2’? Placing section labels across connector lines (instead of using page icons) can be a more immediate means of communicating that this is a label/content-grouping.

Jason Withrow — Fri, 26 Jan 2007 14:52:06 GMT

Excellent suggestion, Peter. Giving a visual indication that there are deeper levels of hierarchy would definitely be beneficial.

Manutius — Fri, 26 Jan 2007 14:52:06 GMT

An excellent article, but I would like to add one thing. I understand that this maps the information space, but would like to see something of the functional as well. There are on many occasions scripts which serve only to process and are never seen by a viewer. An example would be a script that updates a database. An addtional type should be added to the diagrams for such scripts.

Manutius — Fri, 26 Jan 2007 14:52:06 GMT

Jason Withrow — Fri, 26 Jan 2007 14:52:05 GMT

The stencils are from Visio’s built-in sets (Conceptual Web Site and Web Site Map). I also created some on my own using the tools in Visio. While I do not yet have these assembled into a separate library, some sample diagrams (in Visio format) are available at:

http://courses.wccnet.edu/~jwithrow/main.php?f=290&p=deli…

Shaun — Fri, 26 Jan 2007 14:52:05 GMT

I found this article extremely useful and want to start using this method in practice. Is there any chance you want to post the stencil library you used to create the diagrams?

Jason Withrow — Fri, 26 Jan 2007 14:52:05 GMT

The same techniques map quite well to portal architecture. In the past I have developed audience-specific diagrams for projects such as portals, where different user groups see different information and functionality based on their group membership(s). In those cases separate diagrams are extremely useful.

Suzanne — Fri, 26 Jan 2007 14:52:05 GMT

Presenting different versions of the diagrams to different stakeholder groups is even more important if you are designing a portal with targeted webparts, as well as links that can be targeted at different audiences. It seems to be common to experience stakeholder meltdown when attempting to explain how different users will see different things.
Is portal architecture a completely different discipline to web site architecture or can we successfully use the same techniques?

Sean King — Fri, 26 Jan 2007 14:52:05 GMT

I’m with Danny on this. I work on an enterprise intranet and use more abstract architecture diagrams to explain how people will move through sites. Detailed diagrams seem like overkill when presenting to clients, accidentally causing confusion and fear (weird but true, people are scared of what they don’t know and that includes websites).

But I absolutely see the value of very detailed, structural view of the site to better communicate to a team of web professionals producing the site. I can even see this being useful in tracking progress on project.

erin — Fri, 26 Jan 2007 14:52:05 GMT

The file structure problem has been fixed on the images.

Jason Withrow — Fri, 26 Jan 2007 14:52:05 GMT

Danny – good point about having different versions of the diagram, tailored to each stakeholder group. My only concern is having to track multiple versions and the time it could take to create them. I was hoping to serve the needs of both groups at once (in a single diagram), but tailored versions would allow for more specialized information.