Building with Rusted Nails

In: Articles

By Nick Finck

By Peter Fielding

Published on March 8, 2001

When I think of web designers and developers, I think of them as craftsmen. These are people that are specifically skilled for their jobs, and know their way around almost any unforeseen obstacle that may appear in their path. A true craftsman is an artist, who pays close attention to detail and produces work of the highest standard. These are the architects of solid information structure. They are not merely turning out product, but building from the foundation to the finishes.

In such regard, we can compare web design and development to the process of building a house or a structure. The development of every web site has a process that these craftsmen must follow in order to achieve the finished structure. These phases are generalized and somewhat vague at times, while some may even be grouped or varied in name, but they are all essential steps in each web construction. By comparison, they are the blue prints and the architect’s details of what is to come. They are absolutely integral to building a successful web site in today’s economy.

What area will take precedence at each step? Which professionals are needed to complete the project? To answer these questions, and more, we need a strong set of plans. We need an Architect.

Starting from Scratch: Design and Architecture
As any construction project has a set of preformed plans, and a strong supervisory team, so too should any web construct. When building a site from scratch, the first thing typically addressed is the design, or the look and feel of the site. At this phase we have a wide range of talent collaborating to envision the finalized project. Everyone, from the Creative Directors to the Production Artists, is working toward a common goal: to build a solid structure that both works, and is pleasant for the audience to look at.

More often than not, this phase is applied specifically for design and neglects the concept of site foundation and infrastructure.

A web site is not built from a design concept alone.

A well-built site requires a firm understanding of the medium it’s constructed for, as well as the functionality of the final product. This is the phase where Designers and Information Architects work hand in hand, to not only build something aesthetically pleasing, but also to build it in a way that makes sense, and can continue to make sense through the upgrade and maintenance processes.

The structure and flow in the functionality of the site is as important (at times even more so) as how the logo looks and what colors are used in the design. The IA and the designer should be a collaborative unit, carefully examining each other’s work to ensure that their end of the construction is met or, in the case of a great team, exceeded. A design needs to be much more than fancy navigation bars here and cool rollovers there, it needs to make sense in the flow of the site. Building and organizing navigation systems based upon what area in the site they take you is a vital part of laying the foundation for development. Navigation systems should be broken up into an order of hierarchy and importance, while maintaining a feel of cohesion with the rest of the site. For example, a site may have global, local, and regional navigation systems all working within the same design, yet clearly identified as unique from each other.

If the job of the information architect is seen as corresponding with that of a structural architect, then the designer must be seen as an amalgam of superintendent, and foreman. The IA’s plan, or model, needs to be implemented and, at times, revised by the designer under supervision of the IA. It is not enough to see these craftsmen as sectional heads of a project, but as the nucleus of a true team effort.

Once the design and layout are built and the flow of the site is complete, the job of the designer and the information architect is far from over. Both must also work through to completion of the site to ensure that the design goals are being met and that the flow is remaining consistent with the existing documentation. Too often, a design simply handed off to a developer with no follow-ups by the original designers. This method is both shoddy, and lays the unsound groundwork for eventual failure.

Intrinsic problems can arise when the importance of construction management through the duration of the project is underestimated. For example, let’s say the design has been finalized and a flaw has slipped by, something in the design that could not be easily done with XHTML or DOM. The Developer picks up the design and starts building the markup when they run into this problem. Something as simplistic as a DHTML menu that is over a search box can cause a page to be displayed incorrectly (with the search box appearing over the menu) in some browsers, rendering the graphical design, and the structural navigation, useless. The developer’s choices then become either develop around it or remove the problem completely. If the IA were diligent in overseeing the construction, knowing the technology well, and the developer is proactive on finding a solution to this problem, there will be a means to keep the design and not hack up the XHTML.

A lot of weight rests on the shoulders of the developer. Their task is not easy. They are used to working with duct tape, bandages and bubble gum to hold pages together in the visual aspect of things, yet producing clean enough code so that it passes the site inspection (we’ll touch more on this later). The next step is to take something that is non-physical (a design comp) and bring it into the realm of reality (XHTML, HTML, etc). Which brings me to the next phase of the development process.

Building the Foundation: Core Understanding
Every web site must be built upon a core understanding of the medium, its benefits, and its limitations. The developers are the front line for understanding the medium even more so than the designers are. They must know not only what technology is right for the job, but also how it will work on the site. It is the responsibility of the developer to ensure the longevity of the site and to plan for flexibility in the code to allow for future development, redesign and restructuring.

