Sorcerer's Tower

Make it usable, make it usable, make it usable, then add water

That being my answer to the question, "How does one build a website effectively?"

So, let's examine what I mean by it...


1. Make it usable:

This first stage is about building the core functionality - creating each feature of the site and making everything work at the most basic level.

It involves three parts: the database, the server, the client; each of these has its own language: SQL, CFML*, HTML.
(*or whatever language you prefer)

At this stage, you should use nothing other than these three layers/languages — you are building just the basic functionality, nothing more.


2. Make it usable:

After you've made things actually work, you need to make them usable from a visual perspective — the default interface presented by HTML is stark, uninteresting, and not particularly usable for most people.

This is the stage where you hit your graphics editor(s) of choice and start creating pretties, followed by producing the stylesheets to tie these images into the existing code.

Again, you are doing nothing except making things look nice. For which you'll have two technologies: PNG for the images, CSS for the stylesheets. All you're doing is taking what is already there and making it look better.


3. Make it usable:

This third stage is about going beyond static usability, and producing usability that reacts to the user. It's about breaking out of the page mentality and producing dynamic free–flowing interfaces that work with the user. Instant feedback, context–based options, interface preferences, and so on.

There's been a lot of buzz recently, centering around the tacky buzzword of 'ajax', which is allowing people to begin to comprehend the concept and power of reactive interfaces, but it is important to understand that there is more to it than simple asynchronous commands — it's also about putting the user in control, giving them the power, and allowing them to be comfortable with using it.

And at this stage, the current main technology you'll use is called JavaScript. However, unlike previous stages, you can't rely exclusively on it — you will need to interact with the previous languages (HTML,CSS,CFML/etc) in order to implement the new features to the interface — the better job you have done in the first stage, the easier this will be.


4. Then add water:

Ok, so you might have a wonderful interface that allows for beautiful interaction, but it's all meaningless if you don't have the most important part of any website: content.

If you don't have content, you don't have a website (you just have a fancy interface).

Content is important for several reasons. Most importantly, it gives your site a purpose — a reason to live. Without a purpose, why will people visit your site? Without content, how will they /find/ your site? Content is what search engines index, and search engines are the most common method of finding websites.

So, to give your website hits, create content. And if you want a consistant userbase, create fresh content.



And that's my brief guide to effective website building — but its not the end of this entry!

You're getting two for the price of one here, because I'm now going to take a step backwards and give a guide on how to create a website effectively.

What? Didn't I just do that?

Nope. The above explains building a website, but creating a website involves a lot more than just whacking out a bit of code. Before you can start building a website, there are a number of things you should do, and after you've built it, there are a few more.

So, here is my guide to effective website creation:


1. Identify a need.

As mentioned above, there's no point creating a website that has no purpose. And if there's no need to create a website for something, then you have to ask yourself what is the point.

Don't re–invent the wheel, unless you've got something to add to the wheel to make it better.


2. Plan the content.

It's all very well saying "there are no websites explaining how to skin a cat, so I'll make one" unless you know how to skin a cat, and how to explain how to skin a cat, and how to usefully put all this into a suitable format for a website.

And it's not enough to simply plot out vague descriptions of what you're going to do: you must be able to definitely and clearly define a purpose to each part of a site, and be certain that you have enough content to fill each section.


3. Plan the interface.

Once you're comfortable that you've got good content, you need to get an idea of how to effectively lay it out in a way that will allow people to get at that content. Whilst you shouldn't at this stage be producing the 'real' interface, you should certainly not be scared of creating simple prototypes to experiment with ideas.


4. Feedback.

Depending on why and who you're creating the website for, you may at this point want to seek feedback from appropriate people about what you're got so far, and to confirm what the precise functionality you need to produce is. Depending on the feedback received you may need to return to the previous steps to improve what you've done — but keep in mind, all that you have done so far is plans, ideas, and prototypes.


5. Build it.

Once you've got things properly planned out, (and if appropriate, signed off with your client), you are ready to start building.

You should know what's involved here, because it's what the first half of this entry is about, so I wont repeat myself.


6. Developer Testing.

Whilst a good developer will not make many mistakes, (and should be fixing the ones they do make as they go along), it's just plain stupid not to perform testing once everything is complete. If you are good enough not to have errors, this will prove it. And if you do have bugs, you can catch them before anyone else has to find out.

