In which order do you design your applications

Please give a breif description on why you believe one way is better than the other. Thanks...

UI, Backend (DB) then Application Code

Not sure if I would say one is better then the other for me, I personaly am terrible at design so I don't do it, I work with a designer and he does that and site updates, once he has the design finished (he creates static html test pages first then I create new stuff from how it looks) I then get to know what data is needed on the site, then I create the dbs then code the thing together.

I always start with the database, getting the relationships all planned out, etc. saves time (in my opinion) when coding. I then get the coding done before plugging it into a UI.

I did start off the way Viper and echo did, but I always found that I would twist the UI around so much and multiple times that I found the dev time was much faster doing it last.

My tuppence worth

I used to kind of come up with screenshots of the UI while developing the database design, simply because it helped me think through what the users wanted.

But these days I am leaning toward automated, or at least semi-automated GUI creation, at least as far as form elements and navigation. So really, the "design" phase (choosing graphics, colors, alignment, general templating, etc...) can happen after the logic is done.

The reason I now believe in doing the GUI design last is an interesting insight by Joel oh Software: don't make the GUI too pretty too early in the project. Because, if the GUI looks great, people assume the work should be done, so they are outraged that you still want to do "testing" and that there are "bugs". My experience confirms this exactly .

I like to start with the DB, then build my code around that, modifying the DB when necessary. If you use templates then you build the very basics of the GUI while coding (ie, the form elements) but add zero color, style, or even layout. I have to keep the GUI last b/c I'm one of those perfectionists and I find myself taking too much time changing the GUI while I'm trying to code if I do the GUI anytime but at the end. I also completely agree with rycamor's last statement about the customer feeling a finished GUI is a finished product.

UI? Gah, I hate creating UIs, I tend to ignore them as long as I can. The only UIs I don't hate designing are application level UIs (executables) where I can draw them out in resource editors.

Specifically for web development and UIs: everything I do now is xhtml, and I'm starting to really love Smarty for templating. Combine those tools, and for me, UI design is real easy, in the sense that everything can be changed by simply tweaking a template file, or changing a shared css file. I still, for the life of me though, can't design an attractive interface...

As for the backend versus code, I usually work on them simultaneously. I think out the project ahead of time, usually really well. I think that step is crucial. It may seem like a waste to spend a day or two with the computer off, not coding at all. But for me, it saves alot of time. Otherwise, if I need to change the database structure half-way through the project because I never considered x or y, there's no telling how many scripts that will affect. When I finally sit down to do the coding, I know how the databases are going to look, and have a good idea of what I need to code. So I usually do them synchronously as they're needed, going from component to component.

This is how I would most likely do it. The DB is definitely first, because the entire app is built on that. Taking care to create a good database design and schema can save headaches and coding time down the road. It can also help to plan out the overall application froma n abstract point of view. Then I might plan out the UI. Low-fidelity prototypes work great. Then I would work on the application code while creating functional HTML templates. I would probably put the final touches on the UI after the application "works".

I always design and make the DB first. I don't think you can really program without the database created since most of the work I do is based around the database. I then program all of the logic and link it into a templating system for the UI.

i usually do the database design first then create a basic UI so i have a "storyline" for the application. then when im satisfied with both... i do the code.

database design always comes first for me. but i sometimes tend to create the ui and code hand in hand. i know it's more headache that way but clients tend to have a lot of revisions as the project progresses.

None of the above. I use a method of continually evolving a prototype.

I'm somewhat surprized that nobody does prototyping. I have found that it is too hard to elicit feedback from the business people with just a blank sheet of paper.

The discussion is more useful when they can see something, sometimes they can't tell you what they want but will notice things when in front of them.

We used to write specs but found the project would get bogged down in paperwork with all the change orders. With some clients I would still write specs to avoid the he said/she said issue but with my current client that's not a problem.

Usually go for modelling the DB then writing classes for the main objects that will interface with the DB and then go to the UI.

I used to like designing UIs, however after dealing with marketing and end users I quickly got over that after following all the suggestions and plans detailed beforehand and still having all of it torn down because one person doesn't like how it feels. In the past we had marketing tell us flat out that the UI sucked and that it was clunky and unintuitive. When we pulled out the design docs and showed it to the person who said this, we showed him it followed the exact layout and design that he wanted from the very beginning.

-b

Okay... but when you start your prototype, do you design the database, UI, or code first? You still have to start somewhere...

I'll agree with most that I do the database first, design a basic UI, then the code to tie it all together. The "fancy" design comes last and I usually try to pass that off to someone else. I hate design (unless it's micro-electronic design... but that's different).

---John Holmes...

Content brainstorming, UI, backend, application programming

I start off first by thinking of what the site will be about.

I make a very simplistic on-paper sketch of the general layout, which later evolves into a Photoshop mock-up that I print out and show family and freinds to see what they think of it.

After I've gotten a decent design, I create folders for each section (and subsection) of the site. I fiddle around with it until I have it as organized as I can think of. Each weekday I work on 1 or 2 simple pages of the site (I have to go to school on the weekdays) and do several complex pages over the weekend.