Thoughts on templating

Goals

• Output of the design process can be reused in the development process
• Changes made to the HTML after the initial design process are automatically reflected in the development environment
• As much based on standards as possible to make the solutions future proof
• A solution for design time templating: Changes made to a component/widget in one central place are reflected in all instances of the component automatically
• A solution for run time templating: The ability to populate variable or repeating components based on a separate data set. This data set could be a stub during the design process (For instance in JSON format) or a real service in a production environment
• Designer friendly

Some inspiration could be drawn from the W3C Web components standard. The standard is in draft and very new so probably not useful today in a production environment. Yet it's concepts cover most designers' needs and easy to learn.

The nice goodies from Web components through a designer's eye:

• Component templates in separate files
• HTML based syntax
• Option settings per instance
• Slots
• Content

Component templates in separate files

Having components in a separate file is a prerequisite for design. It should be possible to change components in one file, save the file and then see the instances of the component updated on various screens after a refresh.

The component template should — as is the case with a web component — contain two major sections. 1) An area that contains the markup structure of the template, 2) An area that contains a list of the component's options (variables) and their defaults.

Web components have this, albeit not in a pretty form. The HTML template part is pretty. It's fit between <template> and </template>. But the option declarations are fit between <script> tags.

The solution for templating in Patterns should ideally also have this separation in the template files. Preferably not with a script tag containing a JavaScript array for the variables though, but probably something more CSS like. For instance this way:

required {
  label: Required;
  type: boolean;
  values: required;
  default: off;
  description: Use this variable to make the form field required to the user.
}

category {
  label: Category;
  type: discrete;
  values: category-a, category-b;
  description: Choose from category-a or category-b, depending which category your user falls in.
}

width {
  label: Width;
  type: integer;
  values: 1, 3 - 6, 8, 9;
  description: Set the width of this component in number of columns it should spread. Only the values 1, 3 - 6, 8 and 9 are allowed. 
}

id {
  label: ID;
  type: string;
  description: Type the ID of the component if it requires a special ID for styling purposes. 
}

In the above examples, the 'selector' is the actual property that would be used in the data-pat-template attribute.

The type indicates what type of variable it is. There is the type 'Integer' (an integer), 'Discrete' (enumerated, could also be called such) and finally 'String' for strings of arbitrary characters.

The description is basically embedded documentation from the designer of the component template for designers who are going to use the template.

HTML based syntax

With the web component standard each component templates is called through a link:

<link rel="import" href="my-component.html">

After including the template, you can stamp out the template on the page:

<my-component></my-component>

All of the above feels very familiar to designers who already write HTML, but typically no JavaScript.

One thing I like less about this system, is that when you use a lot of components, you also have to write a lot of template includes. It would be nice if that could be implicit in some sort of way. For instance by inventing a meta tag that tells what the location of the templates is. The filename of each template should equal the element name itself.

<meta name="templates-location" value="/components">

It could be a good idea from a designer perspective to utilise this very compact and HTML-kind of way to include components. There are however also disadvantages: HTML doesn't validate. However, since web components will allow for custom elements in the future (as long as there is a dash in it), this could be less of a problem in the future.

Option settings per instance

Another thing that's nice about web components is the option settings per component instance. For instance: If a template contains somewhere the variable {{ myVariable }}, then this variable could be replaced by a chose value in the instance by putting an attribute on the element.

<meta name="templates-location" value="/components" myVariable="Some value">

As a result, each instance of {{ myVariable }} in the instance would be replaced by 'Some value'.

Another important instrument for designers is switch entire parts of a component on or off on an instance basis and in design time.

For instance, should a template contain an element that has the attribute if="myOptionalRegion" on it, then this element would only be visible on the instance if the instance would have myOptionalRegion="True" on it. This mechanism is highly import to have in a design setting and also to create generic enough reusable components.

Slots

It's often desired to fill a certain part of a component, which I like to call a 'slot' with other components or just arbitrary HTML.

In web components this is solved with the content tag. To designers 'content' usually means a cluster of data intended for human consumption, but in the cases of web components it's actually arbitrary HTML, which could contain more web components.

If a web component contains a tag ` in it, then anything between the opening and closing tag of the instance element will be put in the content tag of the stamped out template.

Something similar would be necessary to have with Patterns templating as well. It might be desirable to have a solution that would allow for multiple slots per component.

Content

…