Web

(Extremely Brief) Introduction to Game Theory

For many situations, there are two variables — one which you control, and one which is controlled by the other "player;" this can be an opponent, a client, or random chance.

One of the classic game theory puzzles is that of the prisoner's dilemma. The situation is this: You and your best friend have been implicated in a crime, and the trial hasn't gone very well at all. It is clear that at least one of you performed the crime. The district attorney decides to give you both a plea-bargain, but separates you into two different rooms, and gives you both the same deal:

• If you both admit to it, you both serve 5 years in jail
• If you implicate the other one and he admits to it, you go free but the other one serves 20 years in jail
• If you both implicate each other, you serve 10 years in jail

So, what is the proper course of action? The best thing to do is to analyze all possible outcomes. We make a 2x2 table which examines the four possibilities:

The Prisoner's Dilemma

		Friend
		Admits guilt	Implicates you
You	Admit guilt	You serve 5 years Friend serves 5 years	You serve 20 years Friend goes free
	Implicate friend	You go free Friend serves 20 years	You serve 10 years Friend serves 10 years

So what does this tell you about the best course of action? Well, it depends on your point of view, but if you admit guilt, then you serve either 5 years or 20 years, but if you implicate your friend, you either go free or serve 10 years. (And, if you implicate your friend and you serve 10 years together, he'll probably kill you in a jailhouse riot or similar.)

So, from a global view it's probably best to just admit guilt (so you both only serve 5 years). Unfortunately, that good-for-nothing "friend" is just going to implicate you anyway. Feh. Which is why given the local view people implicate their friends instead and everyone serves 10 years.

How does this apply to web design?

Fortunately (or unfortunately, depending point of view), making a mistake in web design won't cause you to end up in jail (though you might be sued under any number of accessibility laws, as has happened to many prominent sites now). However, design mistakes can cause many other problems, such as lost visitors (which means lost customers, if it's a commercial site), inaccessible sites, and low search engine rankings, which leads further to lost visitors. Then you get fired for incompetence, don't get a good reference, can't find another job, end up on the streets, end up making friends with another homeless guy, then one of you goes and commits a crime and then we're all the way back to square one!

So anyway. There are a lot of site design mistakes which seem like a good idea at the time (well, they must if so many people commit them!), but really aren't.

When you read these examples, keep a totally open mind about which platform is being used — since some of these things still apply even to the people who happen to run whatever browser you think they're running.

Navigation

Opening links in a new window

There are a number of ways for links to be opened in a new window. For example, most browsers let you do some command to do this (for example, shift-click in IE/Windows, alt-click in Mozilla, and cmd-click in IE/Mac and Safari, and then there's always bringing up a context menu and selecting "open link in new window"). There are also ways of doing it from HTML itself, such as Javascript and target="_blank".

One of these choices is wrong.

How to open links in a new window

		User
		Wants link in new window	Doesn't want link in new window	Is using a text browser, cellphone, or PDA
You	Use target="_blank"	The user is happy	The user is pissed off	The user doesn't know better
	Use Javascript	The user is happy	The user is pissed off	The user can't browse your site
	Let the user decide	The user is happy	The user is happy	The user is happy

Conclusion: Don't make navigation links open in new windows automatically; let the user decide whether they want a new window.

Exception: Things which work better as a popup (for example, item details) can still go as a popup. Just don't make a popup for anything which has further navigation, and if you do use a Javascript link, do it as an onClick method and provide the canonical URL as the HREF parameter (so that non-Javascripty browsers can still follow the link).

Whether to use Javascript where it's not necessary (or VBScript at all)

Many sites seem to use cute DHTML and Javascript hacks for things like drop-down menus, which don't allow you to actually navigate should the particular DHTML not work correctly.

To make things worse, for some reason, a lot of sites, rather than using standard <a href="blah/blah/whee.html"> URLs do something utterly obnoxiously stupid: they use a Javascript function to replace the current URL with whichever one they're going to in various onClick handlers and so on. This has quite a few drawbacks:

• It requires Javascript
• It trips up search engines (if you want to avoid search engines spidering part of your site, use robots.txt)
• It's often browser-dependent

and it's just STUPID and WRONG and so DON'T DO IT but if you really want to see why not, here's a game chart anyway:

How to make links

		User
		Conforms to your expectations in every possible way	Doesn't have Javascript enabled (or uses a browser which isn't compatible with your code)	Is a search engine
You	Use Javascript	The user is happy	The user is pissed off	The user can't browse your site
	Use ordinary <A HREF>	The user is happy	The user is happy	The user is happy

Conclusion: Just use <A HREF>. It's there for a reason.

Link-spreading issues

Although the issues regarding frames have been done to death, people still use them. Maybe they won't if they read this table. (Though I have a feeling that the people who would be reading this table are the sorts who already know why these issues are bad.)

Note that this table also applies to overzealous use of sessions which time out (which is bad enough for e-commerce sites but why would you use dynamic page sessions for static information?!), Flash-based navigation, "Web 2.0" AJAX techniques, and pretty much anything else which prevents bookmarking (including "wrapper" framesets which might make your site look like it's got its own hosting but it's not fooling anyone).

The use of obnoxious technologies for navigation

		User
		Navigates to and within your site in the exact manner which you expect them to	Wants to bookmark a specific page or send a link to a friend	Arrives by search engine
You	Use frames	The user continues to be a complacent sheep	The user is pissed off	The user is pissed off
	Don't use frames	The user is happy	The user is happy	The user is happy

Conclusion: Don't use navigation strategies which prevent bookmarks or emailed links.

Exception: Unless it's something which makes no sense to bookmark, but in that case you should be using POST instead of GET methods anyway.

Formatting issues

Dynamic menus

Dynamic menus (using dropdowns, or DHTML, or auto-submitting forms, or whatever) are fine, as long as they actually work. Except that they're a horrible user interface mechanism which is fundamentally incompatible with the web display model, but that's besides the point. Oh, and people really hate things moving around on them, especially when things to way wrong.

Dynamic menus, anyone?

		User
		Uses the exact browser and input mechanism you expect	Uses a keyboard for navigation	Uses a browser which doesn't support your DHTML mechanism (or PDA, or cellphone, etc.)	Uses a browser which doesn't support CSS
You	Use Javascript/VBScript	The user continues to be a complacent sheep	The user is a bit upset	The user is pissed off	The user sees an ugly, and probably un-navigable, site
	Use CSS :hover tricks	The user has trouble with the nitty-gritty precise motions required	The user is a bit upset	The user still has trouble navigating the site	The user sees an ugly, but totally-navigable, site
	Use traditional static navigation menus	The user has no trouble whatsoever	The user has no trouble whatsoever	The user has no trouble whatsoever	The user has no trouble whatsoever

Conclusion: Don't use weird dynamic menus, which takes way more coding effort than the traditional static menus thing anyway.

Font sizing

There are two ways to do font sizes: absolute (in pixels or points) and relative (in percentages or using labels such as x-small).

There are two kinds of web user: those with better eyesight than you, and those with worse eyesight than you.

Do you want size with that?

		User
		Thinks your fonts are too big	Thinks your fonts are just right	Thinks your fonts are too small
You	Use all absolute sizes	The user wants to make the text smaller but can't	The user is fine	The user hates you and your good eyesight, and thinks you're a young whipper-snapper and then feels pathetic, useless, and obsolete
	Mix absolute and relative	The user wants to make the text smaller but only some of it shrinks	The user is fine	The user likes how some of the text changes size, but can't figure out why the text THEY want to change the size of doesn't
	Use all relative sizes	The user is fine	The user is fine	The user is fine

Conclusion: Use relative font sizes wherever possible.

Exception: You need a font to be a precise height (such as for fitting it alongside an image or something), and even then you should really consider if it's all that bad to have your text grow too big.

Note: Of all of the browsers I've seen, only IE adheres to absolute font sizes. This is one of the few cases where the advice actually applies specifically to the most popular browser — and in this case, it doesn't matter if you follow it or not for the other browsers.

Element sizes

Elements have three sizing methods: absolute (pixels, inches, etc.), parent-relative (percentage of the container's size), and font-relative (em- and ex-widths). In the CSS box model, there are a number of sizes to provide, including width, height, various margins, padding, indentation, and so on.

Although many situations call for a very specific absolute or parent-relative size, many other situations require font-relative sizes. For example, if you have a container which holds text, its width should be font-relative if possible, so that it can change size along with the text. This is especially important if it contains a table; for an extreme example, look at these two situations, and change your font size:

Can I super-size your order?

		User
		Thinks your fonts are too big	Thinks your fonts are just right	Thinks your fonts are too small
You	Use absolute or parent-relative sizes	The user shrinks the text, but the container ends up wasting space	The user is fine	The text overflows and refuses to fit
	Use font-relative	The user is fine	The user is fine	The user is fine

Conclusion: Use font-relative container widths wherever possible (especially if you're containing elements which are incapable of wrapping, such as tables or long words).

User Experience

Browser Detection

As a webdesigner, you may be tempted to employ some sort of browser detection to ensure that everyone using the site will be getting the appropriate web experience.

Don't do that.

Wherefore art thou Netscape 1.0?

		User
		Runs a browser you accept	Runs a browser you reject	Runs a browser you don't know about	Is a search engine
You	Detect server-side	The user is fine	The user can't view your site, but it's probably for the best if you don't believe in graceful degradation anyway	The user, who is probably running a browser way more capable than your minimum spec, gets pissed off because your code thinks they're running "an old version of Netscape"	Search engines index your "upgrade your browser" page — and nothing else.
	Detect client-side	Nothing wrong here...	The user has to turn off Javascript or whatever. No big deal though.	The user has to turn off Javascript or whatever. No big deal though.	Search engines don't interpret Javascript! Yay!
	Don't use browser detection	The user sees the site they were expecting	The formatting might be a bit wonky, but the site still works anyway. And you wanted to exclude because of THAT?	The user is happy to view the site even though it isn't the be-all end-all of all past, present, and future web technology	The content is indexed, and is searchable. How about that.