Why a website?

What are you trying to achieve in becoming a website owner? This is a question that most people don’t ask, consequently few websites have any tangible goals. If you can’t answer this question, it’s probably time to quit.

Who are your target audience?

Should you decide to go ahead, there’s nothing wrong with catching the eye of casual surfers, but it makes sense to have an idea of the type of visitor you’d like to attract.

This’ll help you decide what information needs to form the core of the website, remember, content is king.

What do you expect them to do?

There’s been quite a lot written recently on the ‘Call to Action’.

Your goals, remember the first step, will tell you what action you’d like visitors to take, but you need to decide how to structure the site to take them in the right direction.

What’s their motivation for investigating your website?

There are a huge number of websites on the Internet, and some of them will offer the same thing as you’re site, so what’s going to differentiate your website from these others?

Knowing your audience helps when creating an effective marketing campaign to accompany the site launch: where to advertise and how.

Why will they come back?

Your content is undoubtedly fabulous, and a sound foundation, but how is it structured and presented? If your hard won readership can’t find what they’re looking for, they’ll go somewhere else, and are unlikely to come back.

You’ve got to commit to regularly providing something new and of value to your visitors. This is seriously time consuming, and if you’re unwilling, or unable to make this commitment it’s your last chance to back out of the website game.

Still interested? Next time it’s time to start building the website.

How much of the project to attempt to tackle? Sticking to the Agile principles of releasing little and often, I decided that jumping in with a full blogging or CMS would be a mistake. Limiting things to HTML and CSS, with the portfolio displays enhanced with Lightbox, provides more control over the design.

This is especially important when starting out, and I’m not expecting the design to remain static. Once established, adding more functionality, or moving to a WordPress theme will be a much easier task. I feel that the website is the simplest thing that could work.

I’ve always found that the experimentation the most effective way to investigate new ideas, whether methodologies or technology. Frequently, these experiments — prototypes if you prefer — are also the best demonstration of innovative ideas to everyone else.

This conflicts with the avoidance of working for nothing. All this leads me to conclude that the correct approach depends on personality and the application.

My preferences are to follow my interests and keep prototyping. Why… because I’d do it in any case, just to satisfy my own curiosity. It would seem sensible to make use of this effort, but how?

Free access to a web application provides valuable user feedback and data on server performance. Whilst the rights to the software may be retained, running the application comes at a price. Server and network resources are necessary, but often the greatest cost is the man hours required to implement any software solution.

Website graphic designs requested during the bidding process is often a relatively finished product, open to misuse and varied personal tastes. This type of speculative work is best avoided. It’s too easy to burn time whilst gaining little interesting experience; graphic design at the mercy of personal tastes.

Software, including client-side scripting, comprises a range of different behaviours, and the best way to communicate functionality is with a working example. For me, this is where the ‘fun’ is to be found. Few clients would express personal tastes in code and the feedback on functionality can be very enlightening.

This raises the critical question: What price do I put on my time? The answer is not constant, depending on what I’m doing. In my opinion, fun can compensate for a reduced income. The less enjoyable the activity, the higher the price. I always consider this when deciding how to spend my time on a project. The meaning of the term ‘free’ is not confined to my finances.

The first is “The Art of Agile Development” by James Shore and Shane Warden. I’ve been introduced to agile development methods in one of my Open University courses, but this is the first detailed description of the practices adopted by agile teams.

The second tome is “Transcending CSS” by Andy Clarke, which I must confess I was unsure about when I asked for it. I needn’t have worried, this is the best web design book I’ve yet read. I’ve learned a lot about the finer points of CSS positioning and Andy’s semantic approach to mark-up gels well with my interest in the XML in general.

The most exciting common factor concerns the topic of prototyping. It seems to me that approaching the whole application — from the persistence to presentation — with feature targeted development and frequent, early prototyping makes good sense. If nothing else this agile approach fills me with enthusiasm, and that may be half the battle.

I intend to introduce test driven development to my coding. Ruby on Rails and Java make good provision for this within their frameworks. PHP lags these two, and guess which I need to use in my next job? All is not lost though, I’ve discovered a test framework called SimpleTest, which is modelled on JUnit, and I’m going to give it a go.

I’m also investigating build, testing and deployment automation. Java provides the excellent Ant; a tool I’ve used to a limited extent in the past. Ant can turn it’s hand to just about any task that might need automating, but needs Java installed on the server. Unfortunately, this is something a minimal CentOS 5 server installation doesn’t possess, a little research and reconfiguration solved that problem.

Ruby has given rise to a deployment automation tool called Capistrano. I haven’t any experience with Capistrano, but most report it to be very powerful and flexible. There are a number of articles on the Web detailing it’s use for deploying both Ruby and PHP applications. I’ll be giving this a go as well, but initially only with Ruby on Rails.

I also want to try working much closer with clients using the user story, feature driven and iterative approach. The aforementioned rapid prototyping is a key feature, required to assist communication and control the direction of development.

This extends to the presentation layer in the form of XHTML prototypes, using semantic mark-up of the featured content with very little styling. Semantic mark-up and a systematic descriptive naming scheme should allow the design to be applied largely independently.

Will it all work? I hope so, but the motivation alone is appreciated.