Holy cow. I thought I've seen in all, but I've never seen a website like this. When I volunteered to be Technology Manager for the Silicon Valley Open Studios program, I didn't realize that their site was in such dire straits. If you ever wanted a lesson in just about everything bad you could do in designing a website, this site can be your mascot:

1. No templating. The entire site is hard coded. Want to change the banner text? No problem! Just go to each and every single page and update the code! Sound like fun? No!
Lesson learned: Use templates for your banner, links, navigation, logo, sidebar, and just about everything else. I don't care if it's Movable Type templates, js includes, server side includes, etc. Just use something!

2. No centralized CSS file. Ugh. The CSS is embedded in each html file! While this is technically possible, it is just plain bad. Want to update the style of the text in your site? No Problem! Go into every single page and edit the css for that individual page. Double Ugh!
Lesson learned: Use a single CSS file (or set of files) to hold all of your styles. The just link them in the body.

3. No web standards. It's all tables! Argghhh!!!
Lesson learned: use webstandards. It's easier to read and code.

4. Image maps everywhere. Oh my God. Becky. Look at her site. It's just like, so BIG. Yeah. you head me. Image maps. It's like Tommy's first site circa 1995. And this site was done only 2 years ago! Ouch!
Lesson learned: NEVER USE IMAGE MAPS. Why? They're unmaintainable. Need to change something? Great! Download the file, fire up photoshop, edit the file, calculate the hotspots, yada yada...it's just bad. And talk about unsearchable. Google doesn't like image maps and neither should you.

5. Flat database. Yes...I've never actually witnessed one myself, but I've found the elusive flat file database that I was told scary stories about in college. The site's event and member registration system uses a flat file db system that is just plain not up to task for such things (and really...what is a flat db used for anyway?).
Lesson learned: Use something relational. SQL server or MySQL are bonuses. Why? because they're universal so it's easy to get help. Plus it's easier to make full fledge applications on them.

On top of that, the registration process is quite borked that even I'm having a difficult time resurrecting it. It seems to work like it did before, but some of the requests of the team may be a lot to ask given the current state of things.

I've suggested moving on to a CMS system like Civic Space Labs. I'm looking into the final bits and pieces to see if there are prebuilt modules to make the software do what we need, but so far it's the front runner. Anyway, the plan is to patch the holes in the current sinking ship (surprised it has stayed afloat this long) and go head first into deploying Civic Space. Wish me luck.

See for Yourself.