Get In Touch & Receive Feedback & More Information Today!

About You
About Your Project
Tell Us More
Read our Privacy Policy
Request a Proposal

Posts Tagged ‘web design documentation’

What makes a good site map?

Wednesday, February 20th, 2008

What is a good Site Map?
There’s a debate going on about whether site maps will remain necessary with the advent of sites that do not immediately gain much from generating a site map (blogs, media sites, etc… ). While the debate about what will happen rages on, reality reminds us that this is today, and in today’s web, you need a site map.

What is a site map anyway?
A site map is simply, “a visual representation of a web site’s structure,” with the site map items typically arranged in hierarchical order. A site map can be used as a planning tool in designing a web site (the aspect this post deals with), or as a web page listing all of a websites pages (usually for search engines purposes and to help visitors easily find pages).

Site maps are displayed and presented in a variety of ways and have also been labeled structure models, a taxonomy, site hierarchy, navigation model, site structure, or site index. As a website planning tool however, site maps are best in outline format within a Word document or .rtf file.

Online collaboration tools have also proved to be helpful, especially if the site map is still being developed (my favorites so far are 37signals’ Writeboard and the handy Writemaps.

Why make a site map?
The importance of good documentation in a design project can’t be stressed enough. Anyone who’s been involved in a design project knows first hand the pain involved when ignoring good documentation comes back to haunt you later in the project.

Web projects are complex beasts requiring the skill and ingenuity of at least a couple people. The larger a web project is, chances are, the more people will be involved with the project (and not all of them will remain for the life of the project). Having good documentation then ensures that everyone stays on the same page, regardless of how often they come or go. This, however, does not just apply to large teams: even with smaller teams, it’s amazing how easy it is to miscommunicate ideas and/or spend time clarifying issues because of unclear documentation.

Did you notice how the last 2 paragraphs have been about documentation and not site maps?

That’s because the site map is the first (and possibly, most important) piece of documentation needed for a web project. As the name implies, it’s a “map” of a “site”, and without it, everyone would be lost.

What makes a good site map?
There are no “hard, fast rules” in writing out a site map. However, like the pirate’s code of yore, there are certain principles that should be followed:

  • Remember that site maps are hierarchical and should clearly illustrate a page’s position (in relation to the others) within the website. IMO, the best way to achieve that goal, and come up with a usable planning tool, is to use a simple numbered, outline format.
  • Use numbers. It’s a lot easier to say “1.4.2″ than it is visualize (then say) “I.IV.II”. (as if roman numerals aren’t bad enough, bullets are even worse).
  • Pages, it’s all about pages. As a planning tool, the site map tells you a lot about the pages by not only establishing the relationships pages have to each other, but by also “mapping out” these relationships and how they relate to the different components of a project (of course, hence the phrase “site map”). These page relationships can be rather complicated, and adding technical details and aesthetic notes will only quadruple the complexity.

All of that to say, avoid including functionalities, images, placement instructions, etc… If necessary, put an asterisk next to an item and add a footnote. Which sort of leads to my next point…..

  • Titles matter. Titles matter because if everyone refers to an apple as an apple, we would all understand that you want someone to pass the “round fruit with a firm white flesh and a green, red or yellow skin” and not, the “oval fruit with brown hairy skin and bright green flesh” in the fruit basket. As much as possible, choose the title for a page and stick with it. If you’re still trying to decide on the page titles, use “working titles” so that everyone knows you’re talking about the apple, not the kiwi, in the basket.
  • Now tie them together. Although not a part of the site map, it’s a good idea to start compiling lists as you develop your site map. How many forms will it have? What will they be called and what kind of information will you collect? How about videos and pictures? Make a list of all the pages that will have videos, pictures, etc… (obviously that creates another list: “Stuff I Need To Put Together”. Do you see how useful a site map can be?).

Note: these lists you’re beginning to compile don’t have much to do with the site map. Essentially you’re compiling them at the same time you develop the site map so you can develop a clear picture of how your website will function3. More on what to do with the lists later….

Want more? Check out:

  • Communicating Good Design by Dan Brown
  • Last, always remember that the way you want it to function is not always the most feasible, or may not even be the best way, so keep an open mind!

-FTK

2 Comments »

Web Design & Architecture

Wednesday, January 9th, 2008

The house my parents currently live in was designed and built many years ago when I was a kid.  I remember sitting down with the architect as a family and we made a list of all the cool things we wanted the house to have. We made a list of everything; from the necessary things like how many rooms to the seemingly insignificant (like the hole in the wall my sister wanted instead of a bedside table). It was a long and tedious process, but it was also exciting and my fascination kept me intrigued.

The architect then drew up a blueprint based on our conversations and as we went over it, we gradually adjusted the list of features we wanted the house to have. Some of the things we started with were abandoned and others we hadn’t thought off were added. In the end, we had a blueprint mapping out the layout of the eventual house.

Based on the blueprint, the architect built model/prototype of the house  (my sister eventually converted it to a doll house). My siblings and I spent hours looking at it and imagining what life would be like after the house was finished. Again, we spent time going over the features of the house and rearranging things until we were sure it was perfect.

Many years later (or so it seemed to me at the time), our house was finally ready.

I often feel like that architect whenever I start out on a new web design/development project because it turns out the only difference between our jobs is that I build websites and he builds houses (granted it’s a pretty big difference, but the methods are strikingly alike).

Just like with the house, the beginning of a project is spent learning about it, the clients and their goals, etc… We discuss your project and list any features you’d like, colors, etc… until we eventually settle down on a final list of features and how we would like them to work. This is often the most tedious part but doing a good job at this stage exponentially increases the chances of a smooth project experience.

This is also a good time to develop the content for your website and compile any additional files that will also be used throughout the website (images, PDFs, documents, etc…).

With the list of features in mind, a layout of the finished website is designed. Much like the blueprint of a house, the layout simply gives us a visual overview of the website’s structure and concentrates on placing each feature in the right place. In fact, the website layout is often called a blueprint in some circles (wire frame is another term also commonly used).

Blueprint

That layout then serves as the platform the mockup (the model) is built on. Basically, a mockup is a picture of what your website will look like after it’s been completed and its features have been implemented. It maintains the structure from the blueprint but now the color scheme is added, buttons designed, etc…

Mockup

It’s never quite right the first time around so several revisions are designed, colors experimented with, features are moved around, etc… until the “Eureka!” moment arrives (this is hands down the best part of a project).

Mockup 2

This is where you (the client) goes to Mexico, the production team work their magic with code and another remarkable website goes online.

-FT

Special thanks to Eric of Floorsnet for allowing me to use his project as an example 

No Comments »