think pink

I love the approval process.

Elliott Kember — Sun, 31 Jan 2010 17:42:48 +0000

There’s been a lot of hate for the App store approval process over the past… well, ever since the App Store surfaced. It seems like anybody who has ever touched the SDK has a bad word to say about the draconian Apple iron curtain. The iPad’s recent release has incited similar levels vitriol – it’s closed, Apple is taking over the world, blah blah.

Apple seems to be blocking applications that duplicate native iPhone apps, applications that use Apple imagery, logos or trademarks, and apps that are offensive. I can see how some of this might be frustrating for someone who hasn’t read the documentation properly before they start working. I kid, I kid! I’m sure it comes as a nasty surprise.

This isn’t the only reason behind the approval process. In fact, I don’t think it’s even the main reason behind the approval process. One reason is to protect Apple’s ~~patents~~ trademarks. You can bitch and moan about this one if you want, but it’s fairly standard. If people have your image on their stuff, your brand is vulnerable. You don’t want to go down this route; Apple has a big legal team, and you are not a lawyer.

But I digress; the other reason is that Apple checks every application to make sure it works. By “works”, I mean: it opens, runs, and doesn’t crash too badly. If it’s a game, it doesn’t have to actually be any good – but at least it works and is playable by anybody who owns an iPhone or iPod Touch.

Remember that we are not the average user. Just like the iPad, the iPhone is also targeted at end-users. The end user doesn’t understand bugs, or approval processes. They understand works, and doesn’t-work. If something doesn’t-work, it instantly tarnishes the device. The shine is gone, the thin veneer of novelty wears away, and the dirty, buggy reality is revealed. You can watch it happen. In effect, they’re screening applications for suckiness.

So why do I love the approval process? Because it means that every application is tested and approved by Apple before I can buy it. I like to think of it as though Apple is the Maître d’ of a fancy, expensive restaurant, tasting every dish before allowing it to be sold to his customers. The more picky he is, the better the food will have to be.

Before I spend my hard-earned bling on a game, or an app, I want to know that it works properly. I want to know that somebody at Apple has tried the damn thing. Apple is actually making itself responsible for the user’s experience on the phone, whether on third-, second- or first-party applications. Can you imagine the kind of shit you’d be able to buy if they opened the floodgates and let any old developer release any old crap onto the App Store? There’s a store icon on the homepage of the phone, for heaven’s sake.

I guess the bottom line is that the people who benefit from the process are the ones who know nothing about it – the end-user – and so they never say anything about it. That means that all we hear about are the developers’ stories – and at that, only the negative ones. This selection bias is why the approval process has such a bad reputation. The poor thing needs a friend. Look, I’m sure you’ve had a bad experience with the App Store’s approval process, but try and remember us, the end-users. We love your apps, and we love our iPhones. The process isn’t perfect, I’m sure, but it’s there for a reason.

I am an iPhone end-user, and I love the approval process.

(I was going to write an article about the iPad, but there are way too many already.)

On Failure

Elliott Kember — Sun, 03 Jan 2010 10:50:51 +0000

I’ve recently been playing around with monetizing one of my applications: Filetweet. It’s a fairly simple application, designed to allow you to send files over Twitter. You may have seen it; some of you may have even used it.

It’s the first application I’ve built that I’ve tried to charge for – as an experiment. Using the excellent Spreedly service, and the not-quite-so-excellent PayPal merchant gateway service, it’s really easy to start taking money on a monthly basis. The only problem is, nobody is paying. I don’t think anybody will ever pay. It’s just not that viable a system for people to spend £5 / month on. There are probably even other services that fill the same gap.

But you know what? That’s okay. I don’t really mind if I don’t make any money on Filetweet. It’s supposed to be an experiment, which means that it will most probably fail.

One problem with this ultimatum is that I’ve used the wrong terminology. To “fail” is generally to experience no growth – failing to establish a user base, generating no profit, and not really fixing a problem are good general indicators of failure, and reasonably apt descriptions of Filetweet.

However, I think this terminology is wrong. It’s very depressing to fail, even when you’re expecting it. Every application I build, I secretly hope that it will be the next Basecamp. Can this repeated “failure” be any good for morale? I don’t think so – and I think my own point of view is to blame.

Perhaps on paper the project is a loss – but intangibly it’s a victory. It’s like, the opposite of a Pyrrhic victory, if there’s a name for that. The problem is, everybody tries to get things right the first time. There’s no margin for error. Every time you do something new, you’re trying to do it right – which is absurd.

