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.


I’m currently the webmaster for the Keystone Capital Chorus, the Harrisburg, PA Chapter of the Barbershop Harmony Society.  Our website has been in existence in some shape or form since 1997, from a free host up to our current host.  There are few technophiles in our organization, so the content and design for the site has solely been up to me, and to be honest, being a hobby site, it hasn’t always been as high up on the priority list as it should be.  On a semi-regular basis (monthly or so), the site content would be updated, and from time to time a new design would be invoked at my whim.  Don’t get me wrong – for the purposes of our site, it has been pretty successful as it has helped us gain a 1/2 dozen or so new members over it’s lifetime.

Well, over the past year or so, our membership has been growing significantly as well as our level of technical proficiency.  I’m still the only web developer on the roster, but our members are the generation that make heavy use of Google, youTube, Flickr, etc.  And as our membership grows, so does our need to expand our use of technology to communicate, share files, advertise, etc.  As such, it’s become painfully obvious that our site needs to be more flexible and allow for more rapid content changes, and allow others to contribute to the content without my having to get directly involved.

With this being a hobby site, I’ve always worked on it at a whim.  It’s still pretty much a static site, though over the years, I’ve changed some of the site to be database driven, but it’s been that I’ve needed to manually update the database, then reupload it to the site to make the changes active.  Not a pretty solution, but it’s worked and I’ve just never taken the time to work out something better.

Well now, we’re moving at a much faster pace within the organization, and we need more and more information modified throughout the site.  Plus, my kids are now of an age at which I just do not have enough hours in the day for me to live up to the expectations I’m setting for myself in maintaining the content of the site.  Obviously, I’m feeling an obligation to keep our content fresh and relevant, but there just isn’t the time in my schedule to handle the needs of the masses, so I’m going to have to refresh the site to allow others to be able to keep the content up to date without having to get their hands dirty in html (did I mention the lack of technophiles?).

So what happens next?

You may be saying to yourself “This site just needs a content management system,” and while this is true, I’ve never been a person who’s been satisfied with using a square peg jammed through a round hole.  The site needs to be simple to use, easy to maintain, but also specialized for my core users – barbershoppers.  There are some very unique pieces of functionality this site will need to fulfill, and I won’t be satisfied having to just jam it in because it’s easy.

So instead, now comes a site refresh.  In the past, I’ve gone the “fly be the seat” approach with this site and just done it at a whim.  But I thought that using this blog would be a good way to document my whole process and see if by documenting it all out first, I can develop a new site faster and more complete.  This will allow me to develop requirements for functionality, content, design, administration, etc.  Hopefully, someone will eventually trip onto this site and actually find this exercise interesting and helpful.  If not, hopefully this will just help my thought process and save me some time and allow me one place to document where I am in the process and what I need to add, what order to add it in, etc.

I’ve never had a “formal” process for my development, so if nothing else, I can determine what works for me and what doesn’t.  If I even learn one thing from this process, I’ll consider it a success.

So stay tuned to the journey and we’ll see you along the way.




One response

20 09 2007
Anatomy of a Site Refresh III - Functionality analysis « Dave Maxwell’s Blog

[…] History: Intro / Part I / Part […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: