A Few Words On Convention Web Sites

Previous: Echoes | Picofarad #14 contents | Next: Days of Yore

I've been meaning to write this for some time. This article was originally conceived as a light-hearted look at how to make your Web site worse than you ever thought possible, and later as a rant about Web sites which actually are worse than you might ever have thought possible. But I've calmed down now. So what we're going to do here is have a sober, straightforward talk about Web design. We'll start with the basics, look over the possibilities inherent in more advanced technology, and wind up with a few resources to help you learn more.

Hang on, say those of you reading this on the minimalist Picofarad Web site, who are you to be talking about advanced Web design? Picofarad is an obscure amateur publication, and has a site appropriate for one. Your convention obviously needs something grander, so don't worry, I won't be telling you to create one that looks like mine.


The first question in writing is: Who is the audience you're writing for? Your visitors are likely to be sf fans, interested in hanging out with other sf fans. Some don't know who you are, but could be talked into giving you their money, or at least some free publicity, if you convince them you're worth it. Others will be members of your convention looking for information.

In con-running discussions, you hear a lot about how people are idiots, people are deliberately obtuse, people are hostile, people don't know what's good for them. And a certain degree of pessimism is needed in many areas of con-running, in order to anticipate possible problems and have a plan for dealing with them. However, to create a good Web site, you must start with the assumption that your would-be readers are reasonably intelligent people, worthy of being treated with respect, and capable of accepting your help. If you take the attitude that people are difficult and simply need to be managed, that will carry over to your design. If you truly can't let go of it, then please pass this article on to your successor, because nothing else I say will be any help.

Stuff you get for free

Let's start by looking at the merits of being a little lazy. HTML was originally conceived as a way of describing information without forcing a particular graphical representation on it. Because of this, Web browsers will do a lot of your work for you if you let them, including:

Some basics

But hardly anyone wants to leave things on default settings anymore, so let's look at some ways to not screw this stuff up.

Platform independence

You can't anticipate what browser, operating system, or hardware your visitors will show up with, and that goes double for an intensively techno-savvy population like fandom. Try to keep in mind the limits your design decisions place on who can use your site, and don't stick a sign on the front telling people to use your favorite browser, display settings, or system. What you see as gentle evangelism will like as not be taken as "Your kind aren't welcome here." (Penguicon, which is a Linux revival first and a science fiction convention second, is exempt from this rule.)


Why does every publisher in the world want manuscripts submitted in black text on a white background, using a font with serifs? For the sake of the people who have to spend all day reading them--that's the combination that's easiest on the eye. Have some consideration for your readers, and keep your basic text high-contrast and readable. This doesn't mean you can't get all nifty and colorful with your headers or your menu items. (In fact, this'll help them stand out more.)

Don't set a literal text size, however. What looks reasonable at your resolution may become unreadable on someone's 52" ultra-high-definition screen, or ridiculous for the person still working at 800x600, and besides, some browsers now have the option to override text size settings altogether. If your page-creating program insists that you have to specify a size, use relative ones like small, medium, and so forth.


The World Wide Web Consortium has, as part of its accessibility guidelines, an equation to say whether your contrast is sufficient to be readable. (We'll cover a couple tools that can help you with this in the resources section.) However, there is no hard-and-fast rule, no helpful guideline that can give you a guarantee against choosing a really ugly color combination. All I can suggest is that you go to a trusted and honest friend with a modicum of artistic sense, and show them your site. If they grimace, go back and pick new colors. Alternatively, just find a site you like and copy their colors. And remember, no matter how frustrating it may get, taking color out of it entirely won't save you. (Don't think it's possible to be ugly in grayscale? Check out the Citizendium Web site sometime.)


Jakob Nielsen's first law of the Web says, "People spend most of their time on other Web sites." That is, they arrive at your site used to dealing with a de facto standard interface, and anything you do to mess with it is likely to just annoy them.

What's the standard? Something at the top to tell you what site you're at. A menu arranged either horizontally below that or vertically along the left side (but, please, not menus in both places). The center of the page given over to whatever the page is about, and sometimes stuff in a right-hand column that can be safely ignored if they feel like it. Visitors may also be used to important information like how to get in touch being hidden at the bottom in tiny tiny text, but it can't hurt to make their lives easier by putting it in your regular menu.

There are a variety of opinions about how long a page should be--but generally, it should be about one topic, and be only as long as it needs to be to cover that one topic. Page width should be left alone to adjust to the size of a browser window. Like text, if you try to pick one size for everyone, it will wind up looking wrong for practically everyone except you.

The front page

The front page of your site is where people arrive when they've clicked a link after reading a little about your convention. They know you exist, probably what sort of convention you've got, and they want to know more. Don't greet them with a closed door!

Many sites start with a splash page--usually a great big image featuring the name of the con on top of some fancy art. But when is it, where is it, how do you register? Well, you have to click through to the real front page, which tells you the name of the con again, and didn't I just say your visitors already knew that anyway? Drop the splash page, and let them walk right in.

Things that should be on your front page:

For those of you who think these are no-brainers, and would like a break from all this hectoring, let's stop for a little test. All five of the following sites seem to have been constructed intelligent people who are in the loop with their event committees. Try and figure out where (the correct city will do) and when each gathering will be held. Answers will be given later.

1) http://nationalww2museum.blogspot.com/ (Note: the dates were made visible on the front page just before this went to press, but see if you can find what used to be the only place they were listed)
2) http://www.derleth.org/wwf04.htm
3) http://www.cangames.ca/
4) http://www.kajonk-a-con.com/


