Code, then design, or design then code?

[Brett_Tabke]

On a dynamic, 100% program generated site, is it better to:

a) write the program first, then design the site to fit the program, or
b) design the site and make the program fit the design.

What's your thought on it?

[mousemoves]

assuming you mean 'interface design',i would write the code first because design must fit within technology limitations and function. so, first what will the site do? next, write programs to do it, and finally make the interface.

[Brett_Tabke]

It is kind of a catch-22 situation with all the html being embedded in the application. Can't write the code with out the design, can't do the design without the code.

[sugarkane]

I often do a mock-up in straight HTML of how I want the basic layout, colour scheme etc to look, using faked 'dynamic' data, and then use this as a basis for coding. The more detailed design aspects come later - I try to keep things as modular as possible until as late as possible so that tweaks can be made.

[rcjordan]

>kind of a catch-22 situation

Exactly. I find that I'm having to bring them up both at once. One thing I've found; individual pages for dynamic sites tend to grow in content over time... sometimes by significant amounts. It's because it's so easy to go back and add this or tweak that. I've been able to exercise the most control over this by slicing the page design into 5 horizontal slabs... 1-header, 2-above the fold, 3-just below the fold, 4-just above the footer, and 5-footer. A 6th section is the horizontal side column (righthand in my case). Within each section, I tend to think "global, regional, or local" in terms of content strata. A header might have global and regional content, while the above the fold area would be all local. (Confusing, eh? Sorry, I can't think of a better way to describe it.)