As well as simply going through and using the various features as a user would, you should consider setting up unit testing that concentrates on a single part, feeds in data, and compares actual output to expected output. The benefit of this is that it can usually be automated, so after any change you simply run a script and it performs a whole suite of tests that return success or failure.


7. User Testing.

Developers are usually sensible, they are capable of logical thought and tend to have some idea of what they are doing, even when in unfamiliar territory.

Users on the other hand, are often the opposite. They can act irrationally, do stupid things, and can be very unpredictable.

Which is why it is vital to have a set of users (covering the complete range of who your website might be aimed at) go through and test things: It is almost guaranteed that they will find problems. Not necessarily because of anything done wrongly, but simply because they'll act in unexpected ways.

If possible, it is also worth watching the users — because its far less time consuming than having them attempt to explain what they think they did if you can see them doing it.


8. Go Live.

After you've planned everything, built it, tested thoroughly, and ironed out any bugs, you're ready to launch your website. But if all that you plan to do is get a URL and upload a few files, your new website is unlikely to be very succesful. People need to know you have a new website, and so you need to tell them — precisely how you go about this will depend on what the website is for.

Firstly, you'll be want to tell the search engines. Google Webmaster Tools will allow you to do that with the most significant of the engines, and the others have similar tools. They don't tend to start indexing a site immediately though, which is why you want to let them know as soon as you can.

If you have friends or belong to a community, ask them for a mention in their news/announcements section, or for a weblog entry about it, or if you can post in their forums.

If your site is a business one, contact online magazines and ask them to review you.


9. Keep It Fresh.

Going live is only the beginning — once you have a new website you'll be wanting to monitor it: find out how people are reaching your site, what pages they're visiting, and so on. To keep your site successful, you want to react to this information and further cater for these users by producing fresh content which appeals to them, but whilst also being careful not to neglect your inflow of new users, so that you can continue to grow.



Okay, a bit longer than I expected, but there you have it: how to build and create a website effectively and succesfully ...I hope. This article comes from ten years experience and observations of creating websites, and all my websites so far have either failed, or not reached their full potential, I believe due to either missing out or mixing up the processes above. I'm currently using these methods as I'm working on my new website, and so by the summer we'll hopefully see if the guides are correct.

If you have any comments or questions, please do post them. :)

Posted:
20 February 2007, 21:33
Tags:
Accessibility
Web Development

There have been 4 comments.

Kola @ 2007-Feb-21 22:16
Sounds like a plan! Curious how your steps would differ for a web application (as opposed to a website). Also I think one point which needs emphasising which you touched on is the use of Ajax. In my mind the primary goal of Ajax should be to improve the user experience - not just by doing cool things or looking nice but by actually improving the usability of the site allowing the web to behave inline with what users expect - perhaps from a desktop application. However with the growth in web apps you could argue that users expectations of how they expect web apps at least to react has changed significantly over the past few years.
Peter @ 2007-Feb-22 21:36
I think there wouldn't be a large difference.
Content (if any) would be playing a different role, so those stages would likely be less significant.
I'd add a specific modelling stage for figuring out how the data will be stored and arranged, before creation stage 3, and probably fork building stage 1 into a significant database [sub]stage, and then I think it could work just as well with the various app concepts I'm thinking up.
Oh and I'd probably want to emphasise the planning/feedback more with a web app since it's likely more important/valuable.
It'd be interesting to do a study on what people expect in applications - and see how much similarities/differences they expect with a web app and desktop app.
Actually, it'd not only be interesting - it'd be useful for a couple of projects I'm planning to start soon (one of which I'm not going into details about yet, and the other one I'll hopefully be posting a blog entry on within the next week) so I think I'll start thinking up how I might do one. :)
Andrew @ 2007-Jun-03 07:54
Thanks man this was great it helped a lot!
Peter @ 2007-Jun-05 00:16
No problem, glad I could help. :)
Registered Members
If unregistered, leave blank.
If unregistered, leave blank.
Unregistered Guests
Identifies your comment
Not displayed publically. Allows new comment notifications, or for the blog owner to contact you.
Link your name back to your personal website.
Comment