• "Finally, if one can wrap a game around a complex issue like the national budget and engage that many young people, we should be able to do the same with other important policy issues, from climate change to health care. The budget was about the most boring issue one could take on compared to Lost, Heroes, World of Warcraft, or playing Moto Racer on the iPhone." Really interesting set of conclusions from a large-scale serious game.
  • "There was once a world of living robots. But one day a bad accident occured in the main power generator. The world fell into a deep sleep. Bring life back to the world!" Wonderful animation and art design, and a charming little game. It'll take you about 10-20 minutes. It's brilliant.
  • Dustin Curtis didn't like the American Airlines website, and complained on his blog; a UX architect from AA gets back to him and explains how things are; Dustin responds. I need to write something longer on this, but in a nutshell: I understand Dustin's position, but it feels naive, and I think he confuses corporate culture with business practice. I want my airline to have a corporate culture of conservatism and fustiness, just like I want my bank to be severe and serious. That doesn't meant their website has to suck, but it also doesn't mean that their sucky website is their CEO's fault.
  • "ART & COPY reveals the stories behind and the personal odysseys of some of the most influential advertising visionaries of our time and their campaigns, including Lee Clow (Apple Computer 1984, and today’s iPod); Dan Wieden (“Just Do It”); Phyllis K. Robinson (who invented the “me generation” with Clairol); Hal Riney (who helped President Reagan get re-elected); and George Lois (who saved MTV and launched Tommy Hilfiger overnight). Directed by Doug Pray (SURFWISE, HYPE!, SCRATCH), ART & COPY captures the creative energy and passion behind the iconic campaigns that have had a profound impact on American culture." Sounds good – Scratch was excellent.
  • "I hope you find this overview of the future timeline of Facebook Usernames useful to understand where this exciting feature is going in the future, how our industry will adapt and respond to this sort of innovation, and how our tech trade press will hold the powerful company's feet to the fire as this sort of capability becomes mainstream in the years to come." Meanwhile, Anil Dash drops the awesome.
  • "This is what Tim O’Reilly warned about in his definition of Web 2.0. He said that one of the new kinds of lock-in in the era of [cloud computing] will be owning a namespace." Chris Messina, being thoughtful about the Facebook Usernames issue…

It’s a strong title for a post, I know, but having discovered that two friends didn’t know this at last night’s LRUG, I wanted to share it.

Let’s put this in bold for impact.

When you add <%= javascript_include_tag :defaults %> to the top of your Rails layout, you’re adding 146kb to your page load.

And, being Javascript, that all loads serially. This is slowing page load down a lot.

Now, I’m sure if you’re building a whizz-bang AJAX app you need all that. But I reckon a lot of Rails projects don’t use anywhere near all that. So throw some out!

The Scriptaculous libraries are quite big: dragdrop.js is 30kb, controls.js is 29kb, effects.js is 34kb. If you don’t need that lot, get rid of it. prototype.js alone is 56kb. The case for the Prototype library is easier to make… but if all you’re doing is some simple DOM scripting – show/hide, for instance, do you really need 56kb of library functions to do it? Or can you do it in < 10kb with some home-made functions? If so, strongly consider doing that. And if you’re not using any Javascript in your application… why have you get any of it in there? It can all go – that’ll speed page load up no end!

I’m not saying there’s no place for this stuff – there is. Should it be included in Rails Core? Absolutely. I just don’t think that it should be called the “default” option; <%= javascript_include_tag :all %> would make a lot more sense. And by sticking it into the basic scaffolding layout, it becomes a part of many people’s first experience with Rails – and they assume it’s default behaviour. And so I also think it should be left out of scaffolding – perhaps replaced with <%= javascript_include_tag "prototype", "application" %> at the least.

User experience, usability, and accessibility aren’t just about the content or code of the page; they’re about how the user experiences the page. If it takes an age to load, it makes the app less usable. If you’ve got huge page size, you’re excluding anyone on a slow connection. So next time you’re skeletoning out a Rails app, take a moment to think if you really need any Javascript. If you don’t, <%= javascript_include_tag :defaults %> can go straight in the bin. Then, when you come to progressively enhance your app at the end with Javascript (which is, let’s face it, how you should be doing it), you can include only the files you need – and keep your users happy at the same time.

