ARCHIVE: Planning a web site

Overview
Planning before a website's implementation is very important. I have learned this the hard way. I wrote this document while planning my family website. This will be my second complete site redesign for this site that has been up for about five years. Although this is a fairly simple site the same planning process would apply to any site. The most important thing I have learned was that the lack of planning in the first two attempts significantly limited the end site. Many of the limitations, or headaches, could have easily been solved during the planning phase. I am not a programmer although I manage eight production web sites from e-commerce to purely informational to just for fun. Some of this may seem obvious to those with programming experience but for the do-it-yourself-ers I hope this will help get you started.

Requirements
Gathering requirements is key and really needs to be the first step in the Website implementation process. If you are like me it is also the hardest to force myself to do. On my last attempts once I had some idea about what I wanted I tried out a couple of CMSes and then loaded one and started adding content. This time is different. One thing about the requirements below to keep in mind is this is not a totally serial process. During each step I am continually adding to each proceeding step. As I go through the process more and more things come to mind.

The first thing I considered is: What will the website publish or do? For a store this might be selling products, handling RMAs, selling advertising space, or hosting forums about your products. You also need to think about things like: What languages will you site need to support? Will it need to be able to handle transaction processing? Will it need to talk to other sites? If it talks to other sites, what standards are out there that you will need to comply with? Do you need to secure access? Basically anything else you can think of that is important to how you want your site to function.

For my family site I came up with the following requirements: I need various people to be able to publish content. We need to be able to publish pictures, videos, audio clips, wish lists, blogs, and stories. We need a way to secure some of our content yet other content will be open to the Internet. We need a shared calendar that allows for event scheduling. We would like a place to document our genealogy. The site needs to be easy enough for my grandmother to use. None of the users are programmers so it needs to be easily deployed with a minimum of coding. We would like to easily change the look and the feel of the site during different seasons or whenever we feel like it. There is no income so I need to keep the costs down. The content needs to be easy to search. I need to be able to get the majority of the content out if I decide to restart again some day. We would like the ability to be able to comment on content. We would like the ability to have polls. We publish a bunch of pictures to it should be easy to publish pictures especially and keep them very organized.

The second thing I consider is: Who will be using the website? It is best to break your users into groups, even if a group will only have one person in it for now. This is especially important if there is any possibility for growth. The user groupings should be broken into functional groups that will change based on the site. For a store site you might have customers, site administrators, vendors, and your accountant.

For my family site I am able to break the users into the following
groups:

• Administrators – This group will have full control over
  the site. They will be able to change site layout. They will have
  control over user access controls.
• Family members – This group will contribute content.
  They will need to be able to update and upload content. Many of the
  users are not technical.
• Friends – This group will view all of the content but
  will not contribute content.
• Anonymous users – This group will be able to view some
  of the content but not all. They will not need to be able to update
  the content or provide comments.

The next thing I consider is: How will the content be accessed? What are some possible work flows? For a store I might want to make sure that I can link to vendors. I would want to make sure that vendors could update content but that I would have approval of any changes. I would want to make sure that putting an item on sale is access controlled. I would want my highest profit, best selling items right up front. I want to make sure a search works well enough to return just a handful of items.

For my family site I want easy and simple entry of content and simple viewing of content. The users inserting content are trusted so I would like for them to have options about where their content is published. I would like the users to handle the content so that I don't have to get involved every time someone adds or changes something. Users should have a way to pull up specific content easily. They should be able to sort by date, subject, category, and content type. Our current site ended up with a huge amount of unorganized content. It was a great site for current news or pictures but finding an old audio clip was next to impossible. It would be best if all the content could be organized using the same organizational structure. Our current site we ended up with a totally different sorting system and access method for each type of content since we used somewhat unrelated modules. The new one I want people to be able to pull all content types of a certain subject when they want to.

Based on what you are trying to do you could take this further but this was enough for me to use as a base set of requirements.

Evaluating CMSes and Modules
Now that I have an idea of what I want the system to do it was time to start looking at the options. Based on my budget and eagerness for a system that could be tailored to my needs GPL was obvious. I looked into all the popular CMSes and some not so popular ones. When it came down to it, for what I wanted Drupal was hands down the best choice. I could go through the others ones but I will skip to what I liked about Drupal. I really like the everything is a node idea. I also like the way taxonomy was implemented. From a work flow stand point those two parts made Drupal stand out above the rest. Not knowing the system I assumed it might take me a little more work to get it setup but in the end it would be a seamless website with the ability to eventually, if not immediately, meet all of my requirements.

Once I picked Drupal I spent a bunch of time looking at modules. There seems to be at least one module for everything I wanted that was not included in the base. I wrote down all of the possibilities and worked out in my head how it would all come together. I won't go through all of the modules here but basically this step was just a bunch of reading.

Testing Drupal and modules
Next I went right to setting up the site. I installed the Drupal base and just started playing. While I really like Drupal on virtual paper for me it was not final until I saw how it worked. I was pleasantly surprised. It took me a little while to really get the whole picture but once I did it all clicked. It was very slick and really was the seamless base I wanted.

I tried a ton of modules. Based on my requirements it was very important to me that everything worked with the base in a productive way. I did not want to end up having to pull up a picture in a different way than I had to pull up a video. I can't say I have everything i want but you can't always get everything you want and I did get much closer than expected. I ended up with image, image_pub, quotes, wishlist, video, and audio. I am still looking for a few odds and ends but for the most part I was able to get all of these installed and working.

Once I had this worked out I started working on taxonomy. For me this was the most difficult to decide and also the most important. Producing a ton of unusable content would have made the rest of this useless. Drupal has a bunch of articles on taxonomy which helped a bunch. I tried on paper a whole bunch of things and then would talk to he users. They would provide feedback and I would take another stab. Some of the items listed below may not be considered taxonomy because it is not set up as a category in Drupal but is already part of the system. Although this might still change some currently we have the following vocabulary:

• Subject – This would be the subject of the content. It
  could be one of the children, a house, my truck, or a project. Every
  node should have at least one subject and the ability to have
  multiple subjects.
• Subject Date – This will default to the submit date but
  it can be changed since many times content is added that is older
  media.
• Type – This is the node type (image, video, story,
  blog, ....
• Submitter – This is who submitted the content.
• Category – This is some more descriptive category
  (funny, news, woodworking, taekwondo, ...). Basically I expect this
  to grow as our hobbies change and develop but every node should have
  at least one category and the ability to have multiples.
• Submit Date – When the content was submitted.

After this, I put up a test site, got everything working, and had the real users have a go at it. Although I knew a little they are really the only ones that can make it break and have to use it. I administer the family site I rarely add any content. I will tell you that on first pass the site is much better than I expected. We have along way to go for the perfect site but the combination of Drupal and a good plan is a fantastic starting point.