« Penmachine.com home « Long article index | « Back to "Part 1: Ideas" :: On to "Part 3: Content" »

Building a Standards-Compliant Website...
...with an internal team at a small company

This piece was originally published in my online journal on 7 May 2004.

Part 2: Design

It's easy to declare yourself a web standards advocate and then get all evangelical about it—spending endless hours refining your personal weblog so that it validates as XHTML 1.0 Strict (or something really weird like XHTML 1.1) and meets all the semantic, accessibility, and cross-platform recommendations, then pooh-poohing any site, especially a commercial one, that doesn't—never mind whether your own site is worth reading at all.

But real-world web design has to be practical, and websites are for the people who visit them, not the people who build them or the people who sit on the sidelines and comment about the people who build them. Real sites always involve some compromise, because they need to accomplish something, and they need to get launched, and the people who make them have to get on to making other sites or other things in their jobs and lives.

That said, in building the new site for my employer, Vancouver's Navarik Corp., we on the team that did it wanted to practice what the company preaches as much as we could.

Standards are the easy way out

While its products are not open-source software, Navarik advocates the use of open-source tools, as well as open standards for data storage and information exchange, because they make good business sense, both for Navarik and for the company's customers.

Let's face it: despite its headaches, using standards makes development work easier, because, in part, you can blame a lot of problems on web browsers, operating systems, and applications that don't support the standards properly, rather than on your own code. (Maybe I should put it more politely: standards make web troubleshooting and debugging more predictable.)

So while there's much talk about improving the experience for web users, and supporting the ideals of information wanting to be free, and fighting against proprietary monopolies, web standards are also about making development, cross-platform site compability, and wide accessibility easy for web developers, without forcing us to reinvent the wheel (and test on a few hundred different possible client devices and configurations) every time we want to do something a little different.

So, when Bill and Dave and I started talking about reworking Navarik's website, we wanted to be standards-compliant for both altruistic and selfish reasons. Standards are also part of Navarik's way of doing business—and, sure, being compliant might get us some small cool points among web standards evangelists, especially those who might work for some of our potential customers.

Blogs are the easy way out

Most of the hoo-ha about weblogs, or blogs, is about how they let individuals like me ramble on and on (and on) online with relative ease. But there's another side to them. Blogs are lo-fi collaboration tools, and while they don't do much, they actually work, which is more than can be said of a lot of higher-fi collaboration tools.

Navarik has so far avoided groupware such as Lotus Notes or Novell GroupWise, in favour of an internal communications network that consists of:

A file server, where we keep documents of all sorts so they can be found centrally and backed up.
E-mail.
Internal instant messaging, through our own secure Jabber server.
Most importantly, an intranet that is essentially just a bunch of password-protected weblogs that focus on different topics.

In effect, then the Navarik home page is a public extension of our private intranet, using the same technology to bring some of our blog-based discussions to the outside world. In addition to that, quite a number of Navarik employees past and present (me included) run their own personal blogs (sorry if I missed some), which sometimes talk about what the company does. So we're a pretty blog-happy organization.

Going slow is the easy way out

So, several months after doing initial planning work on a new website, Navarik hired Dave and me as employees. But remember that real web development happens in the real world. While the new site was on our to-do list, there were more important money-making projects. I worked on a lot of proposals and presentations for customers, while Dave concentrated on graphics, user interface refinements for Navarik's web software, and cleaning up all those intranet blogs so they made more sense and were easier to use.

Once we had made our way through those projects and freed up some time, Dave began refining his design mockups into actual web pages. By March 2004, we needed to hash out what the new site was going to contain. We took the old massive site structure I'd assembled and stripped out everything but the basics, so that there were only 10 pages left (aside from news archives).

That, it turned out, was too little to tell our story effectively, so we restored some of the old structure. Dave was probably getting frustrated with that, since he was trying to work on a site design where the structure of the content kept changing underneath his feet.

Modules are, er, the easy way out

Fortunately, Dave had been smart about how he'd built his templates:

Using the PHP scripting language, he constructed everything in small text-file modules that could be shuffled around and assembled into pages in various combinations, even has the rest of us dickered about what those combinations should be. (All the main page content files live in a single directory called /content/, for example.)

All the page markup is in XHTML 1.0, without formatting and layout information included. He gave me strict instructions to write page content with very basic tags, so that a hunk of code like this...

<h2>Products &amp; Services</h2>

    <p>Navarik's software products improve how firms in the
    shipping industry manage and exchange operations data. We
    provide software products to customers that allow them to
    conduct business more efficiently.</p>

<h3><a href="< ? echo $siteRoot
?>/products/solve/">Problems we solve</a></h3>

    <p>Shipping companies are overloaded with vast amounts
    of data. The process of tracking and exchanging this data is
    riddled with inefficiencies, yet is necessary to keep expensive
    shipping assets employed. Navarik's systems bring order and
    efficiency to the creation, communication, reporting, and
    storage of this data&#8230; <a href="<? echo $siteRoot
    ?>/products/solve/">[more]</a></p>

...(and so on) would turn into a page like this without any extra effort on my part.

All his layout and text formatting is done with Cascading Style Sheets, so we could change the design without re-coding all the content pages.
Dave's PHP scripts and server configuration put together all the files so that the resulting web addresses are surprisingly sensible. For instance, Navarik's telex and fax messaging products are at navarik.com/home/products/messaging/.

With an agreed structure and well-built design and template system, it was, at last, time to finish this thing off. I'll talk about that next.