As developers, in code, we prototype all the time: create a small, off-master experiment branch and try something out. Sometimes it works, but very often it doesn’t, and usually it’s never folded into the main branch, at least without some refactoring.

Why is it, then, that we place so much stigma on “failure” and “success” with individual business ventures, when so little is placed on the success or failure of individual parts of our code? I think the only way to fail from a project is to come away with nothing. If you learn anything, improve at anything, or streamline your development process, you’ve achieved something.

%h3 The Juice and the Squeeze

If the project were to succeed, would the payoff be worth the cost of failure? In ruby:

  def valid?
    return (failure.cost * failure.probability) > (reward - costs)
  end

Of course, it’s not that simple. Knowing the true cost of failure, and the true probability of failure, is a very difficult art. There are, however, several things you can take into consideration:

• Amount of maintenance required
• Any ongoing costs (hosting)
• Possibility of future feature requirements
• Complexity of the application

- all of which will add to the cost of either success or failure.

In Filetweet’s case, the answers are easy: not much maintenance, S3 means very little ongoing cost, feature requests are unlikely, and the application is not very complex at all. In actual fact, if this rings true – if the hard work involved is not very high, you might just be wasting your time trying to achieve success. Why?

Risk == reward

This is where it gets difficult. The more you put into something, and the more you stand to lose, the more you generally stand to gain. Conversely, it’s harder to risk nothing and hope to achieve everything.

But we’ve strayed from the original point of this article – the flawed concept of success. If we’re redefining success, we have to look at that formula again.

  def valid?
    failure = (failure.cost * failure.probability) 
    tangible_success = reward.tangibles - costs.tangibles
    intangible_success = reward.intangibles - costs.intangibles
    success = reward.intangibles + reward.tangibles - costs.tangibles - costs.intangibles
    return success > failure
  end

Even harder – since the intangible rewards are completely subjective. Intangible costs are generally your time, your sanity, and your hard work. The only way to really make this equation easier for ourselves is to do one of two things:

• Reduce the probability of failure, or
• Reduce the cost of failure, or
• Reduce the amount of time and effort you expend

Or,

• Don’t fail, or
• Fail cheaply, or
• Fail quickly

Fail cheaply and quickly

This point is the crux of this article. With today’s range of scalable hosting services – like EC2, and Heroku – and the number of VPS providers around – VPS.NET, Linode – you can really afford to fail cheaply. “Failure” in the commercial sense is immensely valuable – as far as I’m concerned, it’s the real shortcut to success. Any developer will tell you that learning from your mistakes is immensely valuable.

After I finished writing this article, I came across this, entitled “You will fail”. It’s a great article, and I think it expresses what I want to say. I guess what I’m doing is just pre-empting the inevitable. I’m annoyed

Prototype rapidly, and fail cheaply and quickly, so when you’re ready to risk everything, you know what not to do.

If you have a good story about any of the failures you’ve been a part of, I’d love to read about them in the comments. You’ll have to log in with Twitter.

You'll never get what you want.

Elliott Kember — Sun, 29 Nov 2009 14:22:14 +0000

People sometimes ask me “How can I get good at programming?” “How can I get really good at Javascript?” The sad thing is, I don’t bother answering these questions any more. What inevitably happens is, I give people a list of things to read and try out, then come back 6 months later to find them in exactly the same spot. So what’s going wrong here? I think they’re after the wrong thing.

The problem here is that they know what they want to be, not what they want to do. The reason this is important is because there’s only one answer to these kinds of questions. Work hard at it. Do lots and lots of it. Do it every day. Do so much of it that it starts to affect you. The funny part is, by really enjoying what you’re doing, you inevitably get good at it. As they say, practice makes perfect. If you want to be a famous guitarist, you have to play and play and play guitar until your fingers bleed. Like Mr Olympia Ronnie Coleman says, “Everybody wanna be a bodybuilder; ain’t nobody wanna lift this heavy-ass weight!” You can’t really disagree with someone who uses 200-pound dumbbells.

At student conferences, people ask what they should do once they’ve finished University. Unfortunately, the best answers I can give are:

Don’t ask for too much money

There are loads of people coming out of Uni expecting a £38k salary. You can get it, but it won’t do you any favours. Either you’ll be unqualified for the job, or you won’t have anyone to learn from. Seriously, take a pay cut, for a year, and work hard under someone who’s way, way better than you. It’s kinda like an internship – you won’t get rich, but you’ll be better off for it. Plus, money is useful, but ultimately it’s bullshit. I’ve been wealthy and miserable, and I’ve been broke and happy. Key words here: “Shared accommodation.”

