This is by no means a complete list: there are so many mistakes one can make in the process of designing and maintaining a website that listing them all would be a mistake in and of itself. These are a few general no-nos that I see all of the time when either taking over a previous job or helping someone else with their own mess.

Make it maintainable (KISS)

KISS: Keep It Simple, Stupid. I know some brilliant people out there that take I/O into heavy consideration when designing a web application thanks to a large background in computer science or computer engineering. Unfortunately, the PHP/ASP.NET/CFM/whatever code they’ve written for the server is an absolute mess.

Frequent user-agent sniffing, cramming uncommented code into as few lines as possible, unorganized function declarations and stupid stuff like variable variables in PHP all make it that much harder to go back and add (of fix) functionality in your web app/site later. Take it from someone who’s had to clean it all up.

Even though it works now and you’ve met your deadline, you’ll be pulling your hair out later trying to solve a problem or add something to it. This is a bigger problem for freelancers than teams, because they are the only ones looking at the in-progress code (before the point of no return has been crossed).

HTML Hell

Hi, welcome to the 21st century. Allow me to hop off my hoverboard to inform you of server-side scripting, quirks-mode and semantic markup.

The table-based, completely static 5-page HTML website (usually complete with JavaScript blink effects and marquees) is so 1995. We’ve evolved since then: semantic markup is not only prettier to maintain, but also has SEO and speed advantages I covered in an earlier article, “Two Birds, One Stone: Optimizing Your site In Both Speed And SEO“.

Every server-side scripting language has an include statement or “master page” feature in it. Use it. Having to change the nav bar in 25 static pages is unnecessary and stupid. And no, webmaster of 1994, frames are not an alternative, even if Digg and ow.ly are using them.

Using these will also have other effects for your website, including accessibility for a growing audience of mobile devices and backwards-compatibility. Quirks-mode makes a great alternative to a user-agent preprocessed website (if you’re hopefully using server-side scripting).

I’ve always been critical of Dreamweaver for the crap it injects into your site’s code (if using strictly the visual tool) and other nuisances. Coda and other similar web IDEs are great alternatives for code-editing. While the design of a site is the most important aspect, using a True Text Editor ™ is the ideal way of achieving this.

Security

An insecure web application might as well not exist. I run across more obvious security bugs in websites than I can believe, and many times my curiosity gets the best of me.

If your web application relies on HTTP GET statements, POST statements, or cookie values for sensitive information, then you violated this principle.

I see this type of URL all of the time in web apps: http://MyUnsecureWebsite.com/flawed.php?file=/var/www/default/MUW/file.inc&user=NotAHacker. And 9/10 times you can change the parameters around to get any file you choose; but as a good citizen, I must tell you to instead email the web master and inform them of this error than to try and exploit it.

And it doesn’t stop there – cookies, POST values, JavaScript/AJAX requests and other parameters are frequent violations of this rule. If your web application has even a 1% chance of being exploited, FIX IT. And always sanitize user input before processing it – SQL injections are SO 2005.

Lack of testing

We all hate supporting Internet Exploiter Explorer, but we have to. The same, unfortunately, is not done by newbie web designers in terms of non-IE support.

Just because it renders nice in one engine (Webkit, KHTML, Gecko, Trident etc.) doesn’t mean another will make it look the same, as most don’t realize. All those lame “best viewed with Internet Explorer with resolution …” captions tell me “This ‘webmaster’ has no idea what quality design is and should be shot”.

So test it, fix it (look into quirks mode) and please ALL of your users.

Client Issues

This doesn’t even fall under the design issues – a bad or flaky client can be more of a pain than the site itself (unless it is done right).

“I’ll pay you from the site’s income” or “The check must have been lost in the mail again, I’ll send another in a few months” are both signs that you need to run away from that client FAST.

Other signs are a history of going through webmasters like a knife through butter, long periods of no communication, constant “then I’ll sue” threats, and signs of “the never ending project”. Again: run away, and don’t look back.

Sometimes you have to put up with annoyances like the client who thinks they’re a webmaster, etc. but if they are too flaky or generally display bad signs or give you a bad gut feeling, then be wary about doing business with them.

Conclusion

While these aren’t all of the issues a webmaster can face when making a site, they are a few of the most common I see on a day-to-day basis. Choosing a comfortable language to write a site in, keeping it maintainable, having a stable client and keeping security in mind are all steps towards making a quality website for both you and the users.

You can choose to join the ranks that violate these crucial steps towards a better career, but be aware that doing so not only hurts your sites’ userbase, but it also has an impact on you – either directly or indirectly.