The Mechanical Turk

Ian may claim to be doing nothing but git-work (and what an unfortunate name that is), but the fact of the matter is that we’re both eyebrow-deep in client work. This business has been running since April 1999 & we’ve never been so busy.

When you’re so busy, the last thing you want is a series of bugs that won’t seem to go away. Since most of my work is in the HTML/CSS/Rails templates realm, I’m speaking mostly of visual bugs, things that seemingly won’t budge no matter how much time you put into them. I thought I’d share two tips which have helped me squash a considerable number of visual bugs, one created by someone else & the other merely a process that I follow.

CSS Debugging Tip 1: Burn it all to the ground

First, the work supplied by someone else: Eric Meyer’s CSS Reset. If you’re unfamiliar with it, go & read up on it ASAP. For those unfamiliar with why you’d need to reset something your CSS, the answer is simple: different browsers have different default sizes for fonts, lists, buttons & a hell of a lot else. By resetting all these items via CSS, you help ensure that all your browsers—Safari, Firefox, Opera & the thorniest of them all, Internet Explorer—start from a common vantage point.

The idea is not new. For years I’ve employed a very basic, simple reset:

  html * { margin: 0; padding: 0; }

The problem is that this didn’t reset nearly enough things—and it often didn’t even reset everything it was supposed to! Eric’s reset is a total razing to the ground of all browser-specific sizing quirks & as such should be adopted by every designer. In my experience, it’s particularly useful for a project that you’re just starting up: my IE-specific stylesheets are a fraction of their former size. For pre-existing sites, however, it’s not going to be a magic bullet. You still assembled your CSS based on different assumptions & short of starting from scratch, it will be of more limited use (although still recommended in my book).

CSS Debugging Tip 2: Build it back up brick by brick

The second tip is merely a process that I’ve been following. I’m surely not the first person to do this, but since it doesn’t appear to be widely discussed I thought I’d write it up here.

I’m going to take a real-world example from a site we’re building. In this site, we’re using some Scriptaculous effects to aid in the creation of a visually compact secondary navigation for a database of imagery. The markup is simple:

    <h4>Section Heading</h4>
    <a href="subsection/1">Subsection 1</a>
    <a href="subsection/2">Subsection 2</a>
    ...

Clicking on the H4 tag will cause the subnavigation links to reveal themselves, or hide themselves if they’re already revealed.

Unless you’re viewing in Internet Explorer 7, that is—no, the problem for once isn’t IE6! In IE7, the links were invisible—they were clickable, but you couldn’t see them.

I tore out what little hair I had left, for weeks, trying to figure out this bug. I even thought it might have been Scriptaculous’ fault. It wasn’t, however & eventually I realised I was compounding the problem by adding CSS declarations instead of removing them—instead of trying to figure out what was triggering the bug, I was trying to pave over the bug. If you’re adding more declarations in order to fix a bug, you may very well be creating a shifting target, which is definitely not what you want to be doing. Particularly when you have a lot of other work to do.

The answer is just a process & a very simple one at that: take your CSS declarations & strip them out. Add them incrementally, viewing in the target browser every time, until you trigger the bug.

In the example above, removing a declaration of a:link { display: block; } rendered the links visible again in IE7. I don’t know why—I’ve used this declaration countless times with no problems—but nevertheless the declaration wasn’t necessary & it was causing a big problem.

Again, though, it’s the process of stripping away your CSS & then re-implementing your declarations which is the key. It’s all too easy to add more & more to your declarations, but remember: you may only be making the job of fixing your problems worse.

You may have heard of the Dynamic CSS resolution switcher from Particletree, it's a neat bit of js that allows you to specify different css files depending on the browser resolution.

We love this script, but we had problems running it with Safari, and we are using prototype, so we wanted to make use of its goodness for the browser independent stuff.

So, if you're already using prototype, the following script achieves the same effect as the original particletree script. It also uses the dom:ready event, which fires after the dom is loaded, but before the screen is drawn, so you shouldn't see any 'twitch'.

Example

In the following example, we have three stylesheets that correspond to browser widths as follows:

  thin      up to 1020
  wide     1021...1400
  widest    above 1400