Other people will arrive at your site via search engines. They may arrive at any page. The first question in finding your way around is, "Where am I, to begin with?" There are a couple ways to do this. One is "breadcrumbs", which show the specific path from the front page to the one you're at. They usually assume a form like "Top > Category > Page Title". Another, if you have a small number of pages, is to highlight the menu item you would pick to arrive at the page.

A popular solution that combines both of these ideas is to use a menu in the left-hand column, and show the sub-items for whatever menu category the page falls under, highlighting the particular sub-item that leads to that page.

More on menus: Use a consistent color, typeface, etc. for every item in your menu, so they can be identified as a visual group. Don't leave non- operative placeholders in there--either remove them, or provide a basic page to link to that explains the information will be there later. Otherwise you will drive people nuts wondering what will work and what won't.

Don't put too many top-level categories in your menu. The more you have, the more likely that someone will miss the one they're looking for, or wind up wondering which is the correct one--will you find the Hugo ceremony starting time faster by clicking "Hugo Awards", or "Events"? (And in the worst case, maybe only one or the other leads to that information at all.)

The usual objection to this is that if you don't put hotlinks to absolutely everything in the menu, people will complain that the information they're looking for clearly isn't on the site. Well, it could be that they're idiots, or it could be that your menu is poorly organized. But never mind. In this one case, there is a magic bullet for all your problems, whatever they may be. It's called: Search!

Place a text box and a button labeled "Search"--if there is one place you absolutely don't want to get cute, it's here--after the top banner, but before the menu. Now, search algorithms are very, very hard to get right, but you don't have to worry about doing that. If you go to practically any major search engine and look under their "Site Search" section, you will find a tool that will write the HTML code for you to run searches on your site via their engine. (Google is the odd exception, preferring to steer you to a paid "search appliance".) Plug that into your site, and the labors of thousands of hard-working engineers are yours to command.

With a search box, it doesn't matter if your menu is unreadable, incomprehensible, or poorly linked. As long as your pages have the right keywords, they're findable.

Advanced tools

This being the future, we have all sorts of goshwow advanced technology to pump up our sites with. But remember that every tool can be used for good, or for evil.


Here are the uses of JavaScript on the Web:

1) Serving up ads
2) Tarting up Web pages with annoying flashing and moving widgets
3) Serving up malware silently
4) Doing things which could have been done with a simple HTML tag instead
5) Adding useful functionality to a site (rare)

#1-#3 are the reason a significant percentage of your users will have JavaScript turned off by default. #4 is the cause of a lot of frustration on the part of these people. Never mind if you can draw a prettier button with that JavaScript code, just use the HTML. Period.

But there are occasional legitimate uses. If you have a terrific application that will be useful to a lot of your members, and if there is absolutely no way to implement it, then go ahead. Just don't force everyone to use it in order to attend, and don't demand that everyone turn JavaScript on the instant they reach your front page. Instead, gently request it when they get to the area where the application is. Also, having everything hosted under the same domain as your Web site will help increase the trust level.


Blogs are an incredibly useful tool for communicating news and updates. Blogs are not necessarily so hot for other areas of your site. Using a blog system as the platform for your entire site can have results ranging from awkward to downright silly. When the top item on your front page is the list of GoHs, great. But then a few months go by, and the buzz is building, and lots more people are checking out your site, and the first thing they read is that someone left a pair of glasses behind at the last staff meeting, because the GoH post is buried down at the bottom of the archive.

One Orycon, the people doing the site, who will not be named-- primarily because no one kept the software up and the spot where the information should be now displays "Page not found"--put it all on a blogging platform, which put comment links at the bottom of each page. Fine for news, but a bit jarring on, say, the committee list. Worse, the comment links didn't actually let you comment. (Unless, presumably, you were logged in via the form prominently displayed on each page, but there was no way to register.) Don't put something that looks interesting on your page and then make it impossible to use; you'd think people would just give up and ignore it, but usability studies show that they will obsess over trying to get it to work.