I’ve been thinking about tagging a lot recently. One particular thing came to my attention yesterday, and I think it’s worth noting in public.

Users use tags to hack the UI. Tagging isn’t just metadata; it’s metadata you can use.

To wit: a friend mentioned that one of the problems he had with Flickr was that you couldn’t see al the photos from a particular date. Oh, but you can, I said, and showed him the Archives page which does exactly that – it lets you trawl through photographs by date. It’s a really nice piece of design, in fact, so if you’ve never looked at them, go and check them out.

Of course Flickr lets you see things by date – it’s one of the key pieces of data it associates with every picture. Yes, there’s some confusion between “date uploaded” and “date taken on” but that’s dealt with – Flickr lets you view by both.

My friend hadn’t found this supposed lack in functionality a hinrdance, though. Instead, he’s just tagged his photos with a tag for the year (eg ‘2006’) and, sometimes, a tag for the month (‘September’). He’s not the only one – hunt around Flickr for the preponderance of tags like ‘200506’ or ‘20031224’. Lots of people do it.

Why do they do it? Two reasons. Firstly, they’re adding data that they either don’t think is there or that they can’t find. Even though Flickr stores date information, and they can see that at the bottom right of each picture, if they can’t manipulate that data – if they can’t pivot around it – then they store the data in a way they can use it – they stick it in a tag field. And that leads to the second reason: they’re making something to click on.

Making a tag is like making a shortcut button. One click on “2006” shows me all my pictures from 2006. So does the “archives” function but it’s not quite as fast, to be honest, and not as immediately intuitive.

This is true of all tagging systems – tagging makes links, that’s they way it works. So as well as using tags to store data, tags get used to extend and build upon the user interface. As a developer, this has an unexpected bonus. If you see lots of tags emerging storing data you already track (such as dates), consider that the method for accessing data by date might not be obvious (or simple) enough. And if you see enough data of identical format being tracked – often in the form of machine-readable tags, such as geotags, then perhaps it’s time to consider adding a new feature. Tags are a great way to track how uses actually make use of your service.

Matt addresses the issue of the philosophers of Lagado, with regards to Don Norman’s take on the “simplicity” of Google:

“it would be more convenient for all men to carry about them such things as were necessary to express a particular business they are to discourse on”

I refer to it as the “map of the world the size of the world” problem, but I forget where I obtained that concept – it might have been Gulliver, too. The most perfect map of anything is a 1:1 representation of it – you end up making a copy. The trade-off in any navigation aid – menu, sitemap, chart – is accuracy of representation versus accuracy of content (I think). You need a perfect representation – an outline – but you don’t need a perfect rendering of content, because you’ll get that at the destination.

I face this problem a lot in design and IA; you come up with a solution that will work with the current content – and then “current content” grows. And for a while, things scale, but then they stop scaling, and you end up cramming it all in at the top because, well, all the content is competing with one another. And so you end up with a map of the world the size of the world.

The next step is to stop, refactor, and start again – if you have that luxury. Google, by contrast, never let things grow: it’s still practically the same homepage they started with. They avoided the feature-bloat by never letting it happen, and instead, launched their other product by and large, seperately. They may have occasionally integrated them into the results screen, but never the home page. So then usability comes down to intuition (and why shouldn’t it? Even Norman argues that objects should be intuitively usable). mail.google.com – what do you know, it works. maps.google.com – it works. And in making people guess the subdomains, you’re creating better users – users who work out what they’re really looking for quicker. That makes them more adept at your product – because Google’s product is find, after all – and more adept consumers of the internet.

The map-of-the-world problem stems from that horrid, oh-so-web-1.0 site archetype: the portal. We tread a fine line now – at one extreme, a single search box as a gateway to content; at the other, comprehensive indexes and subindexes, homepages of horrendous complexity. I don’t think the “single search box” approach is valid for many, but people are moving that way, and it’s good – away from horrendous taxonomies and indexes and subpages and sitemaps and towards a more organic, find-orientated paradigm.

Don Norman doesn’t believe in find. He likes devices to be “their own instruction manual”, remember – you shouldn’t need to read the book, it should just be obvious. This leads to his crazy telephones with millions of discrete buttons for each function. He’s kind-of right, but he doesn’t like a middle-ground of adaptability, multi-purpose interfaces. Google riles him not because it’s the middle ground in his way of thinking, but the polar opposite.