Do you create sitemaps before developing a website?

Hi,
I am new to website designing. I've heard that you should first create wireframes and sitemaps before actually starting to code. If you're a designer, do you create sitemaps and wireframes? I want to know what you achieve by creating sitemaps and how do you create them?

 

I tend to use both.

A site map helps brainstorm and plan out what will be on the site, how content will be organised and what navigation will be required. My site map would be a tree much like in a file system.

Wireframing can be useful to plan how the elements will fit together and can easily be dragged around without having to refactor a lot of code. A Google search for wire framing tools will bring up lots of good tools like balsamiq mock ups etc.

 

Sitemap helps me determine how i will structure the website. if the client has a lot of pages and sub pages under sub pages then i know i will need internal page menus. But it also helps me to know the cost in developing as more pages for me, will be more work in adding content.

Wireframe works because it is like a BLUE PRINT of the house. So when we are ready to design, the graphic designers follows the wireframe to the TEE because it has been approved by the client. It is there for a guide and to limit scope creep from the client in making additional changes later on.

 

Wireframing is designer bullshit; it's just dicking around for nothing and pissing all over the accessiblity of the final result...

I wouldn't call what I do a sitemap; but I do start with my content or a reasonable facsimile of future content. Before you even THINK about screwing around with what it's going to look like, you need to ask VERY important questions -- the biggest of which is WHAT'S THE CONTENT?

What information do you want on the site, how would visitors to the site be best served by breaking that content into different pages? Can that content be broken into specific categories and how do you want to handle categories and navigation. This is all stuff I lay down in a flat text editor without HTML in separate files/pages LONG before I even think about adding my semantic markup much less screwing around with styling it.

Once I have that done I add my semantic markup saying what things ARE (headings, paragraphs, lists); since this is SEMANTIC markup that means DIV and SPAN have ZERO business being added at this stage. Once I have semantic markup of one of the basic pages, then I go in and build the layoutS -- YES, PLURAL -- with CSS adding DIV and span when/as needed. Said layout being elastic (expanding/contracting with the default / system font size), semi-fluid (max-width so long lines aren't hard to read, min-width so pre CSS3 browsers don't break), and responsive. Then and only then do you go into your goofy paint program of choice like Photoshop to make the graphics to be hung on the layout -- IF ANY. Thank you very much CSS3!

Basically this approach means the content dictates navigation, the content dictates the markup, and the content, markup and desired navigation dictates the layoutS.

After all, people visit websites for the CONTENT, NOT the goofy graphics you hang around it, NOT the goofy scripttardery people piss all over the page with using things like jQuery, and NOT any other "gee ain't it neat" flashy bull that just makes sites slower and harder to use! CONTENT FIRST!