About

Some thoughts on templates...

Template Blocks was started by Makis Tracend - an experienced web developer that lives in Sydney (Australia). Below is a set of personal ideas that drove this project and are expressed in a direct form as they do not necessarily express the beliefs of anyone else:

"..

Web design is the most important part in the front-end development and how well the web page is structured and the CSS is organized defines the whole experience for the end-user that visits the site. As people say "it's all about first impressions".

Yet, the markup is always placed second to coding and there is not one template engine out there that hasn't been written by a coder and requests users to get into the programming logic to create something as visual as a template. At best you will have to deal with a bunch of semantics that "describe" the markup. This is totally inefficient, as semantics require the user to apply two sets of logic for the same element - one for creating the semantic structure and then trying to imagine how that is going to be translated to markup.

Semantics don't help - they confuse

Most template systems also require exclusivity, so if you are going to use one engine you will be required to pass everything through it. This brings unnecessary barriers when you have a content source outside the engine, for example an open source script. Using open source scripts with template engines is something most simply don't support.

Another big flaw of most template engines is their size. Trying to fit everything in their proprietary structure and logic only makes them scale into enormous proportions. Some of them literary take over the root of the website and the user is left hopeless trying to combine his web assets with the template files, most of which he'll probably never know what exactly they do.

So what are the alternatives of using a template engine? Many have brought forward the "all-in-one" solution where the template engine becomes a component of a bigger structure that actually handles everything on the website, the most popular term for describing them is "Content Management Systems" (CMS).

And again we are faced with the same reality. Proprietary logic, over-sized structures and exclusivity. On top of that add restrictive modification capabilities and the most provocative mix of code and markup, within their functions.

A CMS is an extension of a template engine, trying to blur it's limitations by providing the users all they would ask for beforehand.

I personally have used commercial and open-source CMSs for a long time. I really believe in the idea that web publishing should take place online and have welcomed the improvements in their interfaces over the years. But the truth of the matter is that once you select a CMS for your website you are left stranded with the features that CMS has.

This limits the control you have over YOUR website. And what if that all-in-one tool can't do everything you want? If for example you wish to add a wiki section to your site and there is no wiki addon for your existing system you can use. Should you rely on second rate solutions or the good will of other developers? Or will you simply create a separate section for your wiki pages and try to simulate the same interface for those pages?

Unfortunately this has been a controversial matter for many website owners. And most of them actually decide that having another separate application (forum, wiki etc.) installed on the same site is the way to go if it will do what they want better.

This jeopardizes the use of a template engine as an integral component of the CMS all together. Why should you have to create the same template again and again for every script you have? Even if all of your applications have perfect template engines applied to them (which they most likely don't) repetition of code only means one thing: tedious updates. Every time you need to change your template you will have to do it as many times as you've applied it, while trying to output the same result on different working platforms.

A web designer excels when he operates on a single platform. And the platform has already been defined by the W3C.

After all these years of using open source scripts I think we can all agree that:

  • Open source scripts are one of the best concepts found online.
  • Not one open source script is ever enough.
  • Open source scripts have trouble adjusting to an existing web structure.

All this brings forward once more the idea of a unified template engine. Why not have an engine that draws the interface and lets the other scripts output what they are really there for - the content. Why not let the users create the interface they really want without trying to restrict their actions, supposedly to protect them from their own mishaps?

These ideas were the driving force for me to step forward and create this template engine. I was confident I had crystallized in my mind (over the years of web designing) the logic that a good template engine should follow but the implementation was a whole different matter.

Oppose to popular belief, creating something simple is actually harder than creating something complicated.

I took a step back and noticed that everything was actually there: the scripting language is powerful (PHP), the markup language is fluid (HTML-CSS) and the web standards are well defined (W3C). There is no need for semantics, there is no need to re-construct what's already created, there is no need to limit the user into doing things a certain way. I would just have to compile together (somehow) everything already there...

Usually when you create an online application you first deal with the back-end issues and leave the front-end at a later stage. In this project, being a web designer's tool, I kinda used reverse engineering - analyzing the logic I had built as a web designer and then trying to apply that logic to the application.

One of my intentions from the start was to create a tool that would be simple to use yet would not be limiting in any way. I also had high hopes for the back-end to be clean, meaning:

Complete separation of markup, code and content on a back-end level.

For the administration interface I tried to formulate the logic into a visual environment with floating elements, again in an effort to give focus to the logic of the web designer and not the needs of the programmer. This led to the creation of the block elements that can move around when creating the template, hence the name arose: "Template Blocks".

Another big goal was for the engine to be able to wrap around any open-source script (or any script for that matter). It's something I wanted for my websites and something that would be regarded as an asset for the engine, instead of just using the content that is driven through it.

And all this should operate from one self-contained folder. I named the folder "template" and stored everything there, so the users would know where to look for the template elements when needed and always be able to distinguish them from the rest of their personal files.

But above all this project aims to bring back the fun in web designing. Most of us web designers got into this profession from the excitement of the things we could do online. It's a shame to be dragged down by repetitive, mind numbing tasks.

Web designing can be fun - Let's get rid of the tedious work and focus on the creative fun stuff.

As a last note I'd like to say that I give this back to the open source community with great respect and in the hopes that it will help people create web templates easier and in a more unified way.

.."

Thanks for reading and we hope you like Template Blocks as much as we do.