Anatomy of a Site Refresh III – Functionality analysis

20 09 2007

This is a whole series dedicated to a site refresh.  What steps do I take?  What plans do I make?  How can I learn from this process to improve my workflow?

Series History: Intro / Part I / Part II

I apologize for the gaps between postings.  I’ve been extra busy in real life – between reviewing and commenting on 100’s of pages of technical project documentation for a new project going on here at work, and coaching my son’s midget football team, and running the local barbershop chapter I’m currently serving as president, my days seem to get shorter and shorter in terms of having time to just sit and think.  My wife even got on my case because I didn’t take time to relax yesterday.  I think I may have forgotten how.  Not that anything’s an excuse – just an explanation.

Now, in our last episode, I did a quick rundown on the functionality the site needs.  For a quick recap, everything can be rooted down to four basic functional components: Read the rest of this entry »

Anatomy of a Site Refresh II – the “1000 foot view”

28 08 2007

Series History:
For initial background, see the Intro post.
See part one where the target audiences are identified and needs listed.

Now that the target audiences have been identified, let’s break down what is needed for the web site at a “1000 foot” view. This list is by no means complete, and will probably get updated from time to time:

  1. a calendar of events. Events need to be private and public, and mappable directions accessible where appropriate.
  2. rudimentary CONTENT management system. This needs to be able to create files on the fly, and files needs to be able to be uploaded, and accessed over a number of pages.
  3. CONTACT management – need to be able to add/edit/delete member information from a csv file
  4. a forum or some other sort of interactive application which will allow members to interact with each other, as well as interacting with members of the public.
  5. Group Management – to add/edit/delete quartets and their members.
  6. photo gallery
  7. mailing List management

Now, of course being the anal retentive I am, I will probably write most of this functionality by hand. Things like the forums I will use a pre-built (Snitz most likely), but other than that I will probably build it on the fly to ensure all the pieces work together as they need to effectively. More time consuming that way, but the only way to ensure that everything meshes together properly.

Anatomy of a Site Refresh Part I – Target Audience Identification

23 08 2007

Background – see the Intro post for the background behind this post and all within this theme.

The intro for this process was definitely long, so I’m going to try and break down the processes a little father to get these into reasonable length posts.

First step is to identify who fits into the target audience.  While the ideal is to identify one “niche” to target most of the efforts to, in the case of this site, there are actually five target audiences:

  1. Current Members
  2. Potential Members
  3. Potential Clients (Show Audiences/Booking Clients)
  4. Fans, Friends and Families
  5. Other Barbershoppers

Read the rest of this entry »

Anatomy of a Site Refresh – Intro

22 08 2007

Experiment time – read on if you’re interested.

Like most developers, most of the work I do involves other people in the development process.  I’ve got a customer who is involved in helping me to identify what’s required in a site, build content, etc.  This project I’m documenting here is a little different.

Read the rest of this entry »

Is the SDLC a thing of the past?

16 08 2007

It’s days like today that I start to wonder if I’m getting too old for this business….

 A thread started over at Sitepoint yesterday which started off innocently enough.  It asked which of these steps of the System Development Life Cycle is the least important:  Problem Definition, Software Specification,  Algorithm Design, Coding (Implementation), Documenting, Testing or Evaluation.  Seems like an innocent enough question, right?

Coming from an “old school” background (my first couple jobs were mainframe based) and having had the SDLC beaten into my head over the years, I answered the question as best I could – all things considered, Coding is the least important step of the SDLC.  If you define the problem and develop the specs and algorithms properly, coding becomes very easy.  You then need to test thoroughly, document it well (both for users and for developers who have to maintain your code later), and then evaluate what got accomplished to ensure you solved the problem.  All in all, coding is the least important step.

 Then someone piped in that this lifecycle was too restrictive and “real men do it iteratively.”  WTF? Read the rest of this entry »