Take your time

Even when you’re blasting through a prototype, and you can get it done in a day, there’s still time to sit back and just think about it. In a way, rapid prototyping tools fail us here, because they encourage diving straight into development too early – especially when the whole team consists of one developer. Unfortunately, our brains don’t work that way, and you’re destined to forget something. I built a project recently which I nearly put live before I realised it didn’t actually have any navigation. Everything worked, but there were no links to get from place to place. I was rushing. Not only that – you never know where and when your ideas are going to come from. If you proceed slowly, I’ll bet you anything you have more ideas during development that you can then integrate, which is far better than tearing your whole application apart later on. Key words here: “Make haste slowly.”

Your code sucks.

If you think you’re a genius, that’s great. But you’re not. Even if you are, realise that you aren’t. Even if you actually are, keep it to yourself. Key words here: “Show, don’t tell.”

All code sucks.

The corollary to the previous point, this idea is meant to remind you that opening your source code is not the same as showing off your faults. The cool thing about the open-source community is that it’s helpful, not critical. If your code has some bits you don’t get, politely ask for help.

Enjoy it.

There’s no substitute for really enjoying what you do. You’ll be more productive, and people will want to work with you. Don’t complain about what other people are doing wrong, fix it. Try not to be negative about people, or code. If there’s one thing that’s certain in this industry, it’s that you’ll have to fix stuff you don’t like. So get used to it, and learn to enjoy it. Key words here: None. You’re getting paid to fuck around with computers. It’s awesome, and if you don’t like that, then you should do something else for a living.

Fix other people’s problems.

This is a business model in itself. Learn to enjoy solving other people’s problems. Notice how they react when you solve something, or when you give them something they can enjoy using – it’s really, really rewarding. Don’t get into tech support, though. Key words here: I’m trying to spin programming as altruistic.

Like I said, there’s no easy route. If you’re looking for the quick way to be well-known, or to be really good, or whatever – you’re looking for the wrong thing. Look for whatever makes you happy today, and tomorrow und so weiter. That’s what you should do.

Long story short, do what you enjoy. Do it lots and lots. You’ll get better at it. There’s no easy way to success.

Highlights of Buildconf

Elliott Kember — Sat, 07 Nov 2009 14:30:02 +0000

I’ve been at Buildconf for the last two days. It was one of the best conferences I’ve been to. So instead of writing a whole bunch of tweets, which would be annoying, I’ve decided to write a blog post with a list. To make it interesting, count up the number of points you can identify with and leave your score in the comments.

Finding out how to open bananas

Andy Budd getting his kit off to the Flight of the Conchords.

Wilson Miner showing us what Keynote can really do

Tim Van Damme dragging us to the waterfront to collect a Gowalla badge.

On that note, Gowalla. Seriously, I had to delete this shit before it got the better of me.

For the first time in history, the bar closed before the tab ran out

An Ulster Fry

@itsdavidhughes didn’t get kicked out this time

Eric Meyer.

Tim Van Damme is Ballmer insane

“There were some cute girls here, and then we told them what we do for a living.” #webconference #afterparty – #

Belfast museum’s giant deer.

Interesting and in-depth conversations with people who have no idea who you are

Guinness in Ireland is the best

The amazing, gravity-defying, impact-resistant laptop.

Late-night birthday Jager-bombs with @Fehler

A rough sketch of Tim Van Damme

There’s a reason Harp beer is free.

Nicklas’ Moustache Bonus points: Niklas’s Wild Man Moustache Wax.

You need a silly hat

Wanting, and yet not getting, a Build t-shirt.

Politics in the Speakers’ Club

All in all, #buildconf was pretty much the most rewarding conference I’ve been to in a while – buy your ticket for 2010. What other ones were there? 5 extra bonus points if yours gets on the list.

Announcing Chatrbox

Elliott Kember — Sat, 31 Oct 2009 14:04:06 +0000

As you all may have noticed, I’ve been playing around with some cool live-action stuff. At FOWA London, I built a live Twitter feed. The original idea was to build an app to complement HelloApp, a .NET site built by Carsonified for the FOWA conference. I was planning on using standard every-day Twitter polling to get the tweets from attendees, to get a “real-time feed” of the FOWA tweets. Along the way, I discovered two things; One: the Twitter Streaming API, which allows users to pull tweets straight off the Twitter “firehose” live-as-you-can-be, and Two: a way to stream content to the browser.

