When I was hired at LexisNexis back in 2003, it was to develop HTML templates, often to take to Usability testing. I’d been building actual web sites professionally for four years, so initially I felt this was “a step backwards”. Soon, however, I realized that template building is really more of an art, and indeed more elegant.

When you’re working on a website, you know what you’re building. When building a reusable template, there is a level of abstraction that must be accounted for. It’s a focus on the presentation layer for its own sake, rather than as the wrapping paper laid over the all-important data.

Over several years of template building, I’ve found there are several important notions that increase the efficiency in template creation as well as the overall quality of the deliverables.

Pick a Server-Side Scripting Language

PHP, JSP, ASP- I don’t care.

Identify variations in user or system state

A site of any complexity will have some level of variation in user or system states (authenticated vs unauthenticated, empty shopping cart vs non-empty). Identify these states up front, and determine what the implications are to the UI.
Create variables to represent each of these states. (loggedIn, cartEmpty). Use these variables to manipulate each individual variance across the site, in response to a query parameter being passed in. It is important to identify a default state.
By treating each variation itself, we are able to account for a greater number of combinations of states.

Be Lazy

Never code ANYTHING twice. Anytime something is on a design, ask if it will occur elsewhere. If so, make a generic version of it and include it. Coding anything more than once is not only inefficient, it risks introducing unwitting variation. If I pass off two pages to a development team and they each treat the same thing differently, which should be used? Leveraging the same code also helps to ensure the code is at an appropriate level of abstraction and can account for variation of data.
For me, the best template project involves the fewest number of discrete URLs.

Remember: this is a TEMPLATE

A template is commonly defined as a pattern. It should be simple to follow and easy to apply elsewhere. Remember madlibs? Enter in the appropriate type of word and it populates where it’s intended to be. That’s what templates should do. Define the rules around the content, and then just give it a slot to plug it in. If you have a column to hold images, build the framework around it to give the images the appropriate spacing you need; don’t expect the next person you hand the code to to apply your specific class names to elements. Dummy-proof it Make your code apply to the whole, and then only code for exceptions as needed. If possible, push back on designs that necessitate “exceptions”.

Respect the Data (Unknown as it is)

Data coming from an external source is like a box of chocolates.. In the absence of specifics, the diligent developer must anticipate the possible areas of variation and recognize the boundary cases. A certain design may work wonderfully if there are three lines of text with a font size of 10px, but what happens when more (or less!) text is needed, or the visitor increases the font size? This is the difference between the designer and the template developer: one is in search of the ideal design, and the other anticipates the limits to which it may be pushed.

Know Where You Are

Relative paths can make or (literally!) break a template project. The use of absolute urls means you don’t need to worry what page is trying to access your assets from.

Assign Appropriate Class Names

This is related to the points above, but is still worth calling out on its own. Reuse code, recognize you’re creating a pattern, and be lazy. Use generic class names related to the overall semantics or layout (i.e. navbar), not the specific data you are trying to markup (search-results-sidebar). Naturally, exceptions can be coded with more specificity, because there must be some knowledge about the particular data for it to be recognized as an exception. But manually calling out the same type of layout of multiple pages is once again introducing the possibility of error: if we have 12 pages we’ve templated out and manually apply a style to 11 of them, is that an oversight or intentional? What do we do when we have to create a new page?

Plan for failure

Depending on the level of fidelity, a template project may or may not have javascript interaction in it. If so, it’s a best practice to check to ensure an element exists before acting on it. This should go without saying anytime, but it’s particularly important when the same footer (and JS script block — you DO put your JS at the bottom of the page, right?) is being pulled into different template pages. Always check to ensure an element isn’t null before attempting to manipulate it.

Explain, explain, explain

There is no shame to commenting code. Especially exceptions or default states. A name and initials is a nice touch as well, particularly when a project is in the early development stages. Many development teams will comment in the server-side scripting language so that it is not rendered in the outputted source code, and outsiders will not be able to see it. This is great; it is only the developers who need to be aware why things were handled as they were.

These are just a few of the tricks I’ve picked up over the past several years. It has occurred to me that template building is almost a different skill than straight-forward web development, and I wanted to capture some of the nuances. I imagine my friends and former coworkers could add to the list!

I am drafting an article for the RI:Technology blog on Screen readers and Search Engines, and was reviewing a paper a colleague wrote about Search. He mentioned sIFR as a technique “to bring content to search engines”. I asked another colleague about this, as I’d always just considered sIFR as a “stylability” technique.
We started talking about the weight factor of search engines, whether content written to a page and then sIFRized would be weighted more heavily than the alt text of an image. I hadn’t really thought about that before. I then mentioned a habit I have of placing images within a heading tag, i.e.
<h1><img alt="descriptive text" /></h1>. Toby asked if this really worked, if the alt text would be considered the header. I realized that I’d never really verified it before.

So I took a quick look at an example using FANGS, and learned that alternate text, really isn’t. Turning off images would cause the alt text to display as the appropriate heading level, but at least for FANGS, the alt text does not get surfaced as the heading (the text should show up before the colon in the screen shot below)

Now, obviously FANGS is an emulator, and it’s possible that a screen reader would access that alt text. But this gave me something to consider..

