Iain Dooley of The Working Software blog wrote about an idea he calls “Template Animation“, which seems to me to be in essence the principle of building dynamic sites with HTML snippets which hold no logical constructs. The idea is to create a separate template for each of the logically different view and achieve variable output by selecting the appropriate static template, interpreting it as a HTML DOM tree and using DOM manipulation to insert varying data.
In theory this seems like a very good idea because it would allow the HTML implementer to know nothing of the back end implementation and thus people could be brought in to projects to build HTML implementations with less case-specific introductory training. While the goal is intriguing, the proposed solution is in my current view only a small piece of the overall puzzle.
First of all I think drawing the line of “templates with logic” and “templates with no logic” to include variable substitution and list enumeration on the “no logic” side goes a long way to defeating the actual gains. Your HTML implementer still needs to test the templates with variable inputs (different strings that might be substituted and different sizes of enumerable lists) that are highly specific to your app.
One solution to this would be to categorize the variable inputs in categories that behave in a similar manner in a certain HTML context and then produce a different template for each category permutation. This requires a strict definition for the possible categories in different contexts and a way to convey the possible permutations from the designer to the HTML implementer. An example of a situation where this becomes an issue is when an user’s name is displayed on the page and the preferred display would be different if the name is so long that it does not fit on one line. The HTML implementer should then receive information that both of these cases are possible within this variable input and a different template should be produced for both category variations.
However the above example brings up an issue which is probably not very obvious if you haven’t done a lot of work with dynamic HTML generation with variable inputs: It is really hard for the server side (where the logic presumably lives) to know whether a name is too long to fit on one line or not. Obviously this is not a problem that is specific to Template Animation and does affect also conventional templates that are parsed on the server side. There are a couple of ways to approach solving these issues: Sometimes this can be dealt with by truncating the variable input to a length which supposedly never exceeds the reserved space (no matter what typography is selected). Other times you just instruct the HTML implementer to hide the part of the text that does not fit the provided space. But the most usual situation is that the best way is just to let the containing element grow vertically to make space for an another line of the variable text.
Template Animation should work pretty well on the first two cases where the variable input is always presumed to not alter the layout dimensions on the page. There is only one category of variable input and that can be communicated to the HTML implementer. But the third and very often necessary type of variable input representation presumably leaves us with two options. The first option is to instruct the back end server to know everything about the variable input container dimensions and the typography renderings in possible HTML rendering devices, categorize the variable inputs into separate categories based on how many lines they would span, and ask the HTML implementer to create a different template for each of the categories. And the second option is to tell HTML implementer that “This variable input might contain text that spans multiple lines – could you please test your template also with such longer inputs?”
I personally think that the server side font rendering path would be pretty tedious to get right but at least with a limited set of supported client side renderers, this could be doable. This would make it possible to reduce the variable inputs to categories and while this would sometimes exponentially grow the number of needed static HTML implementations, we could still remain sure that no additional testing is needed if all of the static HTML templates are checked to render correctly.
But what about the second option? Surely we can expect the HTML implementer to be able to do this tiny piece of testing in order to rid us of exponentially growing static template batches and the need to render fonts on the server side. This sounds very innocent, but actually opens up a very dangerous path where the templates do not only contain logic, but actually contains hidden logic that can not be read by just looking at the template. In effect the template is thus saying “If there is only one line of text, render a box of this size. Else if there is two lines of text, render a box of this other size. Else…” which is a form of logic that can easily conflict with the display of other elements on the page and must be taken into account on each iteration of the template.
So if we hold true to the goal of separating the application logic from the templates, we need to specify a separate logical branch for each of the permutations of the different variable input categories. In the same spirit we can also forget about letting the HTML implementer use any fragmentation methods that would get passed back to the application developers, and just provide full DOM implementations of each possible logical permutation of the system.
I think it is needless to say that in the case of dynamically created listings of user inputted variable data, this logic tree might grow to be really really big. With literally hundreds of logically different views it would not very feasible to think that a simple file name would suffice to map the logically different situations to their appropriate templates – or that anyone in their right mind would actually create each of these branches and map them to code individually by hand.
So basically we are left with either an option to use Template Animation only on a very limited set of use cases where the fully expanded logic tree stays very small, or the option to manage this complexity somehow. The tree-size related complexity would be present at least in a) formulating the logic tree in it’s fullest, b) communicating this logic tree to the HTML implementer in the context of the visual guidelines, c) removing the duplicate efforts on the HTML implementation process, d) verifying the correct output of the static HTML implementations and e) mapping the resulting HTML implementations to the logical branches of the application code.
Although this all seems like such a big hurdle that it seems to invalidate the Template Animation approach on bigger projects, I would like to argue that the awful state of the software projects today is greatly caused by the fact that the projects itself are (and grow to be) much more complex than most people can humanely envision. We take upon the tasks of software specification, implementation and validation as if they were trivial matters, employ inadequate or nonexistent tools and practices to carry them on and are usually left with poor results that grow even poorer when the project needs to be extended by an another team.
In my opinion Template Animation has huge promise in forcing us to standardize some ways in which product designers, visual designers, back end developers, front end developers and software testers communicate with each other. Using the full page DOM as the medium of exchange is a natural path which allows us to use many of our existing tools when interacting in the process. It also forces us to face the real complexity of the problem as each state of the program has to be explicitly recognized to communicate it using a static DOM implementation. And having a tangible representation of each visual state of the program makes it possible to employ easier ways to do visual regression testing.
There are still a couple of small things I envision to be a bit problematic with Template Animation, like how to coordinate on variable names and prevent DOM id clashes in projects that are developed in a distributed manner. Also partial page loads and other highly dynamic “AJAX” content might pose challenges that will make using full page Template Animation hard for some parts of the system. But as a new tool in my toolbox for the right situations, I would gladly welcome an easy way to outsource most of my HTML related implementation and testing tasks while still maintaining the possibility to hook the results into the dynamic back end of my choice.
As a closing note I would like to point out that I have noticed a faint trend in moving the HTML template processing partly or even completely to the client side (at Meetin.gs we have most of our templates on the client side). Parsing the templates on the client side is actually very beneficial for the Template Animation approach as it makes detecting rendered text dimensions a lot easier. It also makes partial content updates less of an issue as the renderer can render the whole page again without transferring the full state of the current page back to the server.