The Codist

I get so tired of going to websites that provide interactivity and discovering they suck megatons. This is especially irritating in Fortune 500 companies (like Bell/AT&T/whatever they are called this week with yellowpages.com). None of this is rocket science, yet I am amazed at how companies with deep pockets manage to produce drecky sites. This is your public face, would you go on a date with mud on your face and spinach in your teeth?

At the risk of giving away all of my (not so secret) secrets, here are some useful things to do.

1. Put javascript and css in their place

Javascript and css should be kept in separate files and not embedded in your web pages. I don't care that your IDE can parse and syntax color 8 simultaneous languages in one file, it's hard to read, hard to debug, and brittle when there are multiple people editing the page. I'm ambivalent about adding event handlers upon loading instead of in the html itself but it's not a bad idea. If you want to avoid linking to files then include them in the html using your language or framework include feature.

2. Use compression

All web servers and browsers are capable of dealing with compressed content. Turn it on. It doesn't cost anything, saves bandwidth, makes dialup users happy and dogs wag their tails. You can save more by compressing your javascript files than by removing all the spaces manually. In any case it's easier to code something you can read.

3. If you put a DocType in your page, validate against it

Of all the things you find in the wide world of web, crappy HTML is by far the most common. Why put a DocType in every web page and then serve up invalid content? I always work in strict XHTML even though it isn't served up that way, simply so that I can be assured it's well written. It's a discipline thing. Use the web developers toolkit or Firebug and keep checking all the time. I don't care if IE 6 shows your site correctly. I bet IE7 doesn't. Who would buy a car that only ran on blacktop and not on concrete roads?

4. Don't air your dirty laundry in public

If your web application is properly tested (you do have QA right?) the end user should never see an error message. God forbid your code throws an exception and vomits all over the end user with debugging information. One site I went to threw a monkey wrench and then showed me a page full of every server and application level variable it could find, and then for good measure included them in a comment in the web page. I have also seen so many messages like "could not connect to database" and "timeout occurred reading database" I felt like visiting the competition. And usually did.

If you have to demonstrate poor QA and show an error page at least put it in context of the site and don't scare your customers with it. Architect your logging system to track problems and provide information to the programmers. Don't be like one employer I had who hid the logs from the developers out of some stupid security paranoia.

Whatever you do, don't include your test code and development comments in your web pages or javascript. yellowpages.com happily loads their unittest.js file on every page. Not that I want to test for them.

5. Use modern web design

Table based sites are so 19th century. Yet look around the web and see the fruits of old web design. CSS is your friend. Dreamweaver is your enemy. If your web designers are unable to build sites by hand using modern techniques and style with CSS then don't give them Dreamweaver until they can. There are millions of sites devoted to modern web design so there is no excuse to not learn how. If you can't write HTML by hand then reading the articles won't make an impression. Web design is programming + art. Accessibility, usability and maintainability are all made easy doing things the modern way and treating it as an engineering task.

6. Support all modern browsers

There aren't that many anyway. Other than IE6 and IE7 all the others are pretty similar. Saying you only support IE is stupid these days as there are two fairly different versions, with IE7 being somewhat closer to the others (yet screwed up in its own way). Code to the standards, adjust for IE6 and IE7.

Would you shop in a store that said "Whites Only!"? No, and I don't want to shop in an online store that says "IE only". Even worse are the places where they don't tell you you're not supported until the last minute. It's like going to a store and after filling up your cart, having the cashier tell you "we don't serve your kind here". Not real smart, telling customers to get lost. They will.

7. If your application has special needs, check up front

If you use javascript, flash, cookies, or something special (like a plugin) make sure you check on whatever the first page the customer sees and if you absolutely can't do anything with out it at least let the customer know up front. If you can work without it but have to degrade service either make it transparent or let them know what doesn't work. I don't want to have to explain your site to my mom.

8. Test your application usability with real users

It's amazing how many sites out there are so hard to operate. Sometimes I wonder if anyone other than the engineer actually used the site for its intended purpose. If you offer search, can anyone find useful stuff with it? Is your navigation clear? I went looking for some security hardware for my door and wound up at a Honeywell site, wherein I couldn't find anything useful and gave up after several fruitless moments. Then I went to their competition. Engineers, QA people, managers and the like are not users. If I can't find something I want on your site, then how will my mom?

9. Use a real database

Access is not a real database. Neither is Foxpro. If you can't afford (or don't want to buy) something like Oracle then use MySQL, or even better Postgres (or my personal favorite H2). Access is a toy. Would you drive a lawn mower on the highway? I've always been amazed at companies that have mission-critical information stored on someone's desktop in an Access database. And don't get me started on people who manage data using shared Excel spreadsheets.

10. Don't use platform specific functionality

ActiveX controls are the most evil things you can use. They lock you into a platform, and yet don't work easily in IE7 anyway. Just say no. If you have to Flash is always a better choice since it is available to most people.

11. Realize your customers don't all have T3 lines

An average directory page on amazon.com is around 350K and has 43 separate HTTP requests. Yikes. At least 20% (or more) of people in just the US still have dialup. One friend works by day on internet backbone switches and goes home where he has nothing but dialup available.

Compress, combine and cache were possible. I found that my biggest bandwidth hog was prototype.js. Once I compressed it and delivered it that way it almost vanished from the list. Just because I have a 6MB/sec cable line doesn't mean you aren't paying for it on your end. Most browsers only do 2 connections at a time so why make it hard on your customers and yourself.

12. Deal about accessibility and internationalization early

If your webstore or product site only caters to rock-climbing englishman, maybe you can get away with ignoring the needs of the disabled and those who speak other languages. Think about this before you build.

13. Test early, test often

You do test your web application? Testing should begin long before it's complete. Test the code, test the database, test the usability, test the environment and infrastructure. Test as if people would die if you didn't. Test as if your customers would all leave you if you fail (they will!). Test on all major browsers. On my Macbook Pro I can run IE6, IE7 (I need a bit more disk space), Firefox, Safari and Opera. I am sure a Fortune 500 company can afford more.

If you do all of these things then life will be good, people will love you, you will get rich and everyone will shower you with goodies.

Maybe yes, maybe no; but at least you can know your web application doesn't suck.