As mentioned previously, I have been doing some simple email templates for our project. While we were in development, we could only send emails locally, so I was able to ensure outlook handled them properly. When we opened it up to web clients, however, we encountered several “idiosyncracies” we had to account for.

As I mentioned in my last post, I wanted to set the appropriate DOCTYPE. Yes, an admirable idea, but I completely ignored the fact that these emails were being rendered within an HTML page — hence, my DOCTYPE and html wrapper tags were stripped out. There went my doctype, along with my good old-fashioned attribute specifications for bgcolor, alink, vlink and text. So it was back to manually specifying stylistic information on every element (on the whole I’d done this already, it was the bgcolor for the entire email that was missed out on, so I had to add it to a table that was specified at 100% width and height.).

I also encountered some fun with these “smart” webclients trying to interpret the text. We have the typical disclaimer at the top of the page, “to continue to receive emails, please add XXX@mydomain.com to your address book”. Both yahoo and gmail tried to make links of things we didn’t intend, mucking with the overall look of the email. So now I am having to go back and change periods into . and at symbols into @.

Not that any of these are difficult tasks, but they were small stumbling blocks, so I wanted to be sure to capture them for next time–

Another case in which I feel I am returning to the days as a contract site designer. I have been working on some email templates, something I haven’t done in years. Ah, developing in tables again! I have done some reading on what various email clients support, and the purist in me wanted to code to a specific version of HTML. I started to look at adding attributes directly to the body tag (remember ALINK and VLINK), only to see they had been deprecated back for HTML4. I started to look back at references for HTML3.2, only to make an interesting discovery.

Once upon a time, back in the dark ages of HTML3.2, DOCTYPES weren’t fully qualified.

On A List Apart, Jeffrey Zeldman had noted that:

Scattered throughout W3C’s site are DOCTYPEs with missing URIs, and DOCTYPEs with relative URIs that point to documents on W3C’s own site. Once removed from W3C’s site and used on your web pages, these URIs point to non–existent documents, thus fouling up your best efforts and the browser’s.

…and I found this to be the case even with the HTML3.2 recommendation itself (whether or not you believe me, follow the link to marvel at the old school background image!). I thought I simply had to do some more research online to find what I was looking for. But lo and behold, I ended my search at the W3C QA Recommended list of DTDs to use in your web document.

I have been working in the field for quite awhile, but it amazes me sometimes what I take for granted. I recognize the importance of using a DOCTYPE, but now I wonder if I truly understand it. Is the URI not needed because the parser knows the definition for HTML3.2?

Evidently you can handle all of MVC within flex, but I am still seeing it primarily as the presentation layer — perhaps as my familiarity increases, I will be more comfortable letting it handle more. in the meantime, however, it is easier for me to see flex as a way to present data — and only parts of it.

I plan to use SWFObject to include flex components within a larger page — and that also lets me add the content directly to the page, to be swapped out by the richer component if it is supported. That seems to be a decent solution for search as well as acessibility. Perhaps mobile as well?

Now, I have never been a fan of alternate presentation based on user agents, etc (browser sniffing, etc). Build to standards for a more robust, consistent solution. Otherwise there are more maintenance and consistency concerns (not to mention the fact that you can offend users by offering them up ‘dumbed down’ content). That being said, I do like the idea of progressive enhancement- which is how I am choosing to see this. I don’t want to deprive users of important information, but I do want to offer the best user experience to those who can support it.

What I’d like to figure out is how to ensure the same content is being served up, regardless of the presentational format. So if we’re feeding XML into the flex component, I want the same content written to the page. I did some quick prototype work using XSLT at LN, I’d like to investigate building modules not simply of flex, but of the entire package: XML (data), being rendered on the HTML page and supplemented as possible in a richer format.

I was recently asked how I approached coding, in terms of validation and standards. I said that when I had complete control over the code, I coded to xhtml1.0 strict. “for all browsers?” I was asked. The question took me aback. Yes, of course for all browsers. I wouldn’t even know how to code differently for separate browsers. Sure, CSS and JS take some work to standardize, but for me, coding to xhtml1.0 strict is a no-brainer. [I did give the disclaimer that when using an imposed infrastructure, I had to take a step back down to HTML4-.10 transitional for when we were using struts, and I'm still not sure we'd validate]

Further in the conversation I realized that while I can strongly claim adherence to xhtml1.0, I can’t do the same for a certain version of CSS or javascript. I know there has recently been a call for CSS2.2, but honestly, I just use code that works. So too for javascript. In a similar case, I skimmed something that mentioned some new functionality for javascript1.6. Are we up to 1.6? Who knew?

That’s what struck me: the aspect that I consider ’stable’ (xhtml), I code to completely and I’m familiar with it. The other two, that require more knowledge of ‘what works’ and ‘what doesn’t', I have more applied knowledge. I don’t know if it is due to the age of the technologies and how well they are handled by user agents or not. That is, (x)HTML is a markup language, and is platform- and device-independent. It is when you get into presentation and behaviour that the browser quirks rear their ugly heads, so it is not simply a matter of knowing the technology, but also how it interacts with the various platforms.

Will I ever get to a point where I can say “I code to CSS3?” I’m not sure..