Redux

This site has been around, in one form or another, since 2006. It started out on GooglePages, then Google Sites, then moved to Blogger and finally a couple of months back I decided to move it to my own domain, along with a complete reworking of the site. That's the when and here is the why and how of the new Parallel Transport.

Using the right tools

For a good many years Parallel Transport existed as a blog on Blogger; a collection of some random scribbles, art and photography, and it was quite sufficient.

But, the process of blogging itself was dull, uninspiring, and frankly, quite boring. I wanted to do more. I wanted to make and post new kinds of things. I wanted to design each post, rather than just put words in a static template. I wanted to play with the typography. I wanted the website to be responsive. I wanted to experiment with these new web design ideas that I was reading about.

While I managed to do a redesign on Blogger, it took quite a bit of hacking around their templating system to do it right. I had to resort to some complicated Javascript just to make a simple archive page! It was also completely unmaintainable, with the same code reappearing at multiple places. I realised that I would have to make my own custom setup; free myself creatively from the constraints imposed by Blogger.

Getting organised

The root cause of my troubles was the very restrictive templating engine and CMS. The organisation of content, structural data and themes in Blogger is very simplistic.

The main structure is the template, which contains everything from the raw visual styles for the theme, to the templating code needed to build all of the different pages, along with scripts. The secondary structure is the posts. Here the metadata chunk consists of the title, labels, and a search description. All other things including a thumbnail, a snippet, custom styles and scripts needed only for that post, go into the content chunk. All these different and independent pieces of data are then naively dumped into the final page.

structure of an article page in the old and new site

This final page is not only messy and redundant, but also needlessly large.


The main organisational idea in the new system is to separate different types of data that are related to an article or post into modular units. For instance, the Archives page only needs the metadata about an article, but the page for a particular article needs the content, visual style and more. It is easier to manage and customise these different views if they can pull the appropriate chunks of data as and when needed.

The content of each article is stored in an HTML file while the metadata like title, thumbnail, labels are all stored in a database. Additionally, each article can have its own styles and scripts stored in separate CSS and JS files. This way the content, the metadata, visual styles and interactive parts are cleanly separated and can be handled individually.

Putting it together

To build the final page, the appropriate data needs to be pulled and put together in a page. To accomplish this content jugglary I used the powerful templating system of Django, a Python-based webframework.

In Django, each kind of view has a template that can access the data it needs to render the requested page. It can ask for metadata about an article, some global visual styles, maybe more styles for specific parts of the article, some scripts for the interactive elements. The template then puts these chunks of data in their appropriate places to build the final page.

Django's templates can inherit properties from each other and so the templating code for a particular structure can all be written in one place, and reused. This principle of Don't Repeat Yourself (DRY) makes the code very manageable and easy to experiment with.

This is pretty much what Blogger templates do, but they put everything into one big messy file. And now I have complete control over what gets put in a page. I can make the website small, fast and clean, all the while keeping the code modular and reusable.

Standing alone

In order to make the process of posting more interesting, I decided to tailor each article as a stand-alone. The idea, inspired by magazine design, is that the visual design of each article is adapted to suit its content. This allows me to be more creative with the presentation of the article. A lot of web-designers write this way and the results are amazing.

Having already organised everything in the backend, I can now easily play around with the layout, the typography and colours of every article. This seems like a lot more work than just writing something into a template, and it is. But, I think it is very rewarding. I am not constrained by a visual theme anymore and can actually adapt the look and feel of an article to its message and content.

Articles can have their own unique visual design

Now with my new neat and clean system, this is much, much easier than before. I do not have to rewrite some piece of script or style into every post. I write it once and then insert it into any page that wants to use it. To do this for styles, I use SASS which is pretty much a templating language but for CSS.

Anchoring everything

Though I wanted the freedom for each article to potentially have its own visual design, every page should seem like a part of the same website. I have kept some elements the same across all the pages; the header on top, including the Parallel Transport logo, and the footer on the bottom remain consistent throughout the site. All the visual juggling takes place in the main region in the center. Even so, there is an invisible structure holding the entire layout together.

This is a vertical layout grid designed in Gridset. You can see the grid in overlay using the switch in the footer. Every element, on any page, is anchored to the lines of this grid. Pages like the Archives, use this grid to tile the list of articles, sometimes into an asymmetric pattern. Individual articles arrange the content in their own ways all the while following the gridlines.


Another common theme through the site is the typography. Though each article can introduce its own typefaces into the page, the default typefaces I've used are Quattrocento for the common body text and Josefin Slab for headings and such. Though they are both serif fonts, I think they work well together; I won't pretend to be an expert on typography by analysing this choice. I just like it.

Being responsive

Responsive design, first espoused by Ethan Marcotte, is the idea that a webpage should respond and adapt to the device accessing it. Since the layout on this site is tethered to a grid, making the grid responsive automatically translates to the entire the site. On smaller screens the grid is simple with three columns, and keeps the layout neat. While on larger screens it becomes more complex and allows for more interesting layouts. You can see the details of my grid over at Gridset.

Layout grids for small to huge viewports

Another aspect of responsive design is having flexible images; displaying images that are appropriate to the size of the viewport. There is still no good way of doing this within HTML, and is the subject of much debate. In the meantime, I insert all the images using a custom Django template. A Javascript then calculates the appropriate size for the image and inserts it dynamically into the page. This template also has a fallback image in case Javascript is unavailable. If a solution is finalised in HTML, I can make a change in the template and implement it across the entire site; it's scalable thanks to Django's templating system.

Enhancing the content

The best feature of the web is that it is open and accessible to everyone. This means that everyone should be able to access the core content of the website, regardless of their device or browser; styles and scripts should act as an enhancement and not a necessity. This is progressive enhancement. A faulty Javascript should not prevent you from just reading the words on a website.

Progressive enhancement: a stopped escalator is just a staircase

Having a neat separation of content, metadata, style and scripts, goes a far way in following this principle. All the content is markedup in HTML5, and I try to be careful about semantics. So the same content is accessible to browsers, screen readers, feed readers; in contrast with the old Archive page and the new 'themes' in Blogger, where the page is built using Javascript; failure to load the script or a single error in it, blocks the entire content.

An example of this is the resposive images implementation. If Javascript is available, you get a scaled image appropriate to your device, otherwise you still get a default image. Admittedly I have been lazy at some places. The grid switch only works with Javascript on, but I fully intend to rectify this.

Looking ahead

The truth is I did not have to do most of these things. My blog wasn't very popular or widely known. I do not expect a lot of readers to have Javascript turned off, or use screen readers or even be on a slow connection.

I mainly did this redesign, for myself. To be more creative, learn new things about the web and work with the fascinating ideas that I had only read about. Because of this the redesign is very much a work in flux. I will continue to play around with this website. Here are a few things I am thinking about:

  • Some sort of commenting system would be good. I don't like third-party systems as they all rely on scripts to work and seem very slow. A very exciting proposal I just read about in this context is webmention.

    Edit: Webmention is now active. You can use the form at the end of each article to send me a link to your response. For more on this read: No comment.

  • I want to improve the feeds. Right now, feeds only contain the thumbnail and description with a link to the original article. I want to send entire articles through feeds.
  • Implement some kind of search tool.

The beginning

Now that most of the redesign is done, I am looking forward to writing/doing more here. There have been quite a few ideas that I wanted to write about and now I have a constraint-free place to put them. So …

In the beginning …