The secret behind all this is a great Rails plugin called Juggernaut – a push server that sends Javascript to the page using a Flash bridge. Built by Alex MacCaw, it’s a clever way of doing Comet-style long polling, but without the hackiness of long-polling requests. As much as I hate Flash, it’s great for opening sockets and streaming data – something I’m looking forward to with Websockets in HTML5. Long story short, tweets went from your phone to the big screen instantly. No polling, no waiting, just pure Twitter streaming fun. It was absolute madness – turns out it’s crazy to watch 700 people start posting their thoughts onto a massive projector screen. I even got dragged on-stage.

So why this belated post? As you may or may not know, I’ve just launched a new app: Chatrbox. Featuring the stunning design work of @dizzyup, it’s a live-action IM chatroom, featuring Twitter authentication and login. You can create rooms, invite your friends via DM, and talk to people like it’s 1999 and you’re hanging out in a Yahoo! chat room.

On the technical side, there isn’t much to the back-end. Messages are passed in and out using a very simple JSON API, and saved in a DB along with rooms. Messages are passed to the user using Juggernaut, and then rendered into HTML using jQuery. There’s a backup polling system for the iPhone, or browsers without Flash. Twitter is only for authentication, and for inviting others to join in.

The cool part, I think, is the front-end. I’ve been taking advantage of jQuery as usual, and it’s been seriously fun. Before now, most of the Javascript i’ve hacked together has been fairly procedural – except for my Snake plugin, which I rewrote in OO code (I should definitely release that as a plugin some day). This, though, was a lot of fun. Safari and Firefox both have ridiculously fast Javascript engines, which means that you’re free to pretty much do what you want in Javascript. The code behind the app is all-Rails, the code in front is all-Javascript. We don’t need no steenking templates! In fact, there are no HTML templates for messages whatsoever. Everything’s handled by Javascript.

Javascript as a templating language is great for post-render updates. I don’t have to tell the UI where a message should go – it looks at the message’s room_id and inserts it accordingly – which means I can have “unread messages” notifications pop up. Instead of using the HTML as a database, and jQuery as a query system, pulling stuff out by class and ID, I can do it backwards – maintain my data in Javascript objects, and render to HTML.

Unfortunately, this means that the app doesn’t degrade. If you’re not using Javascript, it just plain won’t work. I can’t see myself ever making it degrade, either – it’s not that kind of site. Short of an all-Flash UI, there’s just no feasible way to do chat without it. If you want to disable Javascript, that’s fine – but you’re going to re-enable it if you want my stuff to work. Javascript is just as necessary as CSS.

So there you have it – a fun, interesting, Twitter-based chat room. I’m planning on adding file-uploading, private rooms, and a few other cool features that may or may not be paid-for. For now, though, I’ll be happy if everyone gives it a go. Also, don’t forget to leave a comment below; it makes me happy when people comment :)

Photos by Yaili and Chegs on Flickr, screenshots by Yours Truly.

I forgot to eat lunch yesterday.

Elliott Kember — Fri, 09 Oct 2009 12:03:02 +0000

Writing code for a living can be a bit depressing at times. It has a lot to do with the fact that it’s a sedentary, and often lonely occupation – especially if you work by yourself, for yourself. Lonely hours at a computer screen does wonders for the soul. However, I think it’s important to remember something:

Programming is fucking awesome.

There are a lot of reasons why this is a popular belief. You’re in charge of a system, and you have to make it work. There are elements of problem-solving, challenges, difficult bits, and best of all, new stuff comes out all the time that makes your job easier. What other craft can enjoy those benefits? Not only that: we’re important. We’re put in charge of critical applications. We do things other people can’t. I’ve heard programmers described as tiny gods, which I think is a pretty apt description.

However, to exempt this post from being just another lousy “isn’t programming awesome?” post, I figured I’d explain exactly why I think it’s fun. And when I say why, I mean physiologically. For science!

The best analogy I can give for programming is flying a plane. When you’re flying, you have to concentrate – or else the plane will crash. This means you have to forget about other things, and focus all your attention on keeping the damn thing aloft. You become a part of the process – a symbiosis of man and machine. You have a purpose, and a goal – and everything else is momentarily put aside.

Better yet, playing a musical instrument. If you lose focus, you’ll get something wrong and ruin the performance. It’s very hard to regain your composure after a mistake. I think the same thing happens when you’re building something. If you lose concentration, you’ll lose your train of thought, forget where you are, and have to start all over again. It’s “being in the zone”.

