Useful Information Company

The Pragmatic Web

25 June 1999

Edd Dumbill edd@usefulinc.com

The recipe for successful web site development includes a large measure of common sense and pragmatism. Success comes when no element of a project dominates for its own sake.

This article examines the application of pragmatism in the following areas: design, usability, technical matters, project management. The target audience is those responsible for pulling together and running web project teams.

Matters of design

Despite common sense to the contrary, web sites are still being designed with all the bells and whistles, forcing users to download megabytes of plug-ins for the "enhanced experience".

The peril here is one that is evident in most aspects of web design: the domination of gadgetry. "Why are we doing this? Because we can!"

The downsides of the fat multimedia experience are pretty evident: large download times, need for plug-ins, increased build time, need for user to "discover" the navigation metaphor of one particular site.

Given these, why are sites like this still being built? An example is the new Channel 4 web site. Very pretty, but took over a minute to load and render (sorry, I went to sleep). Here are some suggestions as to why and how these beautiful monsters still get out:

Site build led by designers: It takes a balanced collection of skills and perspectives to craft a usable web site. If graphic designers dominate, however skilful or sensible they are, there is likely to be a tendency towards "wow" effects and away from practicality.

Companies have fast network connections: You would have thought it the most basic check to perform -- how does our site look over a modem? But an alarming number of sites are presented to execs over a fast connection, and are tailored to impress the customer in that situation. If offenders had to use their site daily over a modem, things might change.

Industry pressure: It is commonly supposed that software manufacturers add "bloat" to their programs (extra, largely useless, features) in order to propel the market for bigger and faster computers. There is some show of this effect on the web. Companies manufacturing either processors or multimedia technologies (Intel, for instance) offer sites money or advertising in order to use their multimedia technologies on their site. Also, one must always reckon with the "me-too" factor, where keeping up with the Joneses dominates sensible thinking.

It is perfectly possible to create beautiful web sites that strike exactly the right balance. You must bear in mind that it can often take more effort to design to a minimum specification, than to design the "all-singing-all-dancing" solution.