In order to ensure the site will stand the test of time, it is important that the developer knows how to hand code and can quickly identify problematic code without the aid of software. A developer must have an understanding of the newest technologies that are quickly emerging and must be able to suggest the appropriate use of those technologies if and when the site’s user-base is up to the standard.

Watching an old building collapse from the explosives of a demolition team is an awesome sight to say the least. However, there is nothing more disheartening than watching a perfectly good building collapse in on itself due to poor craftsmanship. It is the duty of the developer to ensure that no bolt is left loose and no nail half-way hammered. The code must be clean, well organized and properly executed with precision and accuracy. Building with anything less in mind would show the ineptitude of the development team, and the inevitable failure of the site as a viable structure.

Wiring the building: Backend Technology
On the more technical side of things we have the programming and backend development of the site. This stage revolves around the understanding of languages such as Perl, PHP, ASP, JSP, XML and ColdFusion. The programmers must also know how to wire things up, such as database support of the generation of dynamic content and of course, our favorite: secure transactions and e-commerce systems.

The backend technology must work hand in hand with every step that has been developed and designed so far. The interface must be consistent on both the dynamic pages as well as the static ones. The programmer often works collaboratively with the developer to get this feat accomplished. A good developer will also understand how to help the programmer integrate these kinds of technologies and use foresight in the development of the HTML and XHTML to accompany such things.

It is the programmer’s responsibility to ensure that no wires are left exposed so that no damage can occur from the users of the structure. They must also check and test all their code to ensure that no lines are crossed. One crossed wire could mean the compromise of important data on the site and potentially end up costing the agency millions.

Site Inspection: Validation
After all the sawdust has settled and the excess lumber has been removed we can now call in the site inspector for an evaluation of our work. The inspector is very direct with what should be fixed and will indicate exactly what needs to be fixed. For the web, this inspector is the Validator.

The W3C has spent the time and money to provide us with a service to check our code and ensure that it is valid and without errors. Though they do admit that the validator will not check for everything, it will find the most common mistakes in any markup.

So, you are probably asking why it is so important to have this kind of inspection of the code. That is a very good question and I will attempt to answer it in the simplest form possible. It is because today your web site may function as expected in your browser, but the technologies of tomorrow, such as XML, may actually cause your browser to produce errors, incompatibilities, or prevent loading of the site. This all revolves around the idea of quality craftsmanship, or in reference to XHTML and XML, “well-formed” markup.

Standing the test of the elements: Well-formed markup
Well-formed markup basically means that your code is consistent and up to specification. In XML, the markup needs to be lowercased, nested correctly and properly contained. This is important if we ever want the web to move forward on innovation, because we need to make sure we can write code that will work on all new devices and clients out there. This includes everything from dishwashers, cellular phones, gas pumps and PDAs. The idea is that the technology will allow us to request the document in a specific format according to what client we are using. If we request a document from cellular phone the technology will allow us to receive a WML/WAP document. If we request the document from a web browser, we will receive a XHTML/HTTP document.

The technology is already in place to do this, but it is up to us as the developers, designers and programmers of the web to ensure that this evolution occurs. Our tools must be updated to code for the newer languages and our browsers will have to be upgraded to support the newer technologies, but in time it will happen if we keep a focus on what is to come.

Ignoring technological advancement and continuing to build our web sites based on older technology foundations will be the equivalent of building a house on sand. No one likes a lopsided house, much less one that is about to go plummeting down a hillside.

---

Resources
To Use or Not to Use: An XHTML Roadmap for Designers by Molly E. Holzschlag

Preparing for standard-compliant browsers, Part 1 by Makiko Itoh

Preparing for standard-compliant browsers, Part 2 by Makiko Itoh

What are Web standards and why should I use them? by the Web Standards Project Developer Education Committee

Editorial Response to WaSP’s Upgrade Your Browser Initiative by Molly E. Holzschlag

Back to the Basics by Ben Henick

To Hell with Bad Browsers by Jeffrey Zeldman

From Hacks to Standards: A Web Designer’s Journey by Jeffrey Zeldman

Validating XML: A Pretty Complete Primer by J. David Eisenberg

Key Sites
The Web Standards Project (WaSP)

The World Wide Web Consortium (W3C)

Key Tools
W3C HTML Validation Service

W3C CSS Validation Service

Related Topics: Web Standards, Technology, Web Maintenance