For non js users we want to default to 'wide' (the middle one). In order for this to work properly, we disable all of the non-default stylesheet links.

In your html

In your html you need to link to the three stylesheets, give them each a title attribute, and disable the ones you don't want non-js users to see.

  <link title="wide" href="/stylesheets/wide.css" rel="stylesheet" type="text/css" />
  <link title="thin" disabled="true" href="/stylesheets/thin.css" rel="stylesheet"  type="text/css" />
  <link title="widest" disabled="true" href="/stylesheets/widest.css" rel="stylesheet" type="text/css" />

And link to the script, we'll call it dynamic_css.js

  <script src="/javascripts/dynamic_css.js" type="text/javascript"></script>

The script

This is the script, it uses the title attribute of the stylesheets to disable or enable them. It is run when the dom is ready, and when the browser width changes.

// DYNAMIC RESOLUTION SWITCHER
// Originally from ParticleTree
// Simplified with Prototype by Ian White of Argument from Design 2008
// include prototype.js (>=1.6) before this file

// you need to edit this function as per your situation
function applyDynamicLayout() {
  var width = document.viewport.getWidth();
  if (width <= 1020 )                 { applyStylesheet("thin") }
  if (width > 1020 && width <= 1400)  { applyStylesheet("wide") }
  if (width > 1400)                   { applyStylesheet("widest") }
}

// you shouldn't need to edit past here
function applyStylesheet(title) {
  var i, stylesheet;
  for(i=0; (stylesheet = document.getElementsByTagName("link")[i]); i++) {
    // is it a stylesheet with a title attribute?
    if(stylesheet.getAttribute("rel").indexOf("style") != -1 && stylesheet.getAttribute("title")) {
      stylesheet.disabled = true;
      if (stylesheet.getAttribute("title") == title) {
        stylesheet.disabled = false;
      }
    }
  }
}

//Run applyDynamicLayout function when window is ready and when it resizes.
Event.observe(document, 'dom:ready', applyDynamicLayout);
Event.observe(window, 'resize', applyDynamicLayout);

That's it!

That's it, it works for us in Safari, Opera, FF and IE 6 or greater.

Also, you can have as many stylesheet links as you like with the same title. For example, let's say you have some IE6 specific kludges for the 'thin' layout. You would do this:

<!--[if lt IE 7]>
  <link title="thin" disabled="true" href="/stylesheets/thinie6.css" rel="stylesheet" type="text/css" />
<![endif]-->

Since 2005, 24 Ways has been a great collection of web design tips & tricks in an “advent” format (i.e., one article per day in December before Christmas). This year already looks like it’s going to be a great one. Drew McLellan has a great opening article on dealing with transparent PNGs in Internet Explorer 6 & 5.5 (yes, many of us do have to factor in those old browsers in our designs).

This comes at a great time: currently we’re working on a site that uses 24-bit PNGs with alpha transparency, and as Drew says, the common solutions to the issue don’t help you when you want to use that type of PNG as a background image. He also mentions that it’s a big problem to use such PNGs behind a form—because of the way IE6 & earlier deals with the PNGs. IE effectively puts another layer on top of the area you’re looking at—meaning that form inputs are completely inaccessible. This is a problem not simply for forms, but indeed potentially for any design where you’re playing with positioning. For example, we’ve got an organisation’s logo dipping slightly below a masthead, spilling onto the crumbs bar below. Any links that happen to be in that PNG’s area were completely inaccessible, too. Our solution was to set z-index for both the #masthead img & #crumbs. Drew’s solution is better, however—it’s far more set & forget.

Recently I mentioned that I use Safari Tidy—a plugin for Apple’s Safari browser. I thought I’d shed a little light on why I think it’s so great.

For years now individuals—Jeffrey Zeldman most prominent among them—have been evangelising the use of standards-based (X)HTML. There are vague reasons for supporting standards, like getting the warm & fuzzies for doing so; there are abstract reasons, such as preparing work properly to be handed over to a successor; but a very real & immediate reason is that you have a very firm basis upon which to work. It’s all too easy to make mistakes in the semantic properties of HTML, which can yield disastrous rendering results in browsers. And it’s all too easy to not see the problem until late in your design process.