One may argue that larger bandwidth is just around the corner anyway, so why is this an issue? Assuming that this is the case (which it probably isn't in most parts of the world) then it is highly likely that designs will make another leap in heaviness and complexity, just to await the next increment in capacity. The problem's not a technical one, it's one of understanding and creativity.

Usability and information architecture concerns

Thanks to people like Jakob Nielsen, usability is getting a higher profile on the web, having been gaining footholds in conventional software design. This is great -- but companies must be wise in its implementation.

Usability is not a one-man show, it ought to be in the minds of all working on a site. Furthermore, it's not an add-on, it needs to be in the site build and design process from the beginning.

Implementing usability and information architecture within a web design firm can be difficult. The traditional dominance of graphic design needs to be broken, and other disciplines need to be introduced to the concept. Dull as it sounds, good librarianship is becoming a key to web site design and content architecture, along with other disciplines such as the study of human-computer interaction (HCI).

Nonetheless, a site designed by librarians might not be what you're aiming for in every aspect! Clearly, UI designers and information architects should be team members, not dominators.

Here are some common issues concerned with usability:

Audience: "Who is the audience?" ought to be the first question asked when designing a site. Often it is, but gets the wrong answer. Your boss is not the audience! A proper understanding of the needs and habits of your target users is essential. Educate your superiors about this and make a case for the user. Also beware buzzword vendors: it's one thing to claim to think about the user -- but is this backed up with any investigation or data?

Don't kill genius: A lot of the more successful web firms are where they are today because of key individuals. These people have intuition and talent to make the leap straight to what is needed. Don't let the pressure for method and research kill these people off, but recognise their existence. However, 95% of your staff will benefit from methodical usability work, as they haven't got the same genius as your 5% of "star-players". Additionally, it may be a mistake to have your star player in management, as they may not see the need for rigour in areas where their talent is sufficient for themselves.

Techie madness

From the very inception of the <BLINK> tag, feeping creaturism has been a danger in web design. Seriously speaking, tech-dominated projects can suffer from similar issues as design-dominated ones.

In fact, the similarity between designers and programmers needs to be recognised more (not seeing programmers as creatives can be a big mistake). They're brilliant, yes, and can be enthusiastically dedicated to the project, yes, but they may not see the whole picture.

The difficulty with allowing any creative to dominate is that when (as always happens) they need to be pulled back, there's a big risk of offence and ego-damage.

Hazards related to technical dominance include:

Gadgetry: Again, the risk of using the latest-greatest and losing a large proportion of audience exists. Advances in technology are great and ought to be used, but used where appropriate. For instance, you often see Java-based navigation panels where straight HTML would do, and work faster. Use appropriate technology for the job.

Language difficulty: Technical staff live in a world of jargon. It can be difficult to realise that the audience may not share that world: either in language or in metaphor. Wording on a web site is very important and as much attention needs to be paid to the one or two words of navigation or prompting as the latest article from some famous journalist. Also, ensure that your technical staff can speak the same language as the rest of your team members. If you need someone to act as "interpreter", get one. It's of vital importance to your team that there is mutual understanding.

Pulling the wool: Don't let your tech department have complete autonomy. Don't mistrust them either. Technical issues are a limiting factor on the web, true, but sometimes the issues can be clouded. Like everyone else, technical people can have an ego and pride. Important decisions like hosting, adoption of technologies etc. need to be brought out into the open. One of the hardest decisions to make is to go for an external alternative even when your tech team swears they can do the job.

Management

This is possibly the most difficult area to master in web site development, as on it all other factors hang. Even with the most skilled team members available, the management still has plenty of scope for completely destroying a project.

Much could be written about managing web teams, but I want to focus on those areas where pragmatic trade-offs are required.

Timescale and feature-set: Everybody wants to be first to launch with the best product. Practically nobody manages it. The key is to find the balance between depth of content (or feature-set) and launch date. Wait too long and you'll find your plans obsolete before you launch, such is the march of Internet time. Go too soon and the likelihood is your product won't have enough depth to escape the "So what?" reaction. Higher management will always pressure for both full features and a short development-time: web project managers need to protect both the product and the team.

There is no handbook: The new media industry moves very fast. Every project you undertake will likely be different. There is no one perfect way to do things. Sticking to some project management mantra will probably end up with you missing vital opportunities (and quite possibly annoying your staff). However it's also not the time to desert method and rigour. As with the technology: use as many management tools as are needed, and no more. Often a notebook, diary and email work just fine, combined with a good mind.

Understand the product: The need to understand what and for who you are building cannot be overstated. You'll need to take judgements as to whether an elegant, reusable, structurally beautiful system is required, or whether you need to lash together just enough to get things out in time. This is the perennial tension: your boss will want it all to be done in time, and probably isn't aware of long-term maintenance issues; your development team probably want to create a work of art, and aren't as focused on meeting the business or user need in time. You have to identify the right balance.

Don't get blinkered: Take advice, read around, borrow ideas, find parallels with other industries. The web itself may be new, but that's no reason to ignore a wealth of existing experience. Don't put yourself in a box: if you're from a technical background, find out more about business, content and design: and likewise if you're from a different background. But don't chase ideas for their own sake. Work to get your product done, and ensure you keep aside time for analysis and future innovation.

Keep your calm: Your competitors will launch, with fanfare, new ideas and new technologies. Vendors will tempt you with buzzword-laden brochures. Ensure you have the time in your working routine to analyse what is going on: is your competitor's new technology worthwhile, what are its strengths and weaknesses? You don't want to miss out on an essential move out of stubbornness, nor do you want to be jumped into a rash move by a jittery executive. Be flexible when it's required, but remember your course and what you've got planned.

In conclusion

This article has illustrated a few of the places where pragmatism is key in web site development. It can be summed up in ensuring you have a balanced, well-integrated team, a good knowledge of your product and market, and a good relationship with your managers.

I have not touched on many areas of web site development, in particular planning, and managing a team with multiple disciplines. Yet a pragmatic approach is the touchstone of web development: with a clear, balanced mind you will be better able to negotiate the challenges you face.

If you would like to respond to this article, then please email me at edd@usefulinc.com. I will post responses here with their author's permission.