On the other hand, it's possible to do worse than giving your entire site over to blogging; check out the current site of Autumn Dream (an anime convention) at http://autumn-dream.com/. For those of you reading this in print without a browser handy, the entire site is built on an e-commerce platform, which is intended to do nothing more than sell people things. Nearly every page with information has to be phrased in the form of a product.


Did I say something about every tool being usable for good? I misspoke. Flash transforms your site into a wad of binary data which is unreadable by Google or whatever your favorite search site is. This alone can be the kiss of death. Flash forces you to reinvent everything from scratch, and tempts you to do it badly. (Remember what I said about scrollbars?) Flash is incompatible with screen readers, non-broadband connections, hardware below a certain performance level, and many of the interesting platforms which your tech-heavy audience loves. Just say no to Flash.


The last step before you go live is to test your site on a few unsuspecting volunteers who not part of your inner circle convention planners. This may seem redundant. After all, aren't you a fan yourself? Don't you know how your community thinks? Why should you need to ask another fan to validate what you have set up with care for the wide variety of software platforms out there, and rigorous attention to every possible thing people might need to know?

Because you are not your readers. You bring in unspoken, even unknown assumptions which will not make themselves clear until you see someone else struggling with what you thought was obvious. There's no way around it. You can't see your own blind spots. And to show that no one else can see theirs, let's look at the answers to the quiz.

1) Well, obviously, it's at the National World War II Museum. Great. Which nation, again? There's no link for the hotel or venue, the traditional way to find that sort of thing out. Find the registration link on the right side, and click that. Clearly, you're supposed to decide whether you want to go before you know when it is. Click through to the hotel Web site, then scroll all the way down to the bottom and squint at the tiny text for the address.

2) Dates are easy, but note that further up, the festival is scheduled for "the weekend of TBA". The specific venue actually is not listed, but between the "About the ADS" page and the galleries of previous festivals, you can formulate a reasonable guess as to which city it's in.

3) Uh-oh, a splash page! All right, it's forgivable in this case, because it's actually serving a purpose. Click through for the dates. For the location, select "Attendees" in the menu and then "Location" from the page text. It's at the Rideau Curling Club! Further down, there's a map... but what city is it a map of? There's a mention of a local transit system, but is it that specific city, or somewhere in its metropolitan area? You will have to go to your favorite mapping site and try to come up with something that matches the map given here to make sure of where it is.

4) Beautiful, elegant site. Handy search box. So where is this convention? Click "Hotels", and you are not given a list of hotels, but an off-site link to a JavaScript-intensive application that gives you a list of hotels which are in the vicinity of the convention, which might be at the street address given in the "Search Settings" section, or that might just be an address nearby that they had to use to make the application work right. The venue is only mentioned by name in an almost accidental manner on the "Travel" page.

And the dates? Click "Volunteers", then download the Word document. Scroll down to where it asks about availability on specific days--and the writer has helpfully included reminders of which exact dates "Friday", "Saturday", and "Sunday" are.

If people with this level of obvious expertise can screw up this badly, so can you. Test it! Or at least be ready to take constructive criticism when you reveal your new site to the world.

After the con

Doing more work on your Web site is probably the last thing you want to think about when the con is finally over. But there are a couple little things you can do to vastly improve the experience of visiting it from then on out. The first thing is to provide some kind of information about the next iteration of the con, ideally a link to its Web site. This is especially important if this site is for a travelling convention such as Worldcon and Eurocon, where the next one will have a different name, dates, and maybe even be held at a totally different time of year. Otherwise, many people will just assume the next one is in roughly the same place and time next year, and you'll wind up getting puzzled inquiries about when the information for the next convention is after a while.

The other thing is to make sure it's archived gracefully. Even though the event is over and done with, a continuing online presence con serve everyone from curious fact-checkers to attendees reliving their memories. If your site is for a regularly scheduled regional convention, don't underestimate the benefit you can get from the emotional effect of keeping the past readily available.

Remember about the Orycon whose information is lost? If you're using something which dynamically generates Web pages, try to convert them to flat form when that part of your site goes inactive.


All right, that was probably as much lecturing as you can stand, so here are a few sites for further reading and exploration:

The Colour Contrast Analyser (http://juicystudio.com/services/colourcontrast.php) lets you check pairs of colors against the W3C algorithm to see if they contrast sufficiently.

BrowserCam (http://www.browsercam.com/) lets you see what your site looks like in all sorts of different browsers.

Alertbox (http://www.useit.com/alertbox/) is Jakob Nielsen's biweekly column on Web design.

Web Pages That Suck (http://www.webpagesthatsuck.com/) is dedicated to learning what works on the Web by examining what doesn't. It features the Daily Sucker, an ongoing log of truly horrendous design, helpful checklists you can use to tell if your site sucks, and lists of more resources.

Happy designing!

Previous: Echoes | Picofarad #14 contents | Next: Days of Yore

Picofarad home