Site Designs

These are a few notes regarding this site’s designs, dating back from the day when this was called mac.against.org. The site used to be three sites in one (Wiki, code repository and photo album), but all three sections followed the same design as much as possible.

In September 2008, and largely due to the move to Yaki, I decided to start all over again and do something completely different, so I put Kubrick aside and unashamedly inspired by Khoi Vinh’s, I proceeded to remove everything from the layout that was not essential to the content itself:

• I removed all color (I did keep a strong blue for links, headers, and horizontal separators). The only exception I made was for code highlighting (which is seldom used these days and makes a lot of sense).
• I standardized on a single font (Helvetica, of course, falling back to Arial and sans-serif)
• Table formatting was pared down to horizontal lines and bold headers only (except in the “See Also” footer, which still relied on gradients to convey information freshness)
• I removed all unnecessary navigation elements (like the page trail, which was a bit redundant given browser history)
• Advertisements were incorporated in the most unobtrusive form possible
• The home page was split into per-day groups, with the approximate time for each entry clearly marked:

1. Blazing, unadulterated speed. In April 2010, I did a series of major changes to the engine, but refrained from doing more than small tweaks to the layout and formatting. But even back in 2008, the site became lightning quick overnight (although I kept messing around with HTTP headers and started minifying and gzipping both JavaScript and CSS into single files to decrease traffic requirements).
2. Readability. Less decoration automatically helped you focus on the content, which still is the whole point of my keeping the site.
3. Elastic layout. This was the biggest design change – the site would always keep the content centered, but it adapted far better to both narrow and widescreen displays without significantly compromising readability (something that Kubrick was unable to do, seeing as it was constrained by the header size).
4. Mobile support. By being radically simpler, it worked perfectly on an iPhone and other mobile devices, and became generally much less hassle to navigate on anything with a browser, and more consistent across browsers.

Over time, I simplified the navigation bar a bit, and eventually added a set of “popular” pages along the right-hand side, the left one being wholly devoted to providing both “breathing” whitespace and entry metadata:

Also, a number of things were outsourced to other sites or removed:

• The photo gallery moved to my MobileMe account to ease maintenance.
• Comments moved to Disqus permanently.
• All my “non-trivial” coding stuff moved to Google Code or similar sites.

• I never seem to be able to come up with the time to code a proper print CSS, which is ironic considering that the layout itself now prints a lot better without tweaks
• I lost the top header as far as running a photo slideshow is concerned, for that would be impossible (or at least very hard to do) with an elastic layout

Still, there’s hope yet – both may be fixable.

I adopted Michael’s design in November 2004 and was so happy with it that it survived two or three platform and engine changes. There were many reasons for adopting it that deserve mentioning:

• The Clear Lake theme was getting too crowded – the sidebars looked like a sky-blue zebra, and no matter what the experts say, sidebars become useless with too much crammed into them.
• Page load and rendering times were starting to border on the atrocious. Even using gzip compression and a fair amount of caching optimization, the home page was not what I would call snappy, and one of the reasons was that there were something like sixteen different images being loaded on it.
• I was doing far too many plugin invocations on each page, which was making it hard to debug and optimize parts of the Wiki internals (this was one of the things I later eliminated altogether in Yaki)
• Text was cramped and not very readable, since I didn’t use whitespace properly. My font choice was also not one of the best.

In short, the site needed a breath of fresh air and improved readability. I also needed to make navigation better – and I chose to do that by making it unobtrusive, and used Kubrick as the basis because:

• I’ve always liked rounded corners and whitespace. Kubrick makes very good use of both, and I didn’t mind changing to a centered layout – when done properly, it works fine.
• I wanted a large, friendly showcase for my photos, and the large header area was just the ticket. Even though the photo album took a while to follow the main site design, it was fun noticing more and more Kubrick-based sites also displaying random or themed header images.
• I wanted to cut down on the number of image elements. Aside from the Kubrick layout, there were zero extra layout-related images on the page, which also helps focus attention on the page header.
• The Kubrick default fonts were a bit more readable. Michael never needed to display source code to the extent I do, so his CSS needed more work there, although I only really got it right after moving to Yaki.
• Cleaning up the layout templates triggered off a number of other internal optimizations – having a leaner display and less plugin invocations per page meant I could focus on optimizing specific pieces of internal Wiki code like SeeAlso and the database routines used by the Index.

• Clearer, more readable layout
• Great photo showcase at the top
• Faster page load times
• Lower bandwidth consumption

• Years later, it still looked (on the surface) much like any other Kubrick-based site. There were, however, three main distinctions, some of which take a while to sink in:
  • The site header – even if the concept became commonplace, the photos are unique, and I tried to keep them so. I was not too crazy about blatant ripoffs of my logo, though.
  • The content – you either come here because you share my interests, or because of stuff like my HOWTOs and references.
  • Navigation (Archives, searching, See Also, Index, the Page Trail atop each page, etc.), which is where real distinction kicks in. The casual surfers and RSS addicts think this is a blog. The regular visitors know it for a Wiki on steroids, and take advantage of that fact to locate things quickly.
• The Kubrick wasn’t thought out for a Wiki. Especially not a Wiki with a couple of other things bolted on. As such, I have made an ungodly mess of it, and it’s become tough to maintain.

This was the previous theme, which focused on delivering enhanced readability and a clear distinction between content and navigation areas. The Flash site header (which downgraded to a random image) used around 70 different images at the time, and provided visitors with a mini-showcase of my photos (the last five of were also displayed as “teasers” in the sidebar with some JavaScript tricks).

The photo album was considerably enhanced, and provided dimmed thumbnails of older photos for those occasions where you feet like clicking around randomly:

It was, however, a bit of a glutton as far as bandwidth was concerned.

Steroids was an experiment in dark tones and heavy, accented headings, done over a particularly bad spot where I had some eye trouble. The most striking aspect of it was the photo album (shown below), which used a horizontal-scrolling photo browser.

I eventually grew tired of the dark design and moved on to Clear Lake, but the photo browser I did for this theme is still one of my personal favorites:

The first theme I did for PhpWiki, it still had a definite Wiki-ish -look with lots of (admittedly unsubtle) inset borders and the original Mac OS X theme’s pinstripe background. The photo section was very basic, and the code did not survive long:

Still, it’s fun to look back that far.