Web Development. What's Your Approach?

Soldato
Joined
10 Dec 2003
Posts
6,348
I love developing sites and content for the web. I love how I can be highly pendantic about most details during the development, and get away with it. :D

But how do you approach a new project, once you've got the general overview of what the client has asked for? What are some of your first steps to actually sitting down and working?

This is generally how I like to do it.

Content First
The most frustrating thing for me, is developing a site first, then adding the content. Most of the time it just doesn't look like how you wished it would. So the first step I take is to think about the content, the order of the content and write up the HTML. I think about where to use tags such as <h1>, <h2>, etc.

Always making sure that everything is as spotless, clean and whitespace-less as I possibly can. To help avoid any errors in further steps.

Localisation/Internationalisation

This is a step that a lot of people don't take. That is, to understand that a site needs to meet the needs of not just the users, but to relate to the users surroundings, culture and even their expectations. E.g. If your site has a lot of Asian visitors, you must be aware that white is the colour of mourning in most parts of Asia, whilst in the west, it is black. Not just that, but the style of language, colour usage and many other things could potentially upset any visitor to a website.

Reset
Now that I have the site written in HTML, and the static content inserted, I then apply default CSS templates. The idea here is to try and reset every HTML tag to zero, in order to have the site look exactly the same across as many browsers and operating systems as possible. There are some great CSS Reset techniques out there. :)

Defaults!
Then in comes specific defaults for forms, lists, text, tables etc. This is the start of general Typography and element design really. All the while, making sure all techniques work cross-browser.

Strict to Dynamic
Strict content is all well and good but, if the site content will be dynamic, this is where I will add the required PHP scripting and/or Ajax (if required). Although, at this point, Ajax would only be used for dynamic content purposes, as opposed to visual effects.

Back to the CSS
Things start getting more 'visual' now, as I set about including little tweaks in the CSS for paddings, margins and general layout styles. Before I ever think about layout, though, I always settle on a final design beforehand by simply sketching out ideas on paper.

Last, 'Though Not Least
This is where I will enhance the layout, colour and feel of a site. Using images or flash (purely user experience) to make the site feel a lot better and modern. Ajax can be used at this point for visual effects but, generally, I don't like putting a boatload of Ajax into a website as it becomes more reliant on it - that isn't too good if a user has JavaScript disabled or they're using a mobile device or such.

Dusting Off
Then I will add company branding, and other finishing touches before presenting it to the client.

Doing all of this allows me to understand exactly how everything is working so, if the client wants some changes made, I know exactly where to go and what to do. I try to rely on images as little as possible; because any changes to the layout, design or colour scheme are a lot easier without them.

Maybe once a client has decided on a version he likes, I will then polish and refine it, before handing over the keys. :)

... and that's that, really. How about you? I thought it might be interesting to discuess and discover new and maybe unheard of approaches to Web Development.​
 
Agile, Scrum, and XP mish mash.

Firstly, ask the customer what is the absolute minimum they would accept as a working version of their site. i.e. if it's a service booking site, do they really need that weather widget etc. If it was a forum, the absolute minimum might be that you can post, and that's it. No sub fora etc.

Then ask them to prioritise the rest of the requirements. Ask them to explain what they want in the form of user stories e.g. "As a user I want to be able to login" or "As an administrator, I want to be able to ban other users"

Then progress from there. Work on a monthly or bi-monthly basis, and deliver what you have done since the last meeting/time so they can have a look. A lot of the time, they will change their mind from what they originally asked. They either don't want/need it anymore, or when in the flesh it's not as good as it sounds.

Oh, and always always always content, functionality, layout and design in that order.
 
Last edited:
Last, 'Though Not Least
This is where I will enhance the layout, colour and feel of a site. Using images or flash (purely user experience) to make the site feel a lot better and modern. Ajax can be used at this point for visual effects but, generally, I don't like putting a boatload of Ajax into a website as it becomes more reliant on it - that isn't too good if a user has JavaScript disabled or they're using a mobile device or such.

Don't wanna be nit picking but you're using the term Ajax incorrectly, Ajax is for asynchronous http communication with the server using xml. JavaScript is used for client side visual fancies.

My process? Well I don't relaly develop a lot of sites. I usually have an idea in my head of what it's going to look like - try it, and then decide on whether I like it. If not I scrap it and try a different approach.

Yes terribly inefficient, I know :p
 
Don't wanna be nit picking but you're using the term Ajax incorrectly, Ajax is for asynchronous http communication with the server using xml. JavaScript is used for client side visual fancies.

Yeh, I've made the same mistake twice, in as many days. Must remember FACTS! :p
 
Client says "I would like a ...." (it's really always that vague!). Based on experience, I can write a functional specification as to how I would make something. I then take this to the client and walk them through it. If there's anything missing, I make notes on the functionality, shoehorn it into the functional spec if I can, if not I rewrite and include. Go back to the client and confirm. Once confirmed, the spec is signed by both of us (REALLY important otherwise they come back and start trying to make changes to a development in progress!).

Once I have the finalised functional spec, I break it down even further to different aspects that will need to be developed, then those are broken down into classes that I'll need to write/incorporate and database design that needs to be done.

Next comes the 'orrible bit. Design. If I'm at work, I'll get some other lackie to do it, if not, I draw outlines of what each page will look like (no colours or anything, that comes last) and then create my templates.

Once templates are created, all the individual pages are created. Everything works without javascript out of the box. Then when it's all done, I go through and prettify it with javascript and ajax and all the colourful CSS-y stuff. Then it gets the ass tested out of it by muppets who haven't read the functional spec (:rolleyes:!), then bugs get addressed and fixed if they need to be, then it goes live, then I go home!
 
Back
Top Bottom