Safari Tidy is unobtrusive & always on: you’ll see that an error has arisen immediately, so you can go fix it. Other implementations of Tidy aren’t so automatic—you have to physically check your markup’s validity, which often means that you don’t check—this is what makes Safari Tidy so fantastic.

I’ll illustrate with a real-world example (one upon which I’m currently working, in fact):

Many out there will be aware of the generating capabilities of Ruby on Rails. A good explanation of this is beyond the scope of this article, but suffice to say you can build the general building-blocks of a web application very quickly, such as setting up a new user in a system. Here’s a rudimentary example of a ready-built form (linked to the users controller). It’s to be rendered in XHTML:

  <% form_for(@user) do |f| %>

    <p>
      Login:<br />
      <%= f.text_field :login %>
    </p>

    <p>
      Email:<br />
      <%= f.text_field :email %>
    </p>

    <p>
      Password:<br />
      <%= f.text_field :password %>
    </p>

    <p>
      <%= submit_tag %>
    </p>

  <% end %>
  

The result of all that <%= f.text_field :foo %> is to create form tags, such as input. Here’s what the above gets with the Login example:

  <p>
    Login:<br />
    <input id="user_login" name="user[login]" size="30" />
  </p>

So far, so good. But what if the user hasn’t filled out a field & you have to display associated errors? Simple in Ruby on Rails. Assuming validation has been set up in your users controller, just add the following bit in front of your form:

  <%= error_messages_for :users %>

With this in place, if your user doesn’t enter a required field, or enters a required field incorrectly, then Rails will automatically inform the user of what was wrong (in the location of the <%= error_messages_for :users %>). Moreover, it’ll wrap the offending field to highlight the user’s attention to it. It will look like this:

  <p>
    Login:<br />
    <div class="fieldWithErrors">
      <input id="user_login" name="user[login]" size="30" />
    </div>
  </p>

And now we have a problem. A div can contain a p, but cannot be contained within it. This is where Safari Tidy comes in really handy. When you test your error message (as above) by viewing it in Safari, Safari Tidy will inform you of an error in your markup. The error it makes is somewhat cryptic:

  <p>
    Login:<br /> 
    <div class="fieldWithErrors">
      <input id="user_login" name="user[login]" size="30" type="text" value="" />
    </div>
  </p>
  -----
  Line 85  Warning: inserting implicit <p>
  Line 89  Warning: trimming empty  <p>

What’s going on here? Since a p can’t contain a div, Tidy thinks you’ve not closed your p tag before you started your div. In addition, it thinks you haven’t opened your p after you’ve closed your div tag. Certainly, knowing your XHTML helps in this situation, since the error it throws is otherwise cryptic; but Tidy gives the clue where to find the error. On a form with a lots of fields, this is really helpful.

Safari Tidy helped me note there was a problem before I even realised that there was a problem—and there really was, the error screwed up my pretty design horribly.

Update: What a wally—I got so wrapped up in Safari Tidy that I didn’t explain how to fix the error! There’s a simple solution: convert your p tags to divs throughout. I don’t know why Rails screws this up in the first place—Rails seems to have been designed pretty well & this is a glaring oversight. It’s really bothersome to have to fix every automatically-generated form.

If you’re running the newly-released Mac OS X 10.4.11 update & are having lots of crashes in Safari, then the likely culprit is going to be items in your ~/Library/InputManagers/ path. Some popular Input Managers include:

• Application enhancer SIMBL
• Safari enhancer Saft
• X/HTML validator SafariTidy
• TextMate bundle “Edit in TextMate”
• The Safari plugin for the password manager 1Password

SafariTidy was the culprit for me. The developer, Kasper Nauwelaerts, has upgraded this to 0.2.4. I’ve not yet been able to successfully install the update, however—Safari just isn’t recognising its existence.

