One of the sites I've been working on for almost a year now has gone live: National College for Leadership of Schools and Children's Services. Responsible for markup, styling and scripting, the site went through numerous visual and requirement changes before the current layout and design was settled upon.

Starting in November 2008 with the then named NCSL (National College for School Leadership), the number of templates could be counted on two hands and script components were non-existent; since then the brand and colour scheme have changed, a font replacement library has been implemented, upgraded then changed (sIFR version two, then three, then Cufon), script components now include tabs, social bookmarking, tooltips and a fully-featured carousel, and the number of templates has ballooned to encompass a wide variety of pages including a number of member-only pages most site visitors will never see.

The client had a very strict set of requirements regarding accessibility, usability and aesthetics, the site was a great challenge and it's brilliant to see it go live. With it now out in the wild, it's a good opportunity to examine just some of the  notable aspects of the project.

Read the rest of this entry

The newest addition to chaostangent.com is the carousel nestling comfortably at the foot of every page. Sporting a variety of "social media" feeds as well as other morsels, it showcases a number of interesting technologies and techniques including: a fully looping carousel (JavaScript and CSS), integration with numerous external APIs (PHP, Zend Framework), screen-scraping and local caching of results to name but a few. It successfully fulfils the primary goal I had for it: cramming as much functionality into a contained a space as reasonably possible.

JavaScript

The carousel interface is design du-jour at the moment - sported by sites such as Apple, BBC iPlayer and Gametrailers - they manage selective display of information while still providing a high degree of interactivity. In short: they're swish and solve the problem of too much to feature in too little space. The carousel library I am using is a simplified, stripped-down version of one I developed for a large work project - for this reason I'm unable to release it under any kind of license. The original has a number of features that I wouldn't be using including automated construction of a "jump to" control and being able to navigate over a number of entries at once. My library is the only one I know of which successfully loops, providing an "infinite" carousel of sorts; other publicly available libraries cease at either end of the carousel which in some situations is more intuitive but the challenge of making one not do this was posed to me, and I couldn't very well pass it up.

Read the rest of this entry

These are some of the neater parts of gallery.chaostangent.com that don't warrant a full exploration on their own but serve the goal of making the application more streamlined. I've crafted these examples to be focused so they don't contain superfluous details like error checking, timestamp columns and the like.

Database

The gallery schema is as follows:

CREATE TABLE IF NOT EXISTS `galleries` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `left` int(10) unsigned NOT NULL default '0',
  `right` int(10) unsigned NOT NULL default '0',
  `parent` int(10) unsigned NOT NULL default '0',
  `title` tinytext NOT NULL,
  `directory` tinytext NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `parent` (`parent`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 ;

This covers both the Modified Preorder Tree Traversal (`left` and `right` columns) model as well as the more standard hierarchical model (`parent` column). I'm still undecided as to whether indexing the `left` and `right` columns provides any benefits. Most of the queries on the gallery table involve getting the direct children of a particular node; the breadcrumb trail at the top of the page however is built using the `left` and `right` columns:

SELECT * FROM `galleries` WHERE (`left` >= ?) AND (`right` <= ?) ORDER BY `left`

Doing a multi-column index in MySQL works from the left column onwards, so for the above query, indexing on `left` and `right` would be a benefit. However when inserting and deleting nodes, queries are done singularly e.g. one for `left` and one for `right` which having an index on one and not the other may turn out to be detrimental in terms of update times. I could always do two indexes:

ALTER TABLE `galleries` ADD INDEX ( `left` , `right` ) ;
ALTER TABLE `galleries` ADD INDEX ( `right` , `left` ) ;

This runs the risk though of having a table that's more index than data. I haven't done a full benchmark of the different queries for each scenario but I would imagine only for large trees would indexing provide any tangible benefit.

Read the rest of this entry

Forms are perhaps the bane of web development for me; you can't get them to look good, you can't find a foolproof way to make them act well and lets not even start of trying to get them into a pacified state, free from the dangers of user input (surprise ending: form input will never be completely trustworthy). A lot of sites would appear to have aesthetically pleasing forms, however this is a careful ruse by them as they sidestep the problem of forms by having only one or two of them, and then they usually only have a few fields. The monstrosities I am required to deal with almost daily are things of grotesque beauty, veritable Rube Goldberg machines of complexity.

Read the rest of this entry