Monthly Archives: May 2009

batteries…hmmm

we all know that battery life sucks on mobile phones. especially the kind of smartphone mini computer wifi/gps/bluetooth wonders that we’re interested in.

So when it comes to LBS solutions like ours we were faced with an interesting problem.

(a) No data driven push channel easily accesible (iphone o/s 3.0 will provide one – which is great – but that’s only one platform)

(b) Requirement for always-on styled behaviour

(c)  GPS sucks battery life, 3G radio sucks battery life

What does a third party developer do ?

In the end our solution was obvious – but it didn’t seem so at the time. We first thought – Hey no problem – let’s just keep the data connection open the whole time. That way – when you get an incoming echo – you’ll see it right away. Yeah. That was a good idea. NOT.

Problem with that idea is that your smartphone battery dies in less than 3 hours. In other words our users would kill us.

Second idea was to simply Ping the central server every so often to check if there were any new events. Say every minute or every 2 minutes…for 24 hours.

Again – not so great on batteries (startup and shutdown of data connection eventually takes a toll on battery life) – but more to the point it’s kind of daft because the majority of those Pings are wasted.

What we settled on was a third idea – essentially a hybrid of a Polling ping – and using SMS to wake-up the phone you are trying to reach (if it’s asleep – in echoecho parlance)

Tuning the algorithm (how long is polling cycle, what is the frequency of pings within the polling cycle) is interesting – and will be influenced by user activity. It sets up an interesting catch-22 – because perversely if you want to save battery life (for your own phone) you shorten the polling cycle but then everybody else has to SMS you to wake up the data connection.

Yet if you kill your own battery life you save other people money.

So it’s a funny pseudo-altrustic  set of conditions. I think we optimised it well – but as ever – the market users will decide.

Hmmm (again) – this does bring up an interesting philosophical debate – given the battery/push channel constraints – a developer must decide what carries more weight in LBS systems – Time or Accurate Location…Sort of like a version of Heisenberg’s Uncertainty Principle – the more accurate the time sampling of the location the less battery life you will have (or the more accurate the location e.g. GPS – the less battery life you will have).

The solution to this will be a clean push backchannel implementation across all platforms – but we have a long way to until that happens.

new user signup

something that people don’t think about that much with mobile apps (and was touched on briefly in a previous posting – to network or not to network) are the problems with new user signup.

It doesn’t take a rocket scientist to realise that if you don’t make new user signup easy – then the odds are you will never build up a user base for your app and that’s no fun at all.

Basically I divide this into three categories.

1. Finding the app

2. Installing the app/running app for the first time

3. Using the app

At any point we can lose a user if we’re not careful. We’ll get to step 1 – Finding the App – shortly but let’s just consider step 2 – Installing/First run of the app for a minute. Tip of the proverbial hat here to the 37signals guys (www.37signals.com) for advocating utter simplicity of function. Granted they were talking about web design but I think the point is all the more valid in mobile. Especially touch mobile.

It’s been a very interesting experience designing a coherent yet simple user interface across multiple types of smartphone UI.  What we call Touch Only platforms (e.g. iphone, HTC Touch etc), Context Only platforms (e.g. most S60 phones, most Blackberries) and Hybrid platforms (combination of Touch and Context  like most Windows Mobile phones, G1 android etc etc). Btw we use the word context because the primary form of interaction on a non touch platform is a set of cursor keys (or trackball) and a few “select” keys – centered around a context menu.

We wanted to really streamline the design and talked at length about ways to do that.  An engineer heavy response would be for example to say

“Welcome to Echoecho new user – please enter the following details in the form below”

And then have a form ask for First name, Last Name, Age, Gender, Phone Number, Email, Frequency of location checking, GPS Usage Y/N etc etc etc…you can imagine all the possible parameters.

Can you imagine – this is just the SIGN-UP!!! – at this point you’re losing users left right and center. The aim for us was to identify the core functionality of the app – in our case it’s about sharing of location as quickly and as simply as possible – and then NEVER lose sight of getting to that core functionality as quickly as possible. Do I need to know your name for this to work – no I do not – ok so then I won’t ask you for it. That’s it.

Those guiding principles allowed us to develop an extremely simple first-time user experience.

As for step 3 – Using the App – well the proof is in the pudding here. S60 and WinMo will launch imminently – Blackberry, Iphone, Android to follow soon thereafter – suffice to say that we will be practicing what we preach. Ease of use is the order of the day.  As is viral spreading of the app. (which incidentally dovetails nicely into step 1 – If you echo somebody who doesn’t have the app – they’ll get an SMS with an install link right away – so they can get the app. Of course you could find the app on your own in your prospective appstore or via our website – but it’s highly likely the majority of people will simply respond to echoes from friends)

After all – what use is a location sharing app if you’ve no one to share with?