I'm Sold on HTML-based Templating

I've finally come around to liking HTML-based templates. I've been a hold-out for a long time but I'm finding it harder and harder to resist the tide and I'm officially calling it today; HTML templates have won.

What am I talking about? If you've done heavy JavaScript developer since, well the dawn of time, you're probably used to creating templates a lot like this:

<script type="text/mustache" id=template">
  <div><span>Hello</span> {{name}}</div>
</script>

This is a hack, always has been. The script tag was never intended to hold arbitrary strings for later processing, but it does, so it's always been a good fit for templates. Then Web Components came around (which I've written about here) and introduced the <template> tag. The template tag brought some major benefits; namely that the content is parsed but not executed. This means that a template can have <script> tags with JavaScript, CSS, etc. and none of it is ran until the template is inserted into the page.

This is great! This means you can define, for example, a custom element and it's template, then have some JavaScript to execute on insert. Then to activate a template all you have to do is use document.importNode and insert it anywhere you like and boom, it's like inserting new HTML into the page.

How Things Changed

The problem with templates has always been that they do not define a data-binding strategy. And for obvious reasons they can't. Can you imagine Mozilla, Google, Microsoft, Apple and others all agreeing on, for example, Mustache as the data-binding language for templates? No way! Never going to happen. And because of that we only get basic HTML. The problem is that basic HTML isn't all that great for dynamic creation. It's just XML, and XML just has tags and attributes. That doesn't have the power of a string-concatenation-based templating language like Mustache.

But it doesn't matter. Angular has shown that HTML-based templating can work. And devs have spoken; we like to put the HTML straight into the page. Adding script tags or importing HTML from a module-loader feels foreign and weird.

So the question becomes, will there be a standard developed around HTML-based templates? Probably not. But there are certainly a variety of patterns that are emerging, such as for-each="items" to iterate a list. One of my colleagues David Luecke released HTML Breezy recently, a Virtual-DOM backed HTML based templating engine that runs in both Node and the browser. So me, I'm sold. My next templating language will be HTML. The <template> tag is too compelling to continue to ignore.

If Books Had Been Invented for the Web

One of my ongoing curiosities is with how to design books for the web. Although there are many good books available on the web, I haven’t encountered one that is more than just the book contents with some <p> tags intermingled. The web has many unique advantages that makes it ideal for reading, but for whatever reason it hasn’t translated to long-form text (anything longer than a single article) very successfully.

Scrolling

Perhaps the web’s most unique characteristic is that documents can scroll, unlike books which are paginated. This is major when it comes to content because there’s a threshold at which scrolling becomes too much. With books you can keep track of your progress easily by which page you are on. Since pages are uniform it’s easy to know how far you’ve gone and to mentally tag how far you want to go.

With scrolling on the web that breaks down. You can still have chapters (although I’m not sure that you should) but that’s not a great unit for tracking progress. I’ve noticed some designs that keep track of how far you have scrolled down the page as you read; I think that’s a good way to give yourself a mental understanding of your progress. Additionally some sites (and I’ve experimented with this myself) have a badge saying how long it will take to read the article. I don’t think this works well if the time is greater than 10 minutes or so.

A key with me with web design is not to reject the unique characteristics of the web, but instead embrace them. Scrolling goes hand-in-hand with the web. Figuring this part out is tantamount to any other aspect if you want to nail the reading experience.

Remember that scrolling is fun. The user should be able to scroll up and down quickly. Keep their place but perhaps only their forward progress.

Custom Layouts

This is one that is completely overlooked by books on the web that I’ve seen. With the web you have the ability to customize the layout of every page; or even sections within a page. Imagine you were writing a story like Lord of the Rings. Within a single chapter (as the user scrolls) you might have a lighter theme while the heroes are in the land of the elves, then a forest theme for when they are traveling through the woods, and finally a darker theme when they enter Mordor. Parallax scrolling is trendy and overdone, but this could be one place where it works.

You have ultimate freedom on the web so you can take this as far as you want. Carefully timed music might be appropriate, and animations are a possibility. Of course you want to be careful not to distract from the story, but that’s an issue with any medium. My point is simply that these capabilities are in play and should be used.

Linkability

Web documents are linkable; in fact they want to be linked. A book written for the web would take advantage of this. An informational book would be full of links to relative resources; there’s no reason to have footnotes when you have the web. If you want to call-out some text a popover would be appropriate for that.

Links shouldn’t be just out, but within the book as well. If referring to an event that took place several chapters back, link to it!

The Web Medium

The web is an interesting medium because it’s an amalgam of all the others that have come before it. If we approach writing for the web as an art-form in it’s own right we’ll better be able to craft pages that come to life and make the web reading experience something that people seek out.

Keeping in mind that the story is most important is key. I wouldn't make a web-based reading experience an "app". Any interactivity should be flourishes that support the reading, so I wouldn't be in favor of persistent UI and almost nothing should be clickable (except all of those links of course). Navigation is not something I've touched on in this article but one that I've thought a lot about. Since we're keeping track of the users progress we can help them jump to the last place they were; but I haven't come up with a good design for this. A table of contents doesn't make much sense either. When you talk to friends about a book you don't refer to "Chapter 12", you refer to "that part where the killer was revealed". In that regard perhaps the contents should be grouped by "experiences some how".