Alpha channel

I’m not much of a visual designer, but here’s a subtle little use for alpha channel I found while build a related episode feature. (You may have to squint a bit here or alternatively zoom in.)

In the before pic, we have dark text on a dark-and-light texture:

The text blends into the background too much, so we can sharpen it up with a subtle background (#eee):

Better, but observing closely shows the discontinuity. So instead of full light-gray, let’s blend it into the background. Here I used a 0.5 alpha channel (rgba(240,240,240,0.5)) and to make the transition even less jarring, a 5 pixel border radius too. (I suppose I could have added a box shadow for max combo.) I think it’s considerably sharper now, but without any noticeable background.

Notes from Paul Annett Talk

Update – some links:

Pauls deck/audio (needs a bit of time to buffer)

slide deck

Standard live blogging alert

I’m here at GumTree offices in Gumtree, thanks kindly to @cyberdees++ letting me know about this lunchtime talk. Paul Annett (@nicepaul) just gave a fun talk about “oooh that’s clever” design, which contains lots of fascintating ideas and examples around the subtle things, the hidden and unexpected and often functionally pointless, that delight people and get them talking.

Is this Stuff Relevant? 13 Million People Can’t be Wrong

To demonstrate how people are fascinated by little secret details, he begins talking about his magic trick he posted to youtube, “This’N’That magic trick” with no less than 13M views. The interesting thing is the attention to detail people have, where the most commented thing is the few frames in which the third “magic card” is exposed. It’s like they have now discovered a little secret they can tell their friends about.

Offline Examples

You see similar things offline too: (sorry no links – I’ll just let you google these)

  • The hidden arrow in the FedEx logo.
  • The hidden bear in the Toblerone “mountain” logo.
  • The Aerosmith logo, which still says Aerosmith upside-down.
  • Darren Brown’s Trick or Treat logo, where the Trick is the Treat logo upside-down.
  • The “truce” logo, where another “truce” fits into it.
  • The Venetian Snares logo.
  • Mickey Mouse symbols – Disney hides them in different places, e.g. a silluoette in a picture, a figure in a man-hole cover in the theme park, and even a field on Google Maps.
  • The bottom of an Innocent Smoothies carton, containing various messages.
  • The inside of Moo card packages, which contain little hidden cartoon figures when you dismantle them.

Hardware and Software Easter Eggs

This has been going on a while in technology with easter eggs. There are hardware easter eggs such as a cheetah on a microchip. Look at the glow an Apple Mighty Mouse makes. An irregular pattern? No…it’s definitely a real mouse outline. And of course software easter eggs, e.g. “about:mozilla” in Firefox, the saga continues.

The parallax employed on the Silverback website is a well-known example of this. (In fact, @psd talks us through it on I Can’t Believe It’s Not Flash.) Parallax has been used elsewhere since then. The holding page for twequency used it nicely. Tweet1 also has some lovely effects like this, and also has an easter egg figure (at least one) appearing. A lot can be done with parallax, e.g. you could use it jumble sites around. The effect here is just a demo, but could be expanded to something more.

It adds to the brand of a large company when you see it has a sense of humour, e.g. zooming into Google Moon would give you yellow cheese. Try “ascii art” or “recursion” searches.

dConstruct site had a nice easter egg where the hidden top bar would switch different stylesheet. Some people said it detracts from the experience, breaks proper design principles, etc.; but the point is, no, users can still get everywhere, it’s just a bit of a delighter for people in the know.


There are many interesting uses of transparency:

  • Modernista has a funnny iframe idea. Good example of transparency, which is a concept that’s under-used. Skittles also did this, much controversially, partly because they copied the idea from modernista.
  • This trailer shows fake browser with things breaking out of it to promote the movie’s 3-d ness.
  • CSS Zen Ocean (zen garden project)
  • Wario Land video breaks your expectations of YouTube, such a well known site structure. Good example of a commercial application. Likewie, iPod Touch ad on Yahoo! Games.
  • HEMA similarly breaks your expectations of an e-commerce site.

What’s the Point of All This?

Kano Model of Customer Satisfaction: 2 dimensions. Customer satisfaction and Execution. “Performance needs” tend to improve both at the same time, e.g. quick hotel check-in; quick e-commerce delivery. “Basic needs” where execution is higher won’t delight (ie improve satisfaction) but they are just expected and their absence will cause negative satisfaction. “Excitement needs” – e.g. these little design features we’ve been talking about.

These change across time. What excited you last year becomes expected this year, i.e. as enough time passes, the expected need becomes a basic need.


I asked paul about how to get these features known, when you obviously don’t want to just blab about them on your blog. With big sites, you can rely on people to discover these things by accident or investigation, but with little sites, they could sit for years without anyone spotting them. He mentioned it could be as simple as telling a few friends and see where that goes as one route. A more technical trick is positioning some text outside the document. Users will see it when they zoom out, and it would also be interesting to experiment with an image at the edge of a document turning out to be something unexpected when you zoom out to see the whole thing. “View Source” is another common thing you can play with. Tangentially related are playful copyright messages and 404 pages.

Someone mentioned “contextual delighters”. Things specific to certain users. e.g. “Welcome fellow Reddit user. Could also do the “styling visited links” hack to freak people out. Who’s going to make a site where your website tries to log into other websites using the same username and password, then says “actually you used the same password on flickr, so please change it”! (Paul urges us not to try this at home!)

The official olympics medal tally is broken. Let’s fix it.

This is how the official olympics medal tally looks:

Overall Medal Standings - The official website of the BEIJING 2008 Olympic Games

It’s not only the official tally, but the one linked from google each time you type “olympics” and terms like “australia olympics”. Thus making it an absurdly popular page at this time. As you can see, the design is reedeeeculous. The thing you want to see the most – total medal tally – is several miles away from the country. It’s good they’ve used alternative shading for odd and even rows, but even so, it’s still difficult to see the connection. Especially since the gold/silver/bronze tallies are shown in a different colour.

Did you notice even “open/mixed” gets preferential treatment? Look, I can’t even think of an open/mixed event at the olympics. Ballroom dancing? Friendly game of trumps? All I’m saying is, I’d rather see the headline figures first. I don’t know how many gazillion dollars the official IT contract went for, but this is what the tally should look like according to table design 101:

Overall Medal Standings - The official website of the BEIJING 2008 Olympic Games

(BTW I also pulled total to the front and emphasised it. Matter of opinion whether to go by total number versus number of golds.)

(The following images are just to record the fact it’s linked from Google since it won’t be linked much longer.)

olympics - Google Search

australia olympics - Google Search

Designing Like a Pollyanna: Have your Cake and Eat it Too

“The novel’s success brought the term “pollyanna” (along with the adjective “pollyannaish” and the noun “Pollyannaism”) into the language to describe someone who is cheerfully optimistic and who always maintains a generous attitude toward the motives of other people. It also became, by extension – and contrary to the spirit of the book – a derogatory term for a naïve optimist who always expects people to act decently, despite strong evidence to the contrary.”

— Wikipedia entry for Pollyanna

A little while ago, I was talking to some colleagues about an authentication problem. I suggested we need to improve its usability and my colleague’s immediate response was to argue there’s a security-usability trade-off, i.e. by improving usability, we must resign ourselves to decreasing security. Push one lever down, the other goes up. I’ve never bought into this argument. While certain forces do often conflict with each other, they don’t always, and it’s counter-productive to constrain your solution space with immediate presumptions like that.

Clarke Ching triggered this post with his posts on Non-Zero Sumness and having your cake and eating it. The latter is an example of a twerpy category of fallacious sayings and assumptions in this world which are based on scarcity mentality. For example, the notion that you have to “divide the pie” so that a gain for A is a loss for B. The alternative (as a certain presidential candidate was ridiculed for pointing out) is to make the pie higher. Whoever invented multi-storey buildings figured this out a long time ago.

(BTW “You can’t have your cake and eat it too” is a ridulous premise; what else are you supposed to do with your cake? I see from the wikipedia article that the original phrasing “wolde you bothe eate your cake, and have your cake?” is the reverse and makes more sense – you can’t eat your cake and still have it.)

Fortunately, we have sayings and phrases which remind us that it doesn’t have to be a trade-off. Unfortunately, these terms have been over-used by the proverbial “MBA suit guy” that we’re not allowed to use them without offering an apology. e.g. “win-win” and “synergy”. (Both terms I use without apology. I will stop short of “gestalt” though.)

All the above is theoretical rambling – here are some real-world examples.

  • Security-Usability Biometric authentication allows people to enter places without typing a password or carrying a card, and is, generally (and theoretically) speaking a more accurate indication of a person’s identity. Neither security nor usability suffers from this technology; both have been enhanced. (Privacy advocates will argue there is still a trade-off at stake.)
  • Safety-Usability As with security, safety is often assumed to be at odds with usability. In our work on safety-usability patterns, we sought synergies which would ideally improve both at the same time. For example, the pattern called “Behaviour Constraint”, sometimes referred to as a “forcing function”. In some buildings, when there’s a fire, a barrier goes up on the stairs leading to the basement, to ensure people don’t keep running down there (example by Don Norman). The wheels of a plane can’t be raised if the plane isn’t moving (to prevent a pilot from actually raising them while on the tarmac). These are examples which make life easier for users, by reducing the number of decisions they have to make, and at the same time, improve safety by blocking the transition to dangerous states.
  • Ajax-Accessibility When Ajax emerged, some people had a knee-jerk response – “Ooooh! Javascript! Bad for accessibility!”. In some cases, it was true. In many other cases, though, Ajax actually improves accessibility. e.g. Ajax makes it much easier to let people choose font size and colour scheme.

Knowing that certain forces trade off against each other is still useful as a kind of broad-brush stereotype. At a meta level, it’s a kind of general software engineering pattern to say “security and usability trade off against each other”. (It’s a pattern in the sense that if you looked at hundreds of software projects, you’d see people frequently dealing with this trade-off.) I would like to explain such a pattern to a first-year software engineering student, so they can more easily reason about how these things work. It’s also useful in scrutinising a design; I would be quite comfortable ending up with a design with “high” security and “low” usability, or vice-versa, after exploring all the options, because I know these principles do usually trade off. And for that reason, I’d consider it somewhat unrealistic for a client to expect a feature to have both “high” security and “high” usability, and would only engage on such a quest after explaining to said client that the effort has a high chance of failing to meet these criteria.

So these trade-offs are useful and are my defence against the second part of the Pollyanna definition above – “a derogatory term for a naïve optimist who always expects people to act decently, despite strong evidence to the contrary.” I’m not ignoring those trade-offs, I’m just saying they shouldn’t be an automatic assumption. It plays to a higher-level rule about design and creativity: Ignore constraints at first. In too many cases, people are afraid of going down certain paths because they can immediately detect an obstacle down the road. I once tried producing a novel design with a domain specialist who would immediately shoot down most any idea I had on the basis that users would never work with it. Once I bypassed him and got to the users themselves, the situation was quite different; the users embraced the concept and gave further suggestions for improvement. The domain specialist, who had long since working as an active user, was applying constraints too early and preventing us from proving the concept (“proving” == “bashing into shape”). In many other cases, the barrier is technical – you come up with an idea and it’s immediately blocked on the basis that it can’t be done with current technology. (The sort of limiting belief you would have heard if you proposed Google Maps in 2004). In the same way, when we automatically assume “improving X will diminish Y”, what we’re doing is limiting our options prematurely. Better to ask first “is there a way I can improve both”, or, failing that, “is there a way I can deliver the critical attribute X without diminishing Y too much?”.

Rethinking Hollywood OS (Lame Depictions of Computers in Movies may not be so Lame)

Poking fun at hollywood depictions of computing is an old favourite on the net – compilations of dumb computing scenes outshadow even mentions of anomalies in the star trek universe. Meet The Hollywood Operating System (AKA the Movie Operating System, Movie OS). You know it well:

The Hollywood operating system, or Hollywood OS, refers to any fictional computer operating system clichéd in movies and television … These systems usually share common functions with real operating systems, but tend to be able to perform these functions at faster speeds with a more aesthetic graphical user interface (GUI), and are exceptionally more functional than today’s software. For instance, a Hollywood OS may have be able to download extremely large files in mere seconds, display error messages in large, flashing red text … They also tend to have sound effects unnecessarily accompanying every event, no matter how trivial. Some versions do not make use of a computer mouse, with virtually everything being done by keyboard or alternative input device.

I’ve often joked that it would be fun to have a job producing those systems, but recently I’ve been wondering: What’s so funny about Hollywood OS? This is not April 1 and I am serious when I say Hollywood OS has things to teach us (though I do find most of these depictions funny as well!), much as “serious” applications can be informed by video games as well (see Brenda Laurel’s The Art of HCI). In fact, Hollywood OS has two key virtues:

  • It’s an idealisation of how computing should be, and maybe one day will be. The Hollywood OS is not only easy to use due to its natural language and clear UI, but it’s also more aesthetically pleasing than the 2007 junk you’re looking at right now (even if you’re on a mac).
  • It’s a powerful abstract representation of what’s going on inside the computer and network
  • Many times, modern OSs and apps are too detailed. In contrast, Hollywood OS provides a presentation that’s not entirely accurate or precise, but conveys, at a level the user cares about, what’s going on. Just like the revolutionary London Tube Map, which foregoes precise locations in favour of a simpler view of the network and connections. Helpful Distortion principle. I could even imagine using these styles of animations in a tutorial on a given computing topic.

Let’s revisit the wikipedia definiton above – do you really think Hollywood OS sucks?

“tend to be able to perform these functions at faster speeds”

Good – it’s an idealisation of what should happen and also a compressed representation of what’s going on

“with a more aesthetic graphical user interface (GUI)”

Macs and Linux are prettier than Windows, but they Hollywood OS owns them all, and eye candy is nothing to sneeze at.

“exceptionally more functional than today’s software.”


“download extremely large files in mere seconds”


“display error messages in large, flashing red text”

How many times have you missed an error message because it was buried in 12pt times roman on a boring blue dialog, the same dialog that asked you 5 minutes ago if you feel like checking your mail. If it’s critical, large, flashing, red text would seem to be exactly what’s required.

“interface with any computer, whether terrestrial or alien (as in Independence Day)”

Actually this is pretty much possible anyway nowadays.

“They also tend to have sound effects unnecessarily accompanying every event, no matter how trivial.”

As with the visual effects, some of these sounds are actually pretty neat and help build the user’s mental model of what’s happening.

“Some versions do not make use of a computer mouse, with virtually everything being done by keyboard or alternative input device.”

Right, like the way DOS or Unix or ATMs work?

More Links What code doesn’t do in real life

More is Sometimes Less

Someone sent Don Norman a critique implying that a machine was more usable because it contained only one button. His response is interesting:

Nice story, but wrong. Fewer buttons do not necessarily mean easier use … When assessing simplicity, don’t get all hung up on the number of buttons. Look at the whole picture: more is sometimes less.

The sentiment will resonate with anyone who’s tried to set an el cheapo digital clock, the kind of clock that skimps on an hour button and makes you run through all 1440 minutes of the day. Slow. Or tried to set the time on a digital watch, whereupon you learn in the manual (if you’re fortunate enough to have kept it) that you must depress down “Button B” for 3 seconds. Confusing.

The same thing happens with language. Sometimes introducing a new term for something reduces complexity overall. When talking about software architecture, for example, life would be a lot more tedious if you didn’t have terms like “Factory”, “Singleton”, “Proxy”.

Mix ’06 and Ajax Design Principles

‘Tis Goud reports from Mix ’06, Microsoft’s web bash currently happening in Vegas. One of the presentations focused on the most important thing about Ajax: Usability.

The session started with referencing two sites with information on:

Thomas’s guidelines were the first serious look at Ajax usability and a big inspiration for the Ajax Patterns.

The patterns and the principles were apparently distilled to this list:

  • Feedback
  • Predict
  • Preserve
  • Share
  • Controls
  • Separate

If anyone has more detailed info on this discussion, please let me know!

As it happens, the third chapter of “Ajax Design Patterns”, the overview to the patterns themselves, explicitly identifies principles on which the patterns were based. Principles and patterns go hand-in-hand, so any pattern language I’ve worked on always comes with a set of principles, an explicit reference point for people to grasp where the patterns are coming from. You can even (with some energetic hand-waving) look at the patterns as being defined around the principles: “These patterns are written such that if you follow them, your system will adhere to these principles”.

Anyways, the principles are broken into two groups: Usability Principles and Software Design Principles. Maybe I ought to podcast them sometime.

These are the Usability Principles for Ajax.

  • Follow Web Standards
  • The Browser is Not a Desktop
  • If it’s Different, Make it Really Different
  • Provide Affordances
  • Smooth, Continuous, Interaction
  • Customisation
  • Make it Fun

These are the Software Design Principles for Ajax.

  • Embrace Javascript
  • Accept Workarounds Where Necessary
  • Tame Asynchrony
  • Develop for Compatibility
  • Reduce Bandwidth
  • Deal with Latency
  • Partition into Multiple Tiers
  • Go Easy on the Browser
  • Practice Graceful Degradation

It’s funny. The very first thing I think of when I see stuff like this is along the lines “SHOW ME THE PATTERNS!!!!”. I’ve got no patience for motherhood statements like ‘Tame Asynchrony’. But the reason for this annoyance is because you usually see these kind of principles in the absence of any explanations, examples, or patterns. Once it’s apparent that the principles are merely a background to more concrete advice, their presence has been justified.

Error Messages We’d Rather Not See

Uh, thanks for the heads-up.

Reminds me of a presentation at Interact 2001, where the laptop suddenly interrupted proceedings with that legendary message, “Your computer is now fully charged”. The presentation was about user attention, I kid you not.

And, by way of contrast, how to write good error messages: tell the user what happened, explain the consequences if it’s not obvious, outline how to fix it, explain what to do if they can’t fix it.

Error Messages We’d Rather Not See

Uh, thanks for the heads-up.

Reminds me of a presentation at Interact 2001, where the laptop suddenly interrupted proceedings with that legendary message, “Your computer is now fully charged”. The presentation was about user attention, I kid you not.

And, by way of contrast, how to write good error messages: tell the user what happened, explain the consequences if it’s not obvious, outline how to fix it, explain what to do if they can’t fix it.

Agile: Not Just an Attitude

Agile is a big theme these days. Not surprising that it should be a big part of “Web 2.0”, since Web 1.0 is often attributed as an inspiration. Paul Scrivens reminds us of [37Signals’ association with agile principles](] and that’s evident, for example, in this talk by Jason Fried. Similarly, the agile manifesto was mentioned in a Web Essentials talk last week (I think Kelly Goto’s talk, towards the end). And, of course, you’ll see “Agile” bandied around in most magazine ads run by consulting and IT companies, complete with obWhiteboardSketches.

What you don’t hear much of, in these bite-sized message, is how to do agile. I’m sure the speakers and their organisations know how (though I’m not sure about all the magazine advertisers), but how about the audience? I have visions of some people thinking, “1. Loosen up a bit. 2. ???. 3. Profit!!!!!!”. Hopefully, some of them will do some investigation and learn the how part, but for others, this has the potential to end in tears.

To clarify:

  • Agile is not just taking your tie off.
  • Agile is not just the manifesto.
  • Agile is not just whiteboards.
  • Agile is not just programming.
  • Agile is not just adding functionality.
  • Agile is not just setting up a wiki.
  • Agile is not just “we have to try harder”.
  • Agile is not just taking your tie off.

Here’s why:

  • “Agile is not just taking your tie off” because you need specific technologies, technical skills, and techniques.
  • Agile is not just the manifesto, because that’s a set of principles, not a manual.
  • “Agile is not just whiteboards” because no-one ever got paid for delivering a whiteboard. (With the obvious exception of whiteboard manufacturers, and it’s also likely some retailers in the corporate sector have made a tidy profit in the whiteboard market.)
  • “Agile is not just programming” because it’s also continuous design and testing.
  • “Agile is not just adding functionality” because it’s also refactoring existing functionality.
  • “Agile is not just setting up a wiki” because it’s the content that counts. (And in any event, use the wall instead of a wiki. Support your local whiteboard manufacturer today.)
  • “Agile is not just “we have to try harder” ” because that’s not sustainable, and even if it was, it’s not optimal.
  • “Agile is not just taking your tie off.” No, really. Keep it on if you like. It makes no difference. A black polo top doesn’t make you more agile.

(Vaguely inspired by hearing that Dave Weinberger’s going to be talking about what blogging’s not.)

What I like most about Extreme Programming is that it makes the practices explicit, whether you agree with them or not. “Refactor Mercilessly”, “You Ain’t Gonna Need It”, “Test-Driven Design” – they might sound like mindless mantras to the uninitiated, but they actually reflect a lot more concrete, rich, advice than “Chill Out”, “Loosen Up” and “This agile thing’s a breeze … (something about whiteboards) … profit!”.