EYEHEARTZOMBIES

The company I work for hired a “web” development firm to build a new, more powerful web site about 2 years ago. The firm came in yesterday to demo to us the site and it’s accompanying backend. I won’t name any names. This is the most horrid example of application development I think I have ever seen.

The company I work for is a community newspaper. We publish six different papers each month. They go to doorsteps and businesses in the six surrounding communities. If you live in/near Tulsa, you’ve probably read one of our papers, or at least seen it in a restaurant newspaper rack. They’re free and they’re actually a pretty good paper; several color pages each month, a community calendar, and, if you care about the social elite in Tulsa, a lot of event photos. As a newspaper, we have a lot of content to get out. Articles with photos, articles without photos, photos without articles, advertisments (both for us and for clients), and, of course, information about ourselves–advertising and subscription rates, deadlines, delivery dates, and general company information. Also, there aren’t a lot of us (myself, my wife, the publisher/editor, the managing editor, a one-person sales staff/accountant, and a secretary of sorts). Of those who work directly with the content of the paper, only I know any HTML or CSS. My wife and the managing editor have some idea of how to use an FTP program. That’s it. It’s a very technologically-impaired office.

I have not been at this company since the contract was started for the web site. If I had been, I’m sure I would have just produced the site in-house and that would have been that. I came in late to the game and, as such, have gotten stuck with what’s been decided before me and what is to be delivered. Let me give a bit more background, though.

When I met with the company (we’ll call them Dev), their representatives showed me what had been done before (some templates/designs that my predecessor had built) and talked with me about what needed to come now. We talked about how no one in the office is very savvy when it comes to web technologies; how the office-side of the site needed to be as user-friendly as possible; how I could advance the site as needed at a later date, but it should start off pretty much perfect. I left the meeting feeling pretty good. I had promised to create a template for them.

After creating several templates, I finally had one to send them that the boss was happy with and that I didn’t loathe; most importantly, though, it worked in all major browsers. So I sent it to them and we waited.

A few weeks later, I get an email about a new meeting to further work out what the site needs to do. OK, I thought, no biggie. They’ll come over and I’ll just go through it again.

They came, we talked, things where drawn on the markerboard, notes were taken. They left and I felt it would all work out. This meeting had been primarily the backend of the site and I felt confident that I wouldn’t have to teach any old dogs any new tricks.

Some of the key points we brought up were that it would be a web-based interface. You copy & paste the story into a form, fill in a title and a byline and it generates a database entry with the story and other required bits (which paper(s) it’s in, how long it should run for, when it should start running, etc). There would also be a form to upload images and other accessory items (PDFs, video clips, whatever). This, I should point out, was against what Dev had wanted. Dev originally wanted us to just use a form to upload a PDF or a Word file and that would be the article. As anyone can see, that doesn’t work well for universal accessibility, much less screen-readers, translation services, and RSS feeds.

We get a working demo about a month later. When we log in to the admin site, it’s just a place to fill out details for an uploaded file: html file location, image location, cutline for image, tooltip (title to those of you who are HTML-savvy) for the image, headline, subhead, summary for the article, along with the article’s author’s name, email, phone and fax numbers, title, and web address. Also which paper it appears (as opposed to appearing in some mixture of the papers, say 3 out of 6) and what category of the paper and classification for the article (headline, feature, or standard). I’ve attached an image of the form.

This is the same form as in the newest version of the site. As far as I can tell, it’s main objective and accomplishment is to keep track of where an article is on the server. The server can do that on it’s own. The CMS should keep track of more information in a more controlled and useful way. This is just a bunch of runaround.

At the demo meeting, we explain that this is not the site we ordered, it doesn’t have the functionality we requested, and we’re frankly disappointed. They effectively say “It’s not our fault! We did what we were told!” (Even as it conflicted what was still written on the markerboard) And back to their office they went. A few days go by, the inform us that they don’t feel they can make the changes we brought up (the functionality that should have been there from the start) and still meet their cost demands, so we could either quit here or they’d take it to the finish they had planned and then give it to us. Apparently my boss decided to let them finish, because we now have a new “finished” product.

They sent the demo URL to me a couple of weeks ago. It was deadline time, so I didn’t get to check it out, but as soon as deadline was over, I opened it up. Within 10 minutes I had found a security bug; they left the $_GET array open–anyone who wanted to could stick in their own code. After a couple of phone calls and emails, they fixed it. I tried it again, and they had, but I’m not certain there aren’t other holes in the site.

In any case, Dev shows up yesterday (Wednesday, the 30th of June) to demo the site to us. They come in and proceed to show me the site. After they show it to me, they ask if I have any questions; I don’t, I’m choking on my own spit. They leave and I start to digest what I’ve been shown.

As I said, we publish 6 papers, once a month. That’s about 20–30 articles each month, not to mention photos that don’t have articles. The breakdown for adding an article to the site is something like this:
# Open up the article in QuarkXPress
# Open up a new HTML document in BBEdit
# Copy and paste the article text, including image cutlines, into the BBEdit document and apply appropriate HTML
# Upload the HTML file somewhere on the server
# Open up any images in Photoshop and resize appropriately
# Upload images to the server. Again, somewhere.
# Log on to the administration site and fill out the afformentioned form

I did one today. It took me an hour straight through. I’ve been doing web design for 8–9 years; I know what I’m doing. They’ve tried to say that this is a simple enough system for the other people in the office to use, people that have no idea what HTML is, much less how to FTP files to the server or give relative locations to files.

The whole point of this gigantic post isn’t to bitch and complain about the horrible product we were given; it’s not to claim that I’m better than them or that I wouldn’t have made any of the mistakes that were made. The point is that if you’re going to do something, do it well. Don’t promise things you can’t deliver.

I’ll write another post soon, a part two, explaining what I would have done differently. I’ll try to provide some pictures, so you won’t have to read so much.