The concept of grid-based layouts has been around since the 1950’s and the first time I came across it was actually in an old book about print design that I picked up while I was in college. Early on, I kind of developed my own conventions with regards to grids and tended to design sites to be 780px in width, since this number leaves enough margin for a vertical scrollbar on 800×600 resolution and more importantly, can be divided in 1, 2, 3, 4, 5 or 6 columns giving you a flexible, symmetric grid design for your layout.

Most e-commerce sites I work on still have about 10-15% of users using 800×600 resolution, but when we built futurevacations.com, the designer we used for the project used a layout that was 960 pixels wide, which from the look of it didn’t look out of the ordinary to me until all the HTML and CSS was done and I realized we might have problems.

Now, I do have to admit that I rarely browse too many web-design blogs these days - its an area that I have been knowingly neglecting the past 6 years since I started developing a greater interest for programming languages and software design. Anyhow, for futurevacations.com, we decided to keep our layout at 960px in width since it gives us more screen-estate to work with and those 800×600 users will likely diminish significantly over the lifespan of the site, so we felt pretty good about how this worked out.

So, the past month after we rolled out the site, I have to admit I was curious to find out why this seemingly arbitrary number of 960px was chosen, but ironically, I was not curious enough to look for answers. Today however, I stumbled across a blog that made a reference to the 960 Grid System, developed by Nathan Smith. Upon reading more, everything started making more sense; 960 is in fact an ideal width for a grid-based layout since it is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. If you are interested, his site contains a download that contains some useful stuff like a .psd and some HTML and CSS to go with it. Enjoy!

I have been contemplating switching to Mako templates for my Django projects for quite some time, partly because I found some of the template syntax in Django slightly awkward.

Today, a question about recursion support in Django templates came up on the #Django IRC channel, which made me think for a minute. Off the top of my head, I couldn’t think of a quick way of accomplishing this in Django, short of using a template tag. However, some examples that I had seen in Mako came to mind, which illustrates the flexibility and power of this templating language.

I decided I would put together some code just to showcase how it could work. The example I chose is to print an organizational chart using the simple Employee class below:

models.py:

class Employee(models.Model):
    name = models.CharField(max_length=64)
    reports_to = models.ForeignKey('self', related_name='employees')

organizational_chart.html:

<ul>
    ${render_employee(ceo)}
</ul>

<%def name="render_employee(person)">
    <li>${person.name}
    <ul>
    % for employee in person.employees:
         %{render_person(employee)}
    % endfor
    </ul>
    </li>
</%def>