As any Neuropsychology student will tell you, when you concentrate on something, your breathing becomes rhythmic, and your brain’s beta frequencies increase. The funny thing about beta waves? From Wikipedia: “Rhythmic beta with a dominant set of frequencies is associated with various pathologies and drug effects. For instance, beta activity can be accentuated by sedative-hypnotic drugs such as benzodiazepines or barbiturates”. Concentration = hypnosis!

Personally, I think the breathing is behind all of this. Any time you alter your breathing, you mess with your feelings. That’s why you take ten deep breaths when you’re angry. Religion does this; many religions have some form of breath control, be it singing, dancing, chanting, meditation… you name it. Could the entire idea of a “higher power” be caused by misinterpreting the feelings your brain’s activity gives you during measured, controlled breathing? It sounds possible. Funnily enough, the word “spiritual” derives from the latin spiro, which means – you guessed it – to breathe. It’s my favourite theory.

Some evidence suggests that beta waves are good for you, too. This page says “People who have increased their beta Waves have been known to increase their I.Q. and productivity. beta Brain Waves have also been associated as being a natural antidepressant”. Remember, you get paid for this.

The best thing about the trade, as far as I can tell, is that it’s one of the few professions where you get to be “in the zone” for extended periods of time. So much so that we forget to eat, or become oblivious to our surroundings. It’s a little like being in love.

Programming a fairly left-brain exercise – logical and rational, perhaps even robotic. It’s very rare to see creativity and art in programming. _why was an exception, and I miss him dearly. But, in my experience, there’s a real similarity in the feelings between writing some particularly elegant code, and playing a complicated piece of music. Hell, if I didn’t get paid to write code, I’d do it anyway.

When you feel down about what you do for a living, consider this: musicians only get to be “in the zone” for the length of a piece of music. Even pilots don’t get to be “in the zone” every day. I’d be very surprised if business people really get to feel this kind of “in the zone” at all – no matter what they say.

Release open, release awesome.

Elliott Kember — Sun, 06 Sep 2009 10:35:32 +0000

In December last year, I built my own personal site to advertise my new-found employability – www.elliottkember.com. Then, looking at my twitter background, I figured it’d be cool to have a similar image on my own site – a bit of continuity. Then, I was talking to Greg Annandale when a thought occurred to me:

Why not turn that sexy curl into an adjustable feature?

Well, about 20 minutes later I had it working, pending a few tricky bits:

But nonetheless, I had a working curl. You can check it out on my site.

Even Ryan was impressed:

The code wasn’t very elegant, or configurable, and I hadn’t made it very easy to implement, but the thing worked. I went ahead and linked it to everyone I could find to get them to check it out, and I got a little bit of traffic:

At the time, the wonders of relative scale told me that this was a good thing. But as it turns out, it was nothing to write home about. Yet.

My good friend Rey Bango had an idea:

Why not make my fold into a plugin? I sat on the idea for a while, but decided that I didn’t want anyone else having my cool effect. I wanted it all to myself. On one hand, I use many open-source products day-to-day. My job wouldn’t be nearly as fun or as easy as it would if everything were closed-source. The shared contributions of many contribute directly to my own personal gain. On the other hand, I reasoned, why should I let everybody else profit from my hard work, and share my effect?

I agreed with open-source, I decided, but only when other people were releasing things – in other words, I only agreed with open source when I was the one profiting from it.

A bit later, I was cruising around the internets when I found, in a list of javascript effects, a link to this: a page curl jQuery plugin! After checking the source, and discovering that it wasn’t a copy of mine at all, I pondered how he’d made it onto this list. After all, lists are the backbone of the internet. Get on a list, and you’re set for life. #naiveté.

The answer was simple: This dude release the script as a plugin.

Yes, that says 2AM. That’s the last timestamp I’m going to show. Incidentally, I was wrong when I said “copycat” – that URL clearly shows a date of the 15th of December – two days before I made my page curl. Great minds, etc. I reconsidered my stance on a jQuery plugin.

Should I do it, I asked myself? Should I release this into the wild, destined to be my glory or my shame? Am I releasing the next useless gimmicky, showy, tacky Javascript effect for people to complain about?

