Misuse

I’ve been through the process of going from a great graphic design to a website a few times, as I’m sure many readers have also. I was recently asked by a company for advice on this process, and I thought what I told them might be of interest to others more generally.

These thoughts assume that you’ve already got the “look” of your site figured out. You have either a graphic image of that look or some kind of HTML page. But whatever it is, it may not have been designed for production/programming work.

From this point, what I’ve learned is that getting one great HTML/CSS/JS page worked up at the start is really invaluable. This page should be a “programer-compatible” page, meaning it doesn’t just look great on the browers, but is designed to let a programmer manipulate it programmatically in many situations (making subsequent pages much easier/cheaper to build). Once it’s done, you can also get a lower rent HTML person to use the template to build out the rest of the pages to the point where the programmer moves those HTML pages into ASP structure. But that first page is a killer and if it’s done wrong, it makes the programmer’s job much more difficult for a long time.

So the fact that you spend more (hourly and total) for that first page is pretty normal and shouldn’t have you running to the calculator to multiply against the total number of pages and worrying about over-budgets! I’d recommend giving that first page a couple of revisions before moving on to other pages – it’ll seem slower but will result in the overall project time and cost being lower, in my experience.

Regarding that first (“template”) page, here are some of the things I think are critical in the page design:

• CSS styles should be named, hierarchical and inherited where appropriate. I’m currently dealing with a “hodge podge” CSS file in another environment and it’s a real pain. Where possible, it’s great if you can define a style format (like a font) and then inherit that down into all the other CSS elements, so making adjustments easier b/c they only go in one place. It also makes debugging CSS easier, especially during early development when it really matters. Ideally you’ll have just one CSS file.
• The total number of library files (CSS, JS, images) on a page directly affects the load time. You want to keep this total count as low as possible (ideally one CSS and one JS). But don’t worry about this in development. Once you “lock-in” a set of JS libraries for example, you can concatenate the “frozen” set into a single file and deploy that. You can rebuild that single file whenever you upgrade library versions.
• Specify width and height on every image files. If you do this, the page can render before the images are loaded increasing the apparent/effective speed of the page to the user.
• Force a well structured hierarchy of HTML tags.
  • Html tags in general should be very orderly for ASP type systems – especially those which affect style and layout. Amateurs will start one styled tag and then close a different tag from further up, creating mismatches, which is a real pain when doing ASP type work. E.g.:

<span id="style1">
  [code..]
    <div id=style2>
    [code..]
  </span>
  [code..]
</div>

(Note: I've indented the above to show that the errors should stand out if following the next point).

• HTML should be properly indented just like code. I'd recommend for HTML using one space indents since there is often a lot of nesting. It's also ok to indent just once if you have a bunch of tags that start and end together (like div's, anchors, etc). Also, request lots of comments indicating what's going on in this code. If you use a dynamic page template language like Rails, .NET or JSP pages the comment format can be one so that customer doesn't see it in the browser (below is a Rails/ERB example). E.g.:

  <%# block for price detail breakdown%> <div id="style1"> [code] </div> <%# style1%> 

  • Sometimes spaces mess up your layout and the html programmer will want to fudge by removing somes space-indents or carriage returns. Sometimes this is ok, but often this means the way you're building HTML is wrong, and it won't be cross-browser compatible - so keep an eye out if you see this.
• Define a set of browsers you plan to support and test against them all regularly. This is a bit of a pain but will save a lot of pain later if you don't pick too big a set. I recommend: IE6, IE7, FF2, FF3, Safari (latest version)
  IE6 renders very differently from IE7. I have recently seen some FF3-only bugs as well. In general IE6 will be your problem child - where the layout works everywhere but there so test heavily against that one.
• The programmer should be involved in deciding where to put "blocks" of HTML. The header and footer need to be discrete "blocks" of text of course. But there will other spots where this will matter also, such as search result rows. These blocks will let the programmer break apart units of function into libraries that can be called by multiple pages. You should have a healthy skepticism of doing too much in the way of "abstracting" stuff into blocks (see next point).
  • Related to this, I would also advise not to spend too much time putting everything into blocks! I've found that this is a technically compelling exercise that doesn't yield value down the road. A lot of HTML is "gunk" and can be left alone - if it's done in an expedient manner, that's ok. But the programmer should be able to tell the "programmatic" HTML that needs to be "clean" from everything else and be engaged with the HTML programmer in that way.
• Speaking of gunk, beware of the use of tables for layout. In my opinion, there is almost never a good reason to use tables for layout. I think this is pretty generally the consensus among HTML designers but I figured I ought to mention it here too. Even the original purpose of tables, which is to hold cols/rows of data, can often be better accomplished (i.e. looks better) by using CSS/layout/style techniques.
• If the site is Javascript-only, you should have a technique for detecting non-javascript browsers and giving them a little error message explaining the problem, rather than just leave them hanging which can make you look bad.
• Ideally you'll pick a single javascript library and stick with it. The costs of switching between different ones can be a bit of a pain. Prototype, JQuery and Dojo are three common examples.