Input Managers act as a patch to the applications for which they’re intended, and as such are unsupported—even actively discouraged—by Apple, because they can patch applications in dangerous ways. Those of us who rely upon such items—as I am to Safari Tidy, so I can validate my work on-the-fly—are in something of a quandary. As Daring Fireball’s John Gruber implied regarding input managers and unsupported software, this situation isn’t going to get better but worse as time passes.

SafariTidy’s useful validation features: how can it be made a better OS X citizen?

Because the use of the InputManager system is so bad, I’m left wondering what’s the best recourse. Tidy is really useful & there are extensions for Firefox, but none are to my mind as elegant as SafariTidy. I’m left hoping that Kasper will port his plugin to a different architecture…

Update: I just got some tips from Kasper & some very good news:

…You should put [SafariTidy] in the SIMBL plugins folder, which usually resides in ~/Library/Application Support/SIMBL/Plugins/. Please remove all traces in any InputManagers folder you put the bundle, as this plugin isn't technically an InputManager (anymore).

Three cheers for Kasper! I’ll be donating to him right now.

Book cover design is close to my heart—if you’re an avid reader, it’s nice to have a really attractive cover to the book you’re reading. Joseph Sullivan of Book Design Review publishes his favourite book cover designs of 2007.

From his list, my favourites are “Small Crimes in an Age of Abundance” (above, designed by David Drummond), “Six Degrees” (designer unknown), “One Perfect Day” (designed by Evan Gaffney), & “Brave New World” (designed by Greg Kulick). Of course I’m also very fond of “Simple Sentences”, but since I designed it I might be biased!

There’s an interesting article in Design Observer about the fairly recent trend in ugly design—nasty colour combinations, stretched type & a lot of other characteristics considered no-nos of good design.

The development of this style—perhaps we should call it “anti-design”, even though its proponents claim it’s the hardest work they’ve ever done—seems to be a reaction to the prevalence of overly-clean (and potentially overly restrictive) design as covered in the documentary Helvetica.

Michael Bierut makes a good point about negative reactions to the design:

If you’re familiar with art and design, you know the perils of condemning the shock of the new. After all, no one wants to risk being one of the bourgoisie sneering at the unveiling of Les Mademoiselles D’Avignon (sic) or booing at the debut of Le Sacre du Printemps.

I’ve always disliked people who try to paint critics with such a brush—it’s a response calculated just to shut you up, not to provoke any debate. But it’s one thing to be provocative in your work & quite another to be heedless to anything that’s actually attractive.

Time will tell whether this new trend—redolent of the early days of PageMaker & Quark design with its “ransom letter” font choice & squeezed typography—will actually last. I can’t help but wonder why we’re caught in this same spiral of reaction & counter-reaction: restrictive design vs. unfettered, even unschooled, design. We’re stuck learning & un-learning the same lessons: we’re fighting old men’s wars. After all, it’d be nice to create something new, wouldn’t it?

After a long gestation period, we’re now unveiling the new look—and engine—for the Mechanical Turk.

The look

The basis for the new look is of course our corporate site with a few tweaks. The masthead is based upon the back of our business cards—we are very fond of our bonsai logo.

We also took the opportunity to widen the display from our corporate look—there’s a lot of evidence that shows 1,024 x 768 pixels is now the most common resolution. In due time our corporate site will also reflect this wider presentation—which might be good, because we know the site is a bit text-heavy. Perhaps the change will make this appear less of a problem!

The engine

Previously, we had used the Typo engine for our blog. It’s lightweight & has some nice features, but despite using the most recent release, we found it to be very unstable. For instance, if I discovered, after posting, that I had made a typo (ha ha) & I corrected it, Typo’s lighty processes would eat up all the resources on the server, grinding everything to a halt. After restarting lighty processes four times in a day, we just decided that enough was enough & that we needed to switch.

But to what? If you want to run a blog on Ruby on Rails, it appears that there are three contenders: the aforementioned Typo, SimpleLog & Mephisto. While SimpleLog looks really nice, it appears that it does not have a big developer community. Mephisto does, even though there are a few worries about its future development. Apparently there is now a core team for Mephisto, so perhaps it’s got a new lease on life. Time will tell. In the meantime, Ian has tinkered under Mephisto’s hood & when he has a moment (ha ha, aren’t we funny?), perhaps he’ll write a bit about what he’s done. We are considering releasing some Mephisto plugins as well—again, in time.

