In what order do people build websites? [closed]

A website is like any other IT project initially.

1. Start with requirements; analyse those requirements; formulate the needs and goals of the website - that is, what it must achieve.

2. After that stage you need to get it designed and made. Having worked in this industry for many years, I find the best approach is to work from the outside in.

3. The visuals should be designed first, flat designs, getting the site looking exactly how it should be, everything on the interface that needs to be there, in the way you want it there.

4. Once the interface is totally designed, then the HTML/CSS/Flash/Silverlight structural build can begin. This gets the framework up, this should include all the variant pieces of the puzzle, the sections that are hidden, the components that come and go, move about, etc.

5. Finally the functionality can be put in, controlling all the parts with the necessary state control front and back to achieve the desired response from the interface.

   Note that the backend code that the interface relies upon can usually be done at the same time as the structural build, as once the interface is fully designed, the backend requirements for provision to the interface can usually be established.

6. The intermediate layer of control code between the structural build and the backend code is the last thing at any rate, as it is the last coupling between the layers in terms of what must be finished before you can start (the critical path).

NB. Following this pattern does have the advantage of creating a production-line assembly between workers if you have separate consultants, graphic designers, web developers/builders and software engineers. Passing through them in that order.

The only negative to that, is that there can be backlog issues if a given website is more demanding in a particular stage that slows up the corresponding team. If the same stage is regularly more significant this problem does get substantial. Not always controllable by hiring more people in that section either.

Your first concern should be the content that will be on the website. A good notion to Google for is 'Content First'. (Here's an article discussing working on your content in tandem with your structure: http://www.markboulton.co.uk/journal/structure-first-content-always)

For actually building the site, I feel that it is better to get the functionality (logic, events, output) that you mentioned in place and then move on to CSS and prettying it up. (I work as a front-end web developer)

The important thing is to plan out what you are going to be building before you hop in and start slinging code around. Your logic should be based on a spec and your CSS should be based on comps and wireframes, and all that should be based on communication with your client and what needs they have for the site.

If you are implementing a web site for a client, start with wire-frames. Unless your client is an experienced web developer or web designer, they will have zero ability to envision anything on the web. You have to show them exactly what they will see, or something that is obviously a drawing of a web page. Try to get them to speak to you about how the site will be used and construct some user scenarios or "use cases" from that.

When you feel you know what is required, and it's going to be an interactive site, I like to design the database first because it's the most "upstream" part of the application - everything else depends on it. Good design decisions there make the rest of your job much easier (and vice-versa). If you are making a blog or content management system, maybe it's just a matter of choosing a NoSQL database.

Once the database design looks good, I go back to my wireframes and implement them in HTML. The last phase is to write the middleware that queries the data from the database and builds the HTML for the screens.

The actual order varies for different projects and there is always back-and-forth where a design decision somewhere sends you to a different part of the application to compensate, but this is a pretty good default plan to start from.

To Summarize:

• Gather Requirements
• Design Database
• Start front-end (HTML etc.)
• Make middle "Business Logic" to connect front-end to Database.

Reading this over, I'd have to recommend that you write test cases for your business logic as you code it. Then when you need to change something you have a way to verify that everything else still works. Some front-end testing needs to be done manually. Use an HTML validator and test (manually as a user) on several different brands of browsers.

I have to disagree with @Orbling on 2,3,4. This should be a comment on his post but I'm not allowed to do that.

I would rather have the front end design and the back end work going in tandem. If you have a back end engineer creating functionality spitting out markup with elements having class attributes etc the visuals and design can come in whenever. Especially if you're designing off of a layout or master page. Modifying views/html to make it work for a front end engineer is no problem.

Take for example: css zen garden, do you really need a design before you make the functionality when your markup is just so?

No need to bottleneck your project around design. Other than that comment, I agree with Orbling.

I'd add comment but I'm too new, this is the entire purpose of the SDLC (CMMI type thing for software guys). The process is well defined internationally (in the engineering communities) and within various standards.

Gather Requirements > Investigate > Design > Code/Develop/(whatever) > Test > Build

Every step is iterative to the step before it. Without the step before, you cannot do the step after. Iterate using whatever model you'd like (RUP, RAD, Waterfall, etc.) ... the concept does not change.

You say the requirements are known ahead of time, but I would argue that no software project of a useful complexity has requirements that are set in stone.

A website project is still a software project, and accordingly it benefits from agile practices. Develop iteratively, demonstrate working software to the customer every one or two weeks. Start with the minimum working product (not much more than a mock-up), and iteratively flesh out the missing functionality / content. Adapt to changing requirements, and enable the customer to decide what to build while you're building it. Avoid "production line" processes and encourage close collaboration and shared responsibility between team members instead. There's a free e-book that explains scrum practices.

In a scrum-style project you won't be building any of the different technical layers first. You'll build in-depth, delivering one working feature from the top to the bottom, and then moving on to the next (where the next feature might be a revised version of a previous feature). There is therefore no right answer on what to do first, front-end or back-end, because this might change from sprint to sprint and feature to feature.