The Ideal Web Team (part 2)

By Peter-Paul Koch

In this column I’ll continue my investigation of the ideal Web team, which consists of three sub-teams:

1. The client-side specialists, who create an attractive, clear front end.
2. The server-side specialists, who create a smoothly operating back end.
3. The supporting specialists, who make sure that the other two sub-teams can do their jobs.

In the previous column, an ideal Web team consisted of no more than seven people with clearly defined responsibilities who constantly communicate with each other. The project manager held prime importance, while an overly active account manager might cause problems.

The focus of this column will be on server-side and client-side specialists.

Server-side specialists

Server-side specialists are responsible for the back end of the site. Since back end development may range from installing one simple FormMail script to creating extensive databases and applications that communicate with other databases and applications, this specialty can be the least important or the most important one in a Web project.

First of all, the team will have to select a server-side language. Will the applications be written in ASP, Perl, PHP, Java, ColdFusion, or another language? Although proponents of one language or another are quick to point out the advantages of their favorite and the disadvantages of other languages, in practice a server-side language is seldom selected because of these arguments.

Instead, the availability of competent programmers is the most important requirement. For instance, Java could be the best language for a certain job, but if your company only employs ASP programmers, choosing Java is not a good idea. Usually, ASP can do the job, too, though it might be less efficient.

Even more important than selecting a server-side language is a good, accurate, and definitive briefing. Nothing is as irritating and demotivating as a client (or a project manager) changing the briefing in the middle of the project. Changes in the front end of the site, though they’re very annoying, may be made with relative speed. Changes in the back end, especially in the database model, are much harder to implement and will lead to extended deadlines.

Client-side specialists

Since I’m a client-side programmer myself, the client-side specializations are the ones I’ve studied most thoroughly.

The client-side specializations are the most important of the three, since the primary goal of any Web site is to communicate with the users and create an smooth interface that allows them to perform certain tasks.

A project may have a perfect project manager and a superbly working database system, but if the interface is poorly designed, no one will use the site.

I defined four client-side disciplines, each of which is necessary for a properly functioning site:

1. Graphic design—What does the site look like? What look-and-feel and associations does it communicate?
2. Interaction design—Has the site been ordered logically? Is the navigation consistent? Can people find what they’re looking for?
3. Copywriting—How does the site present information? Is the text scannable? (People don’t read text; they scan it.) Is the text well written and filled with relevant hyperlinks?
4. Client-side programming—Do all effects and styles work? Is the site usable even with an ancient or rare user agent? Are any people excluded from the site?
   Client-side programming includes Flash, when necessary.

Any Web site depends heavily on the correct implementation of all of these four disciplines. If one is missing or insufficiently integrated with the other three, the site will never work.

In addition to the usual requirements, every client-side specialist has the extra responsibility to make absolutely sure that his or her own work interfaces correctly with the work of the other three. An interaction idea might be brilliant, but if it ignores basic browser compatibility facts or the design of the site, it will never work.

Job status

How do you prevent one of these four disciplines from being badly implemented? Obviously, you should start by getting qualified people on your team. At the moment, this is not really a problem with so many good Web designers and developers in search of a job. There is a catch, though.

Copywriting and especially graphic design are creative occupations, not only in the eyes of the writers and designers themselves, but also in the eyes of the outside world. Hence, these jobs have a high status.

Interaction design is not quite a creative occupation. However, it has inherited a scientific basis and methodology, though also a sometimes woolly tone of voice and a love for difficult words, from the science of psychology. These scientific associations give this job a high status, too.

But what about client-side programming? It doesn’t yet have the same status as the other three disciplines, making it more difficult to find competent client-side programmers than graphic or interaction designers or copywriters.

The client-side programmer (CSP)

When I started out back in 1998, CSP didn’t have any status to speak of. There were plenty of people programming HTML and JavaScript, and even some who experimented with the enigmatic CSS technology, but they were rarely accepted as full members of the Web team because they weren’t “creative.”

Predictably, this meant that graphic designers especially didn’t see the need for consultation with a client-side programmer about their designs, which led to serious problems that could only be solved by inserting lots of table cells and dramatically reducing CSP job satisfaction.

This, in turn, caused client-side programmers to apply for higher status jobs as soon as possible, which resulted in a knowledge drain because ex-CSPs didn’t want to be associated with low status browser fiddling any more. Their successors had to start all over solving browser compatibility problems.

Ironically, the largest increase in status of client-side programmers was caused by the Browser Wars. When people became aware that there were differences between Netscape and Explorer, they loudly clamored for skilled professionals to solve these problems. Hence client-side programmers were taken more seriously and became full team members.

Fortunately, the status of a client-side programmer is on the rise, especially because accessibility, standards compatibility, and a general feeling that sites should be kept simple require a skilled professional for correct implementation.

The ideal Web team

So the ideal Web team consists of a maximum of seven people, all specialists in their own field, who are willing to listen to each other, to defer to each other’s judgment, and to communicate importantly or even not so important information immediately upon receiving it.

Of course, having an ideal Web team is no guarantee that you will create an ideal site. For that you’ll need a few more things, like an ideal client. But that subject will have to wait until a future column.

Peter-Paul Koch is a freelance Web developer, writes and maintains the JavaScript Section and is an Administrator of the WDF and WDF-DOM mailing lists.