The name?

As noted in the comments to my second post on the blog, we are considering a new name. We’re coming around to a name revolving around “falling leaves”—suggested by the image of the bonsai on the masthead. It’s also somewhat evocative of the nature of blog posts—posts fall when they’re ready and… OK, I’ll shut up already.

Finally, I’d like to publicly thank Ian for taking time out of his horrendously busy schedule to help get the new blog engine running so smoothly.

We have a client that is part of a large institution (both shall remain nameless to protect them). Like many in such cases, they’ve had a CMS thrust upon them. I won’t name the CMS, but you might be able to figure it out from this screenshot:

Behold in all its horror!

Look at this from a user’s perspective. OK, we’ve got a nested system of some sort. What are the radio buttons for? We can also delete “publication details” (notice the wastebasket at the right). Below the wastebasket is a tickbox. What does it do? And do you dare click it? How about the “temporary save” button—why is this not automatic, as in online apps such as GMail & Basecamp?

Let’s look at another example:

“Once more”? “Switch”? WTF?

This second screenshot comes from further down the page, from a list of publications. Clicking the “Switch” button lets you move the publication up or down the list; when you do this, the page reloads. It would reload every time you moved the position of the item (average page refresh time: 30 seconds).

Now imagine that you’re re-organising a list of, say, 20 publications so that the most recent publications come first in the list—a not uncommon task. Imagine that, previously, the publications were listed in order of publications (i.e., that the oldest one was first). To just move the latest publication, you’d have the page refresh 20 times. After each refresh, you’d have to scroll down the page to find the publication again so you could move it up one more position. Imagine that you have to re-order several pages’ worth of publications: now do it a million times!

After doing this for a couple of hours, finally imagine saying “Fuck it, it’s not worth the effort”. You have now reached the position of my client—and, indeed, the position of many people who have had CMSs thrust upon them.

A lot of things have gone wrong here. At my bitchiest I’d say that these screenshots showed the unholy marriage of Windows 1.0-style software design with all the flair of a Linux user interface. How did it come to this? Why was this software chosen? How do you get out of this situation?

I don’t have an answer to that last question, unfortunately—large institutions make their decisions on behalf of all departments & it takes years to move such a big ship. But I know how others can avoid this.

Let’s gain some perspective: CMSs became a big thing before the dot-com bubble burst in the early 2000s. They were designed for the browsers of the day—Internet Explorer 4 & 5, perhaps even Netscape 4. Any web developer will tell you that these browsers are pretty limited—and that support of legacy browsers quickly reduces the options you have to design an intuitive interface, progressive enhancement techniques notwithstanding. So, CMSs were designed in an era when you couldn’t have asynchronously-updatable data on a page—yes, we’re talking AJAX here. In other words, many CMSs come from a less technologically-advanced world.

Mixed in with this is the glacier-like pace of large organisations in their technological adoption. Years ago I worked for a university & saw first-hand why the technological decision-making process took years: often for legitimate reasons. For example, if you are running a corporation with 10,000 computers, it takes a long time to produce all the tests necessary to ensure that you’re not going to bring down the entire corporate system in your enthusiasm to adopt new technology. Accordingly, many corporations start looking at tech products & it can take years for them to reach their decisions. (NB: many corporations are a lot better at making swifter decisions now, but it’s a rare academic institution that has matched this quicker pace.)

So let’s recap: many CMSs were originally built in a time when dinosaurs walked the earth & this is when large corporations might have begun eyeballing their products. Years go by, the corporation makes its (now dodgy) choice & then the corporations’ employees are stuck with the result for years to come—perhaps simply to justify a decision that cost millions of pounds even when that decision clearly was a bad one.

