Launching on the App Store – It’s simple physics

Written by David Frampton @ 1:55 am, November 27, 2009

I’ve been asked a little about my thoughts on marketing in the App Store lately. Back in the early days I felt qualified to say a lot, and did, but not so much anymore. However, I am very aware of just how difficult it is to get any kind of traction these days.

Word of mouth is king on the app store, but how do you get enough people using your app to start with so your good app can turn into a recommendation dirty snowball?

There is one important thing I feel developers can do but often fail at. So I’ll share this little tidbit of opinion, you can take it for what it’s worth.

Quite simply, it is: Do all your marketing at once, the very best you can.

That might seem obvious, or might not, I’m not really sure. But I often see developers launch an app with not a lot of fanfare, then when it doesn’t do very well, they try every different marketing method under the sun, one by one.

This is bad.

People are far more likely to notice a launch with an explosion of press than one with a puff here and there, and the press itself is more likely to notice the explosion too.

Basically it’s like a game of Crash Lander where instead of landing, you have to get off the moon. Earth is a far better place anyway. But on your earlier journey to the moon, Bubbles kept accidentally strapping the wrong tanks of gas to the side of the rocket, so now you have a dozen tanks of rocket fuel lying around, but you don’t know how full they are.

Do you:
A) Try them all one after the other, to see which one runs long enough to escape the moon’s gravitational field, or
B) Strap em all on and light em at once.

It’s simple physics. Do everything you can to get your app noticed on day one. If your launch fails, you’re going to have a hard time finding an alternate escape plan.









Web Apps Suck

Written by David Frampton @ 6:23 am, November 14, 2009

I know I’m going to get hate mail for this one… but here goes.

Recently I’ve been thinking a lot about user interfaces. I became enraged by the terrible user interface of Daz Studio, and then had the pleasure to use Motion. I have generally been using a large number of applications lately, and am currently creating my own fairly complex level editor for Chopper 2.

I could write many blog posts about all the different lessons I have been learning recently, but one in particular stands out.

Web apps suck. I’m talking about the web interfaces to the google suite, the photo editors, the facebook website. Apps that run in web browsers, any app that requires an internet connection to function at all, and does most of its work on a server somewhere.

Of course web apps have their uses. I don’t think they should all just go away, it’s nice to have a web app when nothing else is available. But what I’m saying here, is that compared to a native application, web apps are very much worse, for many reasons.

In the most simplistic sense; you need an internet connection, so your ability to access it is unreliable, you get presented with foreign looking – and behaving – buttons and sliders, and the service could go up in price, or simply disappear on you at any point.

But even if that is OK to you, and you like living on the edge, there is still the yucky user experience due to client-server communication. This is what I’m focusing on here.

The latency between action and response in web apps can be horrible, and this fundamentally comes down to the latency between the client and the server. A problem that I can’t see any solution to in the next decade or two.

Currently, the internet can be a little slow at times. It doesn’t matter if it’s due to server overload, bad local wifi or network, slow or misconfigured databases or whatever… there are many, many reasons why a ping to an app server might take a while, and it always seems to take ‘a while’.

Clicking a button in a local/native application, doing a minor computation, returning and displaying the results takes no time. I mean you simply cannot perceive the time it takes for the button to flash, simple data to get computed, and the result to be displayed. It’s stupidly fast.

Clicking on any button in any web app could take any amount of time. Usually it’s fast-ish. Sometimes it even appears to be as fast as a local app. But it’s not, and sometimes it is far worse.

So every web app, no matter how much it tries to pretend to be a native app, is reliant on the connection to its server, and hence can’t rely on some data being available. If you change some state, you can’t guarantee the state change was valid until the server responds. If you scroll down a list, you can’t guarantee that the new items being revealed will be available, or even still exist.

Most of the time it kind of works, kind of a bit slow, but OK. Every now and then someone turns a microwave on, and you wait. Every now and then someone changes a standard or a server config file, or you upgrade your browser, or the database overloads, and it all goes to shit. You might even lose all your data, despite your everything-in-triplicate local backups of your own machine’s data.

This is Bad. It will always be bad. As technology improves, the technology that uses it also improves. And web based apps are a step behind. Web apps will always have higher latency, more interface issues and a less ‘native’ experience. They will always be a worse user experience than native apps, with less user control.

So why make web apps? Because it is easier. Because a developer made a website, and suddenly it turned into a web app. Because a developer wanted to make something simple for Windows and Mac and iPhone and Linux and couldn’t afford to do it properly. Because a developer intends to inject advertising into the experience at a later date.

Most web apps don’t even have a revenue model. Those ones are figuring out how to capture people so they can spam them or sell their details later.

Web apps suck. They are a poor substitute for a native app, and will continue to be so, for many reasons, for many years to come.