Archive for June, 2007

The end of an era: a Flukebox post-mortem

Sunday, June 10th, 2007

It’s been a fun ride but now it’s officially over – I’ve decided to call it a day on the Flukebox project. To be honest, I’ve made little progress over the last few months but the final nails in the coffin were provided by IndabaMusic. They’ve not been around long, but they’ve already created a slick web site with many of the key features that the Flukebox musician community was going to have. With competitors this good, I think it’s time to find a different problem to solve.

It’s often said that you learn more from failure than from success, and for sure, this project has taught me a lot. Most fundamentally, it has taught me several important things about myself that perhaps I knew but was trying hard to ignore:

  • I prefer to pick a hard problem and spend all day thinking about it than to pick a easier problem and actually solve it. Instead, I should try harder to do something productive without worrying too much about the details or in which order I should complete things.
  • I need to work with other people who are less imaginative but more productive. Not just so that I can sit in my chair and bark orders, but that that my team-mates can periodically encourage me to stop dreaming and do something useful for a change.
  • Apart from occasional toilet and meal breaks, I really can surf the internet for an infinite period of time. Having regular contact with other humans, especially those that ask you “what have you done today?” helps a lot, but ultimately I need to recognise my knowledge addiction and keep it under control.

With that in mind, it’s not surprising that as my team fell apart, so did the project. Although I succeeded in finding some great people with the right skills and a genuine interest in the project, they all had successful businesses of their own as well as full-time study. I knew that it would be a problem from the beginning, but I had hoped that I might be able to persuade them to give me just enough time to make it work. As it turns out, I was being over-optimistic. In retrospect, I should have tried much harder to find team members with time as well as ability, instead of trying to “go it alone” with inevitable consequences.

It’s not all doom and gloom, though – many things have gone surprisingly well:

  • Almost everyone I’ve talked to about my ideas have been very helpful, supportive and sometimes even constructively critical
  • Being given funding from my University to “be entrepreneurial” was a pleasant surprise!
  • Moving to Poland. Not only has it been a lot of fun living here, it’s given me a lot of confidence that I can live a semi-nomadic lifestyle without problems. I mean, if I can live in a country where even “hi” (cześć) is unpronounceable, the deputy education minister thinks that “the theory of evolution is a lie” and government officials are worried about school teachers and even the Teletubbies promoting homosexuality, I can live anywhere ;)

Thanks to everyone who gave me their support and good luck to the IndabaMusic crew – it’d be great to see them grow rapidly and vindicate my ideas! I feel I’ve learnt a lot and am much better equipped to start my next businesses. Watch this space.

Posted in Flukebox | 4 Comments »

Designing for ignorability

Friday, June 1st, 2007

Increasingly, our lives are being filled by interruptions – SMS messages, emails, calls, internet chat conversations, Twitter updates and RSS feeds, to name but a few. Things are only likely to get worse when your new robotic vacuum cleaner demands to have its bag changed and your car starts moaning at you to change its oil.

With all these noises and flashing lights constantly competing for our attention, it’s no wonder that many people get stressed by technology. So how can we aim to reduce this stress when designing software and devices?

Firstly, don’t ask unless you have to. If the decision is predictable, trivial or reversible, it’s not necessary to trouble the user – just do it and let the user change it if they notice something’s wrong.

If some action does need to be taken, present the message to the user in a non-stressful way. Beeps, pings and flashing lights are necessary when the user must take immediate action to avoid impending disaster – but they are so often misused.

Critically, the notification should be ignorable – not just that it is not so distracting as to completely derail the user’s train of thought, but also that there’s no real penalty to ignoring it. Usually this means that the message must be repeated at an appropriate interval. Of course, the “appropriate interval” is not easy to define and will be affected by the user’s preferences and situation. This is an opportunity for creative UI design and perhaps a little Artificial Intelligence.

Let’s take the example of text messages. When my phone receives an SMS, it vibrates and makes a sound. If I’m in the middle of something, I’ll ignore it. If I’m in the middle of a conversation, I’ll ignore it but the conversation will often be interrupted anyway when the my interlocutor kindly points out that I received a message. The trouble is that by the time I’ve done what I’m doing, I’ve often forgotten I received a message and I only re-discover it some hours later when I happen to use my phone.

How could this type of interaction be redesigned to be more ignorable? First, my phone should know if it’s in my pocket or not – in my case, just detecting if it’s dark would do the trick. If it’s in my pocket, it should only vibrate. If I ignore the message, it should vibrate again every few minutes. If this is distracting, I can give the phone a sharp tap and it won’t bother me again for another 15 minutes. Even if I read the message, I should be able to indicate that I will reply later, in which case it should periodically remind me to do that.

It might seem that having more notifications would increase stress, not reduce it – but I’d argue that by making the notifications gentle and ignorable, the fact that I’m not forced to pay attention significantly reduces their annoyingness.

Designing a product to be ignored is a distinctly unsatisfying goal, but it’s one that I think is becoming increasingly important. To preserve our sanity in an increasingly computerised, networked world, both software and intelligent devices need to be designed to disappear.

This post was inspired by my hob.  In our era of global telecommunications and private space travel, you’d think somebody could design a machine to simmer a pan of water without it boiling over.

Posted in Musings | No Comments »