A major part of the problem is the decision-making process: after a certain cut-off point, no other options may be admitted. This is unfortunate (to say the least) because in the meantime blogging software has emerged not just as a niche player but as a robust solution—which solves many of the problems that CMSs were supposed to tackle. Publication control & template-based “unified” branding cross-site are allied with a significantly better interface. Moreover, many blogs allow for “static” pages (in this context, pages note defined by the date of the post but by their content). And while blogs may not automatically provide all the semantics required for, say, publications, most blogging software allows you to delve into markup to address specific concerns—or have plugins that would address the concern—or (as a last resort), you can tag content according to its semantic meaning. It’s a very good solution that solves 90% of the problems which CMSs were to address.

Now this doesn’t leave our clients in a good place—they still have to use a terrible CMS. My question is: why hasn’t the CMS vendor updated the working of its CMS? At the very least AJAX-based tools to move publications (as in the example way above) would ease so much of the pain. A less charitable person than myself would conclude that they don’t care that their software is so broken, so there is little impetus to fix it. A more charitable conclusion would be that they don’t realise that the software is broken. Perhaps when clients don’t renew their licenses they’ll wake up.

The New York Times has a very interesting article on the development of “Clearview”, the new font being rolled out on the country’s highways (or motorways, if you prefer). The font is designed to combat the effects of phenomenon halation, where the reflective material that’s used to make the signs more legible at night blows out the letters & dazzles drivers. This is particularly an issue for the elderly, an increasingly large segment of the US population, but it also can effect those with common sight defects. The designers, James Meeker & John Montalbano, opened up the counter shapes (the interior shapes of letters) & increased the x-height (size) of lower-case letters while retaining the stroke weight of the letters as they currently are.

An interesting fact from the slideshow (well worth exploring if you’re a font nerd) is that the typeface achieved “approximately 40 percent gain, or 200 feet of added reading distance using a 10-inch heigh letter on the demonstration panel”.

Proposed Japanese MOD logo: let’s hug!

So we’ve examined terrorist organisation logos from around the world. How about their nemeses, those of defence departments from around the world?

As the author notes, the proposed new logo for the Japanese Ministry of Defence is a bit Web 2.0. But we’re noticing common themes here:

• Oak leaves (they taste like victory!)
• Eagles
• Swords
• Anchors
• Creepy associations from the past (Germany)

Now, surely some artist out there can create a tableau of a sword-wielding, oak-leaf-chewing eagle dropping an anchor on a bone-and-gun-laden star. That would be awesome.

At least some of the employees of design firm A Gray Space collect Polish movie posters. This page shows some absolutely fantastic posters covering nearly 70 years.

Farewell to Autumn (1990s)

Working Girl (1987)

Behold, Melanie Griffiths vehicle “Working Girl” gets greater artistic treatment in a poster than it did in the original film.

All kidding aside, there are some beautiful designs here, including some that remind me of 1950s–1960s Ben Shahn. This page reads like a synopsis of European commercial graphic design.

We all need logos, it seems. Even your terrorist organisations need to differentiate themselves from one another. But where do you start? What are all the other organisations doing?

The Weather Underground logo

Ironic Sans has helpfully collected a large number of logos from terrorist organisations from the past 30 years or so, helpfully organised thus:

• Stars
• One gun
• Two guns crossed
• Other weapons crossed
• Crossbones
• Animals with multiple heads
• Other (which can also be called “WTF”)

Presumably, a logo consisting of three guns, a machete below crossbones, on top of a star, surrounded by the World-Snake would look as if it were designed by committee.

Contrary to the way things look right now, this blog is not dead! Ian has been hard at work on a project for a client & further refining resources_controller. He’ll have lots of news on that & other plugins once the job is done.

I, on the other hand, have far fewer excuses. While I’ve also been hard at work on a project for other clients & working on our business development & marketing, Finally, I’ve been working on the design for this blog, which will be implemented once we switch our blog engine. Work for ourselves, as so many designers can recognise, comes well after our clients’.

Raja Sandhu has written a FAQ regarding the development of logo — or, more accurately, corporate identity — design.

It’s good to see someone else taking a rational approach to design — or, at least, as rational approach as one can take. Many, if not all of Raja’s comments reflect our own experience of corporate identity design. In fact Raja’s comments can be expanded to cover graphic design in general. A good read!