This was written as a guest blog post for Keen IO.

Those that want to cut to the chase, should go and take a look at the project on Github here.

Have you ever found yourself putting off adding analytics until an app reaches its later stages of development and you’re less busy?

I think this is a mistake we all fall into all too often. In a highly competitive ecosystem, users will sometimes be with you on launch and gone the week after. By waiting too long, we can lose our one chance to study early user behaviour so it’s very important that we take every opportunity we can to understand how they interact with the service while they’re around.

But we also shouldn’t be wasting valuable development time installing analytics either. Surely installation should be a quick and simple process leaving you time free to work on the features that truly differentiate your product.

Keen IO is an...

I had an experience the other day that transformed my thoughts on interfaces and I’d like to share it. I believe that not enough of us understand what an interface really is and that this is hampering our ability to provide good user experience.

One of the problems we have when answering the question “What is an interface?” is that we don’t have an accurate representation of what an interface looks like. There is a tendency for us to become confused and pick just one concrete instance of an interface that we know well, leading to responses like “Oh, you mean a GUI” or for those that have read books like “The Design Of Everyday Things” something more physical like a door handle.

Like many people in the tech industry I’ve become acquainted with a small subset of interfaces known as GUIs and this has largely controlled the frame in which I recognise and understand interfaces.

So, like...

I’ve been reading a lot of Taleb recently, and one of the concepts which is repeated over and over again and that is proposed as a rule is of “skin in the game”. For those that haven’t heard of this before, the idea is that: we should not be protected from the downsides of natural volatility if others would be exposed to them otherwise - e.g. a cook should taste their own food as a preventive measure to giving others food poisoning (doing so makes them more careful than they would be otherwise.)

While this concept is a good heuristic for trustworthiness it’s unlikely to survive evolution.

Small transactional costs stop things from existing at the fetal/growth stage. Evolution destroys them long before the long-term benefits demonstrate themselves as it supports short-term adaptive traits over long-term adaptive traits. If you require skin-in-the-game transactional costs then your...

Modern smartphones still use 90s-era vibration technology.

Looking back mobile technology has improved a lot: the screen, the keypad, the internet connectivity, the OS; but do you remember the days when you felt your pocket vibrate and you knew somebody rung you or texted you?

Nowadays a vibration in your pocket could be an email, a tweet, a follow, a like, a new friend on facebook, etc. Your iPhone and Android are in a way even less user-friendly than your old Nokia. Often you need to take your phone out of your pocket to find out whether it’s a spam email in your inbox or a text from your significant other. You might check the settings and see that there is an option to choose different vibration patterns but is that really it?

In order to reduce unwanted distractions and to increase the usability of our devices we should ensure that the connection we have to a phone is not just...

As I traveled back from Belarus last week I glimpsed a photo of a gorilla in a magazine.

I recognised the gorilla’s facial expression as one of anger, and noticed that we share a great deal of similarity with other primates in how we signal emotions through facial expressions. This got me thinking:

1. Why do we share facial expressions with other primates?
2. How and why do emotions get communicated in facial expressions?

Evolution

The universality of facial expressions [1] was noted by Charles Darwin in his book “The Expression of the Emotions in Man and Animals”. Darwin believed that expressions were innate in human nature, and as an anecdote he pointed out that the congenitally blind have similar facial expressions to other individuals. This was later supported by studies in the 1960s by Paul Ekman who found that apart from slight differences in facial morphology it was possible to...

To new readers of my blog. This article was written many years ago, and is no longer the entirety or core of what I believe. It remains here as a historical stepping stone to newer ideas.

1. Understand the overall functional behaviour of the system you must implement. It’s sensible to understand this from the perspective of why (e.g. a customer’s need fulfilment). These behaviours are often represented as user stories or business requirements and are the result of business-driven planning.
2. Distinguish different behavioural domains as components and then define the scope of each of these. The scope of each component should describe the behaviour it must implement in a standardized format or ubiquitous language that is well-understood by everybody involved in the project (BDD). This is the result of joint business/technical planning.
3. Ensure that larger components are broken into more...

1. “The map is not the territory.” Be mindful of what is.
2. Concentrate without distraction.
3. Hold opinions without gripping them.
4. “Invert, always invert.” Impose faces on reality and then ask them contentious questions. Interrogate topics from perspectives of distinct cultures, and reframe in diverse contexts.
5. Use metaphor to sense patterns and generalisations in nature.
6. Normalize knowledge. Define boundaries and interdependencies, formulate opposites, show interactions. Finally form simple principles out of these patterns and generalisations.
7. Compose principles into novel ideas.
8. “Creativity takes courage.”
9. “Show, don’t tell.” Visualisation and narrativisation > verbalisation.
10. Test new ground by lightly stepping on it.

To new readers of my blog. This article was written many years ago, and is no longer the entirety or core of what I believe. It remains here as a historical stepping stone to newer ideas.

There’s been a lot of buzz on RESTful Web Services [1] and yet there are still far too many developers that believe they may implement it by simply using a Rest class provided by their favourite framework.

I wonder if this has been helped by the obtuse or long-winded articles that are out there on the web and so here is my attempt at explaining the concept as concisely as possible:

Building a RESTful web service requires that you stop building the same concepts that already exist in HTTP as part of your API and instead build a uniform API [2] that inherits the HTTP Interface [3] by (a.) treating URLs as resources, (b.) implementing CRUD using the HTTP methods POST, GET, PUT, and DELETE; and...

To new readers of my blog. This article was written many years ago, and is no longer the entirety or core of what I believe. It remains here as a historical stepping stone to newer ideas.

In order to motivate groups to take ownership, be creative and produce their best work, we must align individuals into a team vision [1].

In concrete actions

1. In a stand-up meeting every morning [2]:
   1. What did you do yesterday?
   2. What will you do today?
   3. Are there any impediments in your way?
2. In an email every few days:
   1. What tasks currently exist? Who is doing what?
   2. Show the fundamental directions the group is moving and give everybody a chance for input on this.
   3. Encouragement and celebration of group effort.
3. Make it easy for developers to brainstorm easily (for example, an IRC server). Whatever solution is arrived at, make sure it is obvious.

These abstract directions should also be pursued

1. Pave...