Web Templates for Erlang: A Different Take

Much discussion of web templates on the Google Groups – Nitrogen forum recently.

I stuck in my two cents and generated some interesting discussion.

This is a topic I care a bunch about based on experience and hard knocks.

Today I posted the rationale behind my thinking, thought I’d share it.

Note, I define a “Part” as an encapsulated single-function black box of code that can be configured to display CSS stylized web content. You can think component, applet, mini-application, or what have you.

So here it is:

“I’d venture that the truest thing one can say about templates is, ‘different horses for different courses.’

Page-level, monolithic templates are fine for relatively simple pages.

But I argue that there is a conceptual mismatch between the way many web developers, particularly those on the programming side, see the web and the way many many sites are presented today, indeed, the way many page content developers and designers conceptualize a web page.

On the one hand, the conceptual unit is the ‘page.’ Makes sense, since the page is the basic unit of HTML.

But for well-trained designers the page is simply a frame for a ‘page grid.’ Squint your eyes and look at any magazine, newspaper, or even well-designed brochure, and you’ll see a mathematical “grid” structure, where each panel in the grid is a container for content. True, many designers spread content over two or more panels, but the basic structure holds.

The grid system is a fundamental concept in many graphic design text books. Why? Because it provides a coherent way of organizing disparate elements of content.

Squint at many, if not most, well-designed, high-traffic websites and you’ll see the grid system at work organizing the content. The grid system is like a well-organized closet with shelves and cubby holes — everything has a place and everything is in its place, whereas a page-oriented design is more like one of my wife’s kitchen drawers, everything tossed in a jumble with everything else (I should talk; my closets and drawers are even more disorganized).

Now take a look at amazon.com. I have no idea of how Amazon constructs its pages. Maybe as someone suggested it’s a big hairy content management system. Doesn’t matter to my basic argument.

Call up page source for the Amazon home page. Now squint your eyes and substitute variables for every substantive element; e.g. in your mind, turn the source into a template. Now imagine a programmer giving you a list of variable names for different dynamic content elements and working through the template to match content item with place-holder in your big, long, hairy template file.

I’m sure no one does it quite this way, but you get the idea.

Now take another look at Amazon’s home page. Squint your eyes and you’ll see a simple three-column grid, or “make-up” as a designer would say; e.g. left and right side bars surrounding a main content panel.

Look more closely at the top of the grid and you’ll see three content elements (personalization line, personal menu, and search bar) that span the content column and right side bar. They’re still consistent with the basic grid, but they add visual diversity and interest while keeping content well organized.

Further note that the basic columns contain simple lists of content elements stacked one atop another.

Now, look at the variety of content elements that fill the panels in the grid and think about the code, HTML formating, and CSS styling tags needed to create each element. You’ll note that some elements are straight text, some are text and graphics, some made up of hyper links, some form elements, some buttons, and some report data drawn up from a database.

When I talk about ‘Parts,’ this is essentially what I’m talking about. Content elements can be abstracted into a set of ‘Parts,’ distinguished by underlying logic.

Now imagine a page construction process that goes like this:

1) Programmers provide an inventory of Parts, single-function black boxes of code that can be configured with content and styling to generate content elements.

2) Select the Parts you need to convey the information you want. Enter content for each.

3) Design (or select from an inventory) a page grid, essentially a list of DIVs (see my earlier post for example).

4) Develop (or select from inventory) CSS file(s) for your page

5) Plug parts into the page grid

6) Tweak styles in each part if necessary to maintain stylistic consistency with page.

A system like this:

1) Is conceptually consistent with the way content developers and trained designers think

2) Does not necessarily require the page designer to adopt any additional tools beyond HTML and CSS.

3) Breaks down a potentially confusing task into a set of relatively simple tasks.

4) Content and styling can be configured with a simple text editor on the one hand, or sophisticated GUI tools on the other. Indeed, GUI tools could be an additional layer on top of the simpler system.

If the base system were open-source, then specialized parts and GUI systems could add value to meet specialized requirements or support a variety of business models.
E.g., Parts could be open-source or proprietary; offering the best of both worlds.

5) Encourages substantial code reuse.

6) Pushes code complexity down into the Parts. With careful factoring, code complexity may never even be an issue but for the rarest and most algorithmically challenging Parts.

7) Offers great flexibility. Change the page grid and/or the high-level CSS file and you change the basic look of the page. Reuse content elements across pages. Change a content element with little to no interaction with other content elements.”

(Getting too long here… continued next post)