Personally I think the new designs are excellent and really appreciate the fact that they address my need to access my Google Apps from a variety of devices. I also like the fact that they allow me my own preference for the visual density of content within the page.

In fact this is such a killer feature that I reverse engineered it to better understand it. I’ll be looking to use this knowledge in some of my future work. Whilst I wouldn’t really refer to this deconstruction as such, plagiarism is the sincerest form of flattery. Unfortunately, due to extensive work commitments, I’ve only just gotten around to writing up my work…

Responsive

It’s my opinion that this technique relates quite closely to the responsive design ethos. The visual content density should respond to both the user’s available screen real-estate, their chosen font-size, and their own preference—which should always override any other external actors.

The majority of responsive design discussions and tutorials seem to talk extensively around how a design responds only to the client width. True responsiveness, however, equates to so much more than this.

Visual density

In this article I am referring to visual content density. This refers to the actual physical space around the content and is not to be confused with keyword density, which is concerned with the proliferation of words and phrases within said content. Balanced visual content density is an important factor towards improved typography, improved legibility, and an improved interface overall. Most designers will wax lyrical on the benefits of plenty of whitespace and how giving content room to breathe can improve the usability of the interface.

The visual density of content within your web-based documents can easily be controlled with an extensive set of CSS properties. However, there are only a few that give entirely predictable results across all browsers:

• font-size
• line-height
• padding
• margin
• width
• height

Importantly, these properties control both content size and the amount of whitespace that surrounds it. Together these two factors can sway the balance between spacious legibility and the efficient use of limited screen real-estate.

A demonstration

Here’s a quick and dirty prototype that I’ve knocked up to demonstrate visual density variance at work. You can vary the density via the buttons at the top, or by resizing your browser window (which will override the former):

http://timhuegdon.com/test-cases/density/

The source code for this example is available here:

http://github.com/nefarioustim/density-demo/

How it works

In my demo I am applying a class to the root element of the document that controls the level of content density selected by the user. I also repeat those styles within media queries for different client widths to allow denser content on smaller screens—try resizing the browser window to watch it respond.

To make this more maintainable in the future I’d probably invoke those styles through some form of SASS or LESS mix-in to cut down on the obvious duplication of styles. However, be aware that the use of CSS preprocessors like SASS and LESS can complicate things when attempting to get browsers that do not support media queries to detect the styles using a JavaScript polyfill like Respond.js.

Summary

So there you have it; a simple technique that has a pretty significant impact to the readability of your content. Hey, and the demo is kinda fun to play with too.

Following a small refactor—guided by some more Pipes-knowledgable friends of mine (cheers Carlo and Dirk)—I privatised my token, and allowed customisation of the GitHub account used.

So, without further ado, here’s the pipe; feel free to use it to stalk your friends on GitHub:

GitHub Friend Stalker

Recently, I’ve been building a new blog platform, in Django, called “nef-blog”. It’s nothing special; just a quick self-build solution that will get me off of WordPress. However, I’m still not entirely happy with it, since it will still be building my blog pages at request time (otherwise known as “frying” pages). This seems like a needless overhead and, for good performance on popular posts (I do have some), will probably still require some form of caching solution. I’d much rather have the choice of implementing a mixed fried and baked solution—where “baked” pages are generated by some form of printing process, and the output is stored on the file system and served at request time.

Several of my peers have also recently been building baking (or “static CMS”) solutions—most of which are available for perusal on GitHub, despite being in varying stages of completion:

• “Lanyon”, by Steve Webster
• “Fallow”, by Mike West
• “Flourish”, by Mark Norman Francis
• “AYM CMS”, by Will Larson
• “Jekyll”, by Tom Preston-Werner
• “Hyde”, by Lakshmi Vyas

This has inspired me to attempt to develop a new CMS; but before I do that, I thought I’d lay down a sort of treatise of things to take into account when designing and developing a CMS. These are simply my own thoughts on the subject, and I’d definitely welcome some discussion; I’d definitely like to be able to update this post in the future with new information garnered from the web developer community.

So, during the train ride into work this morning, whilst staring out the window at an awesome morning mist, my thoughts turned to API’s; more precisely, to writing an application entirely based around an API. I was thinking about how fun it would be to try to write an effective API and then use PHP and JavaScript to manipulate that API to build an application. I also thought it would be an interesting exercise in best-practices; from planning and documentation, through to responsibly using AJAX.

Woah! Where did that come from?

I guess I’m partly spurred on by Jeremy Keith‘s excellent presentation at d.Construct06 entitled “The Joy of API“, as well as Drew McLellan’s presentation “Can your website be your API?” at the last WSG London meet (listen to it via the WSG podcast). API’s are sexy – all the popular kids have them in one form or another; from REST style Flickr and de.licio.us through to the Microformat heavy Corkd. It’s all happening out there and I want a piece of the action.

So what’s the big idea?

As an amateur cook, I’ve recently been thinking about purchasing a scrap-book so that I can collect and collate recipes, however, I’d much rather be able to do this online since I tend to plan meals in my head whilst I’m at work. There are a huge number of recipe sites out there but they tend to be over complicated, drowning in adverts, ugly and not quite what I want – so I thought, what the heck, I’ll write one and try to do a good job! What’s more, I’ll try and work to a Web2.0 ethic and promote a community environment.

I’m well aware that I might crash and burn half way through the process – but since I’m approaching this as a learning experience, I’m going to get something out of it even if it is a few harsh lessons.

What do you hope to learn?

Quite a lot really. I’m interested in improving my understanding of user interface design, of web application design, of information architecture for the web, and, at a technology level, of Microformats and the YUI. I’m also looking to discover new things about the languages I’ll be using; from the potential minefield that is PHP through to the responsible use of JavaScript, as mentioned earlier.

So what next?

Over the next couple of days I’ll start to look at planning the project and I’ll try to blog the process. I’ll also include all my documentation and will hopefully get some feedback (including ideas – let’s open up the floor here).

Hopefully, by the end of this, I’ll have learnt some stuff and created a handy application.