Why, Blog, Why?

I came across a sort of mini-novel/case study today called Client vs. Developer Wars. In it, the author narrates the story of Brian, a project manager at a fictitious company called Electron Cowboys, and his experience with a client that hired them to build a website. The story details one of the classic problems in web development - getting the client to tell you what they want and giving the client what they really mean. I’ve been in situations just like this where a client will only give you a general idea of what they are looking for using buzz words like “cutting edge”, “sexy” , “hip” and “cool”. These terms are mostly used to describe the design or the look-and-feel of a website rather then the content (I think most clients focus on style over substance) , and it’s because of this that the design process is the longest part of the development process. After all, the words “sexy” and “hip” are relative terms that can be interpreted differently by each and every person. What one designer thinks is sexy may just look like a complete mess to another. So, if a client can’t tell you with absolute certainty what they are looking for, how can a designer ever be expected to nail a design on the first try? The truth is that they can’t, and if a client could tell you exactly what they wanted then they probably could have just done the design themselves and saved time, money and many, many headaches on both sides of the hallway.

Follow up:

After the story of Brian et. al. concludes, the article morphs into a case-study of how an actual web company took a similar experience and used it to come up with what they felt was a revolutionary process of proto-typing a website that would lead to less confusion and less overages through the rest of the design process. In short, their new process involved the separation of the text that makes up a web page from the presentation of that text into a graphical medium. This practice is referred to as compartmentalization and is used frequently in software development such as the MVC, or Model, View, Controller, Framework. Under this theory, the Model is the data that is displayed or submitted within the program, the View is the presentation of that data and the Controller is the program logic that displays or processes the data. Web Developers routinely separate the Control layer out within their projects but will almost always combine the Model and View layers together. This often results in web pages where the data is locked into a design template. Even though the data itself may change as a result of the actions of the Control layer, changing the layout of that data usually requires a lot of work as you need to manually separate the Model and View layers only to combine them again in a new layout. Working backwards, this means that most web projects can’t get off the ground until a suitable design has been selected and approved by the client. Only then can you begin to cut up the design in to an HTML template and start plugging in the content.

So how does this parlay into a life altering experience through XHTML and CSS? Through the use of well formed X/HTML and cross-browser compatible CSS we can finally make the separation between the data and the presentation of a web page and do it in a way that is easy and extensible. By doing so we can then alter the typical development process so that the development (i.e. coding and data entry) phase is not dependant upon the completion of the design phase. Instead, we can work on both phases in parallel resulting in more time for development, less missed deadlines and less project overages. Let’s explore this further.

The first thing we need to do is to understand the concept of the separation of the Model and View layers in regards to web development. I think this is best done visually, and the best place to go for that is CSS Zen Garden. For those of you that are unfamiliar with this website the concept is simple - The authors provide a single well-formed, valid XHTML document (the data) with no visual markup (i.e. formatting) and let any user submit a new CSS file that controls the presentation of the data on the page. The base HTML code, when rendered in a browser, is about as plain of a page as you can get. It uses no tables, no frames, no formatting tags, no images - just well-formed HTML with properly nested tags, using all the right tags for all the right purposes (H1 for the first header, ULs for the list of links, etc). It is pure, unadulterated data. But, apply a CSS file to the page and you can transform that data into any number of presentation styles (ex: 1, 2, 3, 4, 5), all without touching one line of XHTML. This is compartmentalization at its finest - you can make changes to the Model, Visual or Control layer without affecting the others.

So now that we’ve seen compartmentalization in action, let’s apply the concept to the web development process. For your next project, instead of hanging onto all of that content that the client is sending you until they’ve approved the design, just start tossing it into some well-formed XHTML pages and get the Model layer of the web site off the ground. At the same time, have your designer get to work on a few mock-ups for the design of the pages. As you can see from CssZenGarden.com there is almost no limit to how complex or simple you can present your data. When the mock-ups are done, cut ‘em up and apply them to your pages using CSS. Your data can stay just as it is and you can swap designs in a snap. Your client will benefit from being able to see the design in context instead of in a few screen shots and you will benefit from being able to retain what sanity you still have when your client calls you up with revisions to design or data.

I think this is a good place to wrap this up. But before I go I’ll leave you with a few tips. The migration to this type of development can be tricky unless you plan appropriately. Here are some of my recommendations based on my personal experience.

1. Prior Planning Prevents Poor Programming - It’s not possible (or at least not practical) to write an HTML page that can have an infinite number of layouts applied to it. There will be limitations based on how you group your data together, so try to plan not just for flexibility, but also logically. Try splitting your data into at least 3 parts - a header, a body and a footer or left, center and right. It may very well be that the data in the header section of your HTML will end up at the bottom of the page in the layout once the CSS is applied, but at least you have a starting point. Take a look at the layout of the HTML in the CSS Zen Garden base file for an example of a good open layout. However you group your data together, you should still be able to read the unformatted version and have it make sense.
2. The hardest part of designing with CSS is the differences in how each browser renders the end product. Netscape, Internet Explorer, Mozilla, Opera - they all have little quirks that need to be accounted for. Don’t worry though, for every quirk there’s a work around. I detailed the Star HTML Selector Quirk in a previous post, and there are several dozens more resources on the web for dealing with finicky browsers. Be patient with your code and let Google be your guide.
3. Making your web site accessible to the visually impaired is only a few small steps away from just having well-formed XHTML. Use this time to make sure that your sites conform and open up your client to a whole new set of customers. Since most visually impaired users use a non-graphical screen reader to help them surf the Internet make sure that your pages still make sense when unformatted.

Update
I came across an article on another blog that details good, semantic HTML practices. You can find it at http://www.brainstormsandraves.com/articles/semantics/structure/