Hell yes. Let’s do it. First off, though, I had to refactor my code. I wasn’t having my sloppy mess of javascript sitting around cluttering up the web. So I cleaned up my code, and with the help of a few articles, I turned it into a plugin. This is not a difficult task: I can’t remember which I used, but there are 527 Google results for “your first jQuery plugin“. Pick one – it doesn’t matter which. If it sucks, pick another one. Welcome to Google. If you’re actually reading this article, leave a comment with the code words: “rock you like a hurricane“. That way I’ll know.

Now for the important bit: what should I call it? Adam Cooke and I pondered the issue:

Clearly, this name wasn’t awesome enough.

And with a GitHub repository, the Sexy Curls jQuery Plugin was born.

I spewed some of my trademark absurdity into HTML form:

And I passed it on:

Now, Rey tweeted it from @jquery – and here’s that tweet preserved for posterity:

Instantly, some 3,000 hard core jQuery nerds heard the word about my plugin. RT after RT, FWD >> FWD, and so on. Quietly, my plugin propagated around the internets like W32.Blaster. You can watch the tweet stream – it’s still going. I graced the front pages of Ajaxian, YCombinator News, hit #9 on Del.icio.us, and countless other aggregators. Help even came from other GitHub users – Cheeaun was nice enough to give me a hand.

I also surreptitiously included a link to my Twitter page in the first line of the page. As usual, the internet is just my big race for followers.

What did that do to my analytics?

That’s insane. My pageviews were up by about 2,000%. That’s not all Sexy Curls traffic, either – although it pretty much mostly is.

That’s wa-hay above normal – which means people are clicking through. My name is getting out there.

That’s the content for sexy_curls.html – loads of pageviews, a strangely high time-on-page, and somehow I have made 8 cents. I look forward to receiving it.

As usual, a high Firefox/Safari split. I’m proud of my visitors! Somebody also tried to use their PlayStation:

But I haven’t heard back on whether the curl worked. Even the Googlebot is rendering Javascript these days:

So I guess it’s been checking out my curl, too. Hope it liked it.

What did I learn? Open Source isn’t just kernel-hackers in their parents’ basements. Open Source is everywhere. Anything you do can be open-source. So, if you aren’t already, release stuff. Release good code, release bad code, it doesn’t matter. It’ll end up being better than you could ever have intended. Use other people’s code – FIX other peoples’s code.

So far, there haven’t been many reports of sites using the Sexy Curls plugin. But that’s okay – it did what I intended it to do. It sparked ideas, made a few gaze in wonder, touched the corners of the internet far and wide, and maybe – just maybe – it inspired someone to start writing code.

Code is like a magic penny – write it once and you don’t get any. Lend it, send it, give it away, and it comes right back to you.

On Usability

Elliott Kember — Sun, 06 Sep 2009 05:55:53 +0000

I’d appreciate it if you read this entire article before commenting.

So there I was, in a RyanAir Boeing 737-800 coming back from FOWA Dublin. Having just spent three days partying it up I was a little under the weather. It was late, it was raining, and I wanted to sit ~~back~~ bolt upright, read my Jeremy Clarkson book and drink my €5 Coke.

During take-off, the crew turn off all the lights in the cabin. I like to imagine this is because the pilots think it’s more fun taking off in darkness. I was surprised, though, to hear the sound of chimes from all around me, as passengers pressed the “I need a napkin” stewardess button. Were they so frightened of the dark that they wanted a hug and a €3 cookie? I shrugged it off, and reached for the light-switch so I could continue reading.

I was confronted with this:

That’s right – the buttons have no lights on them. So, when the cabin lights are out, you can’t see which button does what.

Now, the 737 is a good plane, built by clever engineers, and even when bought by the lowest bidder and covered with advertisements, it’s still an engineering miracle. It weighs 80,000kg and is capable of carrying 189 people 5,600km at Mach 0.8, which is no mean feat. Clearly the people who made this machine know what they’re doing. So why couldn’t they, at a cost of about €5 per seat, light up the buttons on the ceiling? I don’t know, but I have my own theory:

Usability is difficult.

As with many things, usability comes from a military background. The concept was invented during the course of World War 2, when the Americans realised they were blowing themselves up with grenades a bit too often to be statistically viable. So they streamlined the product, gave their chaps instructions like “throw it toward the enemy”, and then, as far as the film industry would have it, proceeded to stomp all over Europe smoking cigars and shouting at one another. The P-51 Mustang was a miracle of simplicity too – by reducing the number of switches and dials and buttons, they let the pilot concentrate on what he was doing – which is vitally important when you’re whizzing about over France upside-down at 700 miles per hour.

