As I mentioned before, I’ve adopted a wonderful open source tool called Dia into my work flow. Many months ago, I was working with a team to develop a community based web application. Part of my job was consuming our discussions and creating documentation that embodied a cohesive view of all that we talked about. One of my tasks was to produce site maps and wire frames. Please note, I’m talking about pre-production site maps and not what you might expect to find under a “site map” link on the footer of a page.
A quick search for site maps on google image search shows the typical site map layout. Be it top down or branching from the center, they’re usually a tree based architecture. This relates well to the old way of building websites, where we always started with a home page and drilled down. On the modern web, this does not work nearly as well.
In our Web 2.0 world, websites are often more like applications. Thanks to AJAX, a single small section of a webpage can be purely dynamic and disconnected from other sections of the same page. Also, the use of standard navigation and interface widgets often links every page to every other page. This can break the conceptual information architecture that the tree model provides. Instead of a tree, you have a much more complicated graph.
In response to this, I went out on a limb and created a new style of site map. I started diagramming on paper and brought it into Dia. The end result is extremely information dense and looks more like what you’d expect to find on a white board after a meeting. While the document doesn’t communicate as quickly and easily as a traditional site map, it does provide a level of detail well beyond. I’ve continued to diagram in this way for a while, with extremely positive results. Here are some basic guidelines I typically use:
When I presented this new style of diagram to a co-worker, he called it “Site Map 2.0″. It stuck in my mind. The project itself was completely re-evaluated when the company purchased an existing community. We moved from a raw development strategy to an integration strategy, rendering my diagram obsolete. Thus, I feel comfortable sharing it with the world. A few bits of key information have been blotted out, just in case. Keep in mind, as you view the diagram, that the concepts and sections were discussed among the team. I’m sure from a “first look” point of view that there’s some ambiguity.
Comments, thoughts, and suggestions are more than welcome.test