Site diagram: what does cluster of pages mean?
-
Hi What is the best way to represent site navigation in a requirements document for developing a web application? Have looked at the following link: http://www.boxesandarrows.com/view/site_diagrams_mapping_an_information_space[^] There seems to be an icon for a representation for a cluster of pages. What does that mean - cluster of pages? How do you represent the following scenario? Your page is a single page but with many tabs which can fetch/post dynamic data, forms, etc.
-
Hi What is the best way to represent site navigation in a requirements document for developing a web application? Have looked at the following link: http://www.boxesandarrows.com/view/site_diagrams_mapping_an_information_space[^] There seems to be an icon for a representation for a cluster of pages. What does that mean - cluster of pages? How do you represent the following scenario? Your page is a single page but with many tabs which can fetch/post dynamic data, forms, etc.
Personally I would just change it a bit to show the 'page' with a tab at the top and then the shadowed pages behind it. Possibly add a small side icon to indicate if the pages where drive via a DB dip (ie: small DB barrel style icon overlay) or perhaps just multiple pages in the file system using a folder icon. I have been in search of a standard for diagramming stuff like this for years and to be honest, I don't think this is something that the developer community is ever going to settle on. Sadly it just seems like its parts of human nature simply because we all see things 'visually' different in your head, even when there is a written standard. Often times I have seen the best solution in these cases within an organization is to pick a software package to use based on the features and then just all agree to 'get over it' with regards to the disagreements of the visuals and just agree to disagree and move on. As a side note that is kind of funny here, I have actually had managers and engineers complain that the original design document only had 2 or 3 cascaded squares in the design picture, but the implementation actually called for maybe 5-6 tabs, and they felt that made the design inaccurate :) My key learning's as an architect over the years have been to focus on the 'idea', the 'requirements' and the environment, and try to not allow the design tools to drive the design itself. Be flexible there enough to make sense within the context of the group, but try to stay consistent within the organization itself. Established standards within the company are important, but the real value in design is simply to document the design, regardless of how the lines look. I do however always make post-implementation design review meetings to discuss what worked and what didn't as far as issues like these. It helps identify the need for change in design documentation style, content, and process. To me this is just typical of any well run development organizations continuous improvement process. OK, I rambled far too long here... Hope it helped.