So clearly, removing things is the shortcut to usability. Everybody’s heroes, Apple, Google, and 37Signals do this to great effect. The fewer buttons I have on my page, the more I start to feel like that Mustang pilot. My Macbook Pro is the Cadillac of the Sky.

The problem is, though, sometimes just removing things isn’t the whole answer – as with the 737 and its buttons. Usability is something that you need to study, and practice, and think about. It doesn’t just happen.

This brings me to Balsamiq. Sure, it’s a great tool, if you like post-it notes and Comic Sans. Okay, it lets you build mockups of your websites that look like drawings. But let’s remember one thing: it doesn’t necessarily mean you know what you’re doing.

I understand what the tool is for, and @balsamiq verified this for me: creating 5-minute mock-ups that can be thrown away. But that’s ALL it’s for. It’s really, really not for full-scale wireframes. If you think about this, it’s obvious. You don’t get to re-use components, there’s no layout grid to speak of, and you can’t save files together in a folder-type-arrangement. The tool simply wasn’t designed to do these things, because it’s not meant to.

But the problem is, it’s available to the masses. And that means people are going to start using it. It gives people the illusion that they know what they’re doing. Being a child of the internets, I couldn’t resist but make a funny image of this, complete with Impact writing. Now, if I were really mean, I’d use it. But I won’t. Well, I’ll use it satirically and then apologize, because that seems to be the way of the bloggers these days:

Thankfully, you’re reading this ENTIRE article instead of just looking at the pretty pictures. Right? Good. You won’t be offended, then, because that image is just for satire purposes – a cheap laugh, and a cheap shot. I’m sorry! I should write for TechCrunch.

The problem is, as I was saying, that your clients are about to start doing usability. They’re going to start doing your job. I’m not concerned about the money involved here: FrontPage, Dreamweaver and .NET have been around for years and I’m still making internets. I’m really more concerned about the quality of what you’ll end up producing, in the same way I love finding MM_* functions in websites that I pick apart. When you lower the barrier to entry, people start using simple products for complicated things – and then you end up with crap.

You can’t tell the client that, either, because they’re proud of what they’ve done. They hand you their stack of .bmml files with a big smile, like a 5 year old who’s finished a drawing. The only difference is that instead of just sticking the drawing to the fridge and giving them a chocolate bar from the Treat Drawer, you’re supposed to publish the drawing, put your name next to it, and then accept the criticism. You don’t want to tell them that what they’ve done won’t work, because you’ll break their hearts with the sad truth, and they’ll go off and find some other poor sap who’ll knuckle down and produce it.

If a client comes to you with a mock-up of their website, that’s fine – they’ve thought ahead and given it a shot. Now, when you apply yourself to it, you have something to work from – and even if you go the other way, you still know what you’re avoiding. But if a client comes to you with their own full set of wireframes, what on earth are you supposed to do?

@ balsamiq is a very clever, and friendly chap, and his product is cool. I like where he’s going with it. What I’m trying to say is that the problem doesn’t lie with the tool – it lies with the way it’s used. The bottom line is: be careful. Just because you can do something, doesn’t mean you can do it right.

In fact, there’s a whole talk I’ve got planned based on that very concept – and I’m trying hard to get to speak at a Future of Web Apps event. Shameless plug? Me? Never. Anyway, it doesn’t matter, because you’ll have stopped reading at the last image and proceeded straight to the comment form to rant at me for being nasty. That’s the beauty of the web – everyone can have their say.

Image credits: Usabilitylabrental.com for the cockpit photo, farmerdoodah on Flickr for the upside-down Mustang, and @elliottkember for the satirical internet image.

Speed: The Secret Code of the Baristi

Elliott Kember — Sun, 06 Sep 2009 05:55:35 +0000

The other day I was in the local coffee shop dealing to my addiction. I couldn’t help but notice that the guys behind the counter were speaking in a foreign language. We’ve all heard this language: “Double cap out, no foam”, “Chai mocha skinny half with space”, “Moon unit alpha, tennis elbow”. It sounds like some kind of indecipherable language – the secret code of the Illumilatté, if you will.

I realise, of course, that these contractions are inevitable when you’re performing a task over and over again. To bring it a bit closer to home, they’re like keyboard shortcuts. But really, I’ve never seen any barista actually save any time by leaving off the “-puccino”. So what’s happening here?

The answer, of course, is perceived speed. It doesn’t actually have to save any time, as long as it gives the impression of saved time.

