Web Design Philosophy
Know what you want to communicate. This is so basic I'm embarrased to put it here. But I've had projects that have dragged on for a year, because the customer doesn't know what she wants (through no fault of mine, I can confidently assure you). Do we want advertising space? Do we want a warm fuzzy feeling? Do we want to communicate a "you're safe with us" tone?
Right tool for the right Job. Sure you can kill flies with a hammer. You can even water your plants with a hammer, if you ever manage to get your drunk elephant in your garden. But no one ever does that. Us programmers, we've seen many customers that want the latest most fun gimmicks, some of them great fun to code, some of them a real pain in the ... er... well some of them were a real pain. But many of them aren't even used today, because the customers didn't understand their web users. One of my clients wanted a chat room on their website, so their employees from other cities can communicate with them. I thought about it a while and asked (the vice-president as I found out later), "what's wrong with using the telephone?". Confused looks all across the meeting room. After about 30 seconds of whispering, one person helpfully suggested that between certain branches the cost of telephone calls is very high. I then suggested Skype, and that was that. No chat room. Right tool for the right job.
No tables please. What? No, I meant no tags in the HTML. Its not only difficult to manage tables if you want change the layout, even by a bit, in the future, but semantically it doesn't make sense. What do I mean? I mean that when machines (i.e. internet browsers, PDAs, handphones) read the HTML code, when they see a table, they expect a table of information, like sales statistics. They don't expect to see a another table, with another table in it, with nothing but a couple of spacer images, just so your text would line up with your logo (for example). This is very bad. Many WYSIWIG programs, like Dreamweaver do this. This is very bad. Tables should be tables, and be used for schedules, staticstics etc. Lists should be lists, and be used for menus etc. This has benefits in SEO too.
Don't make your users think. This is actually a title of a book web usability book. Make the decisions that your user is confronted with easy. Remember the paradox of choice. If your user expects a submit button at the bottom of the form (as most users do), please don't put it after the advertisements, just so that you can get a couple dollars more a month. Help direct the users attention to where you think it needs to go. Don't hide your crucial navigation in complicated flash movie of a forest where the links pop out of trees when you mouse over. If your external links are in red, please keep it red through out the site. Link text should be clear. Clicking on links are a big investment for your users. Help them feel sure that they won't have to use the back button so often.
Flash, Javascript, Java, Ajax, and other eye candies. Hmm.... tricky. I don't really have a philosophy for this. More like guidelines. Important stuff should always be in standard XHTML, like navigation, sign up forms. I have a love-hate relationship with Javascript. I generally use it for non-mission critical stuff. Java is a great language and tool, but over-powered for most web applications. Ajax is very important for the web. I try to use it where it doesn't compromise too much on SEO and usability. Flash is the future, but most flash developers are busy learning how do funky stuff than to actually concentrate on making user experience better.
