A New Palette

The Palette (aka "How to Justify Green Links")

“sIFR is addictive”

In case you haven't noticed (if that's possible), I have chosen to colour my unvisited links with a shade of green (#009900) not usually seen on any self-respecting website. I've also chosen a purple variant (#6600cc) for my "a:hover".

Normally, I wouldn't stray far from the default link colours (generally some shade of blue for unvisited links, purple for visited links and red for hover/active links) as I'm a firm believer in the Nielsen school of thought on link usability ("shades of blue provide the strongest signal for links"). However, I couldn't find a shade of blue that "worked" with the header image, as far as my untutored eyes were concerned.

So, in a complete break from tradition (for me anyway), I used a colour-wheel to find the complimentary colour of purple. This is the first time I've ever applied science to my web design!

In all honesty, I'm not 100% comfortable with the palette. but it is growing on me. I have also encountered mixed reactions from others - both Noah Slater and Ryan Brill seemed noncommittal when I discussed the palette with them via IM. On the other hand, Mike Papageorge emailed me with the simple message, "Love it!"

What do you think?

Problems with the Logo

Along with causing colour chaos, the header image also posed some problems with regards to the "Urban Mainframe" logo.

Being "graphically challenged", I have always used a textual logo for the Urban Mainframe and, prior to the introduction of this template, I used regular text in my markup to present it. However, when I introduced "Kernel", I switched to an image of the "Urban Mainframe" text as I was horrified by the rendering of non-anti-aliased fonts in my web-browser which was exacerbated by the high contrast between white text and a dark background image. By creating the text as an image with a transparent background, the logo looked much cleaner and, dare I say it, more professional.

The problem with creating text as graphics is that, for the anti-aliasing to work, the text must be rendered against the background image (or colour) that it will be deployed with. If that background changes, the image must be re-rendered. If the background is fairly static then there's no problem. If, however, I were to make frequent changes (and I'd like to), having to repeatedly generate a new logo image would quickly become annoying.

As if this weren't a big enough issue, the problem is exaggerated on the Urban Mainframe because of my use of a fluid design. The new header image is designed to "float" as the browser's window width changes, so that the flower always remains in the centre of the page (resize your browser to see this in action). Thus, the background behind my logo can change, theoretically, with every page request! What I needed was a way to generate anti-aliased text with transparency, on a variable background, on-the-fly and that's where sIFR comes in.

Branding with sIFR

sIFR is generally used by web designers to deploy fonts that aren't guaranteed to be available on the client by using Macromedia's Flash as the delivery mechanism. While I love the technology and the freedom it offers designers, I've never felt the need to deploy it on this website. At least, not until I needed my dynamic, transparent, anti-aliased logo.

Unfortunately, there are issues with transparency in Flash on certain browser/OS combinations. Take a look at the logo in the following screen capture, courtesy of Noah Slater:

The image shows the sIFR "Urban Mainframe" logo rendered in the Mozilla browser on Linux. As you can see, the transparency is rendered opaque on this platform. Not the desired effect at all!

Sadly, there's no way around this - on some platforms transparency just does not work. Because of this, you almost never see sIFR deployed with transparency enabled.

My solution to this problem is use sIFR only on "known good" platforms. I can do this with a little bit of magic from my favourite Apache module, mod_rewrite. Consider the following:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} (Opera|(Mozilla.*Linux))
RewriteRule ^assets/templates/sifr.js$ /assets/templates/disabled.sifr.js

What we're doing here is taking advantage of sIFR's compatibility fall back. You see, sIFR relies on the Flash plug-in. If Flash is not available, then ASCII text is displayed as normal. The same thing happens if the sIFR script isn't available!

Therefore, the code above (which is deployed in either Apache's "httpd.conf" or ".htaccess" files) simply directs requests for "sifr.js" to a non-existent file, "disabled.sifr.js" when the request originates from a platform that doesn't support sIFR's transparency. Because the requested file doesn't exist, the logo text isn't replaced and is rendered as ASCII text.

This is the perfect solution for my logo requirements (short of total cross-browser/cross-platform Flash transparency support). The majority of my visitors, using MSIE, Firefox or Safari, will see the website exactly as I intended. All others will only lose the aesthetic benefits of anti-aliased fonts.

The browser/OS combinations currently known as bad are:

• Opera (I don't know which versions of Opera on which OSs are "bad", so all Opera requests are served without sIFR);
• Mozilla on Linux

sIFR and Hyperlinks

sIFR introduced a new problem into my design. I wanted my "logo" to consist of the word "URBAN" above the word "Mainframe". In order to display this how I wanted, the lower sIFR container is positioned with the top of the container overlaid on the bottom of the upper sIFR container (read that again - it makes sense).

Initially, both words were linked back to the home page. Unfortunately, this played havoc with the mouse pointer on mouse-over. Depending on just where the pointer hit, the cursor would alternate between the link pointer (correct behaviour) and the text pointer (incorrect behaviour). This problem disappeared when the two containers where separated.

The logo is intended to appear as a single component and thus the mouse pointer should always be a link cursor when hovering over the logo, regardless of where the initial contact occurs. I got round this by overlaying a single-pixel transparent GIF on top of the logo, with its dimensions set to match those of the combined containers. The GIF is hyperlinked, not the containers themselves.

I'll admit, this is a clumsy hack. But it works and that's good enough for me.

Still More sIFR

sIFR is addictive. Once I was happy with the logo, I couldn't resist further deploying the lovely, anti-aliased fonts. Thus I have also used sIFR to render all my page titles (h1's) too!

Summary

I've refreshed the design with just CSS tweaks, a new header image and selective sIFR. I've achieved a situation where I can change the header image easily without having to re-generate my graphical logo. I've used mod_rewrite to help me deploy sIFR with transparency for a crucial site component (the logo), with fall-back to ASCII text for non-supported client platforms.

Feedback

I'm really interested in your views on the link colour scheme, so let me know what you think.

I'd also like to expand the list of platforms that can't render sIFR with transparency correctly. So, if your browser/OS renders the "Urban Mainframe" logo without transparency (as per the screen capture above), then please let me know. At the very least, I need to know the browser (name and version) and OS (name and version). If you want to go that extra mile, point your web-browser at the Browser Mirror and let me know what the "User-Agent" is.