A good example is this: setting your microwave for one minute and eleven seconds actually takes less time than setting it for a minute flat – because you don’t have to move your finger from the 1 button. 1-1-1 is much easier to type than 1-0-0. Of course, the microwave will be running for a good eleven seconds more, but you aren’t sitting there watching it for eleven seconds – you’re off dicing and slicing, or whatever people do when they cook. I cook by phone.

A lot of this stuff has to do with efficiency of data structures. If you keep all your receipts, you put them in chronological order when you store them, right? Each one has to go into its alotted position. Would you design a data structure like that? A lot of expensive writes? You only ever pull all your receipts out of the box once a year, so that read action can afford to be slow compared with the hundreds of writes you might do. You should throw them into specific boxes (heh, sharding) and sort them in one go later on, or once a week or whatever. It’s like a cron job.(00 18 * * sun ./tidy_room.sh).

I was reading a great article the other day at Assert True which says that twice-as-fast isn’t good enough. A speed-up factor of 10 is what’s required to really make any difference. That really only applies to foreground actions – which are high in cognitive interaction. If something locks up my computer, then a 20-second lockup and a 40-second lockup are pretty similar. They both interrupt my computing experience, and generally tempt me to wander over to the coffee machine.

What I’m effectively doing here is backgrounding the process. It’s still happening, it still takes time, but it requires none of my cognitive space. I only notice something’s happening when I’m actively waiting for it – and in this instance, I’m not. So if the application backgrounds the process for me, it’s doing exactly the same thing. If I can use the rest of the computer while it does its thing, then my workflow is pretty much uninterrupted.

This is why background processing is such an awesome tool. If you have to do 10 non-urgent things when an action takes place, put them all in a queue and report back straight away. This is for more than just server-client requests, too. For example, when I was building Twiggy last week, I found that the jQuery remove() function was really slow at removing all the tweets from the results page. That meant that when a new search took place, the whole application would lock up while jQuery cleared the list. Empty() and .html(”) weren’t fast either. Nothing would make this bit of my application run more quickly.

What was fast, though, was adding a ‘hidden’ class to the tweets and hiding them. That was instant. So, the trick was to hide the old tweets and conduct the search. Now, when a search is conducted, the delay is huge. There’s at least a 3-second gap between clicking search and having the results available. The difference is, this dead time is expected. So I told jQuery to remove all old tweets during this searching process. It locked up the phone for the same amount of time, and probably added to the total search time. But when you’re waiting for the results to come back, you know you’re going to be waiting anyway. The really important thing is that hitting the “search” button has an immediate effect. The old results disappear, and the “searching” text comes up. Things are happening. Happy user!

In interaction science, we’re told that the human brain needs less than 50ms response time between an action and its perceived reaction. Any longer, and it feels as though the system is lagging behind. Symbian, buddy – that’s you. That’s why the ubiquitous AJAX loading gif was invented – it doesn’t actually tell you anything. There’s no indication of how long the action might take, but the main communication is there – something is happening. And that’s important. You’ve acknowledged my request straight away, and told me you’re working on it.

In truth, the difference between the tweet-clearing and the asynchronous searching can be huge. On a cellphone, where latency is really high, the searching might take 10 times as long as clearing out all the tweets. But that’s fine – the user knows this. What I can do, therefore, is hide all the other slow interactions inside this searching query, where they pale into insignificance. Better yet, I can spread the invisible functions out during the course of the application’s usage. If I remove a hidden result every half a second, it takes almost no time at all. It’s effectively a process queue.

So if your app does loads of stuff on a request, like emailing 10 people, or processing credit card stuff, or generally doing ANYTHING with the filesystem, run this process in the background. I use BackgroundJob in Rails for its simplicity, but there are others like BackgroundFu and Starling that have other feature-sets. Some can use multiple processes to run the jobs, and some are kept in memory. Pick the one that suits your jobs best. http://wiki.rubyonrails.org/howtos/background-p...

Either way, remember to keep stuff as snappy as you can. This is an optimization, and premature optimization is the root of all evil – so remember to do this reactively once people are using your application. It’s really just intelligent optimization – instead of spending hours speeding up your code, just leave the stuff that doesn’t need to be done straight away until later, when it can be done in the background. Uploading to S3, rotating and cropping images – there’s loads of stuff. If you have a process that generates big ugly graphs, make it run once every six hours, and memcache the result – because there’s nothing worse than a 15-second page load.

All you need to remember is this: perceived speed is the only test of speed.

Photo: Burt Munro (Anthony Hopkins) on an Indian Scout from here