Revisiting Pain #1 for local applications, and about the new model for mobile applications
The Argument
The argument is that from the user’s perspective, having to download an application kills the experience, and that people just won’t download.
Yes, it is a pain to download, but it is not a killer.
People will download applications as long as the application brings the right value or makes a difference. A good example of this is Jaiku, the popular social application that needed to be designed as a local application due to the needed integration with the handset’s functionality for presence, messaging and other.
I wonder how many Jaiku users exist, as that number would help understand (and defend or not) this argument about downloading local applications. It is important to realize though that Jaiku users are mobile-sophisticated-kind of users, and probably don’t represent the “critical mass”. BTW, not bad for a local application (and related services on the web) to get acquired by Google — congrats to the Jaiku folks. I always thought that Jaiku gets it.
A Solution is Needed
Downloading local application is the #1 problem from the usability perspective that must be corrected. If people can’t download the application and past that step, who cares about the rest of the issues: fragmentation, portability or whatever. Downloading must be easy, and must work: 1) to find or share the application, 2) to download, 3) to bill (if applicable). This goes inline with bullet #4 and #5 in Tim Bray’s message to the network carriers – Flat Rate Considered Harmful:
4. Build a developer ecosystem. Make it effortless to get in. Build a hot-new-apps social network; maybe in alliance with one of the big existing social nets.
5. Don’t ask developers for any money. But sell the use of your billing system at a really attractive rate, so people can sign up for apps and have it billed to their phone plan. Do it at a scale that an app can charge a dime a month and still make money on scale.
The New Model for Mobile Applications
I am still looking forward to the hybrid or lightweight application model, this is, the integration or convergence of (mobile) web technologies with access to local functionality, perhaps a new type of browser run-time with the (scripting) libraries for/to access local functionality (or even the Java APIs). The Java ME specification JSR 290 kind of started with this path. Recently I learned about Aplix’s JSX. Perhaps Google will be the one to deliver this new model for mobile applications. Will we encounter in this new model the same security issues and paranoia from network carriers that we see today with local applications? Very likely the answer is Yes.
ceo
Hi all,
I agree that installation is a pain. It’s painful for the user and a hell for the developer who has to deal with all problems that remote software deployment comes with.
I personally think that we will end up in something similar to the desktop: Many, many applications (more then most people are currently expecting) will run in the browser, completely transient, without local installation. Only a few will be installed, for example games or heavy weight applications. Look a the desktop, how many apps have you installed?
Just my 2 cents…
Agreed…
[...] Applications and user experience and how people interact is the future of Mobile applications. Mobile web seems to be the future, because we forced ourselves to such path (or evolutionary path?): see Revisiting Pain #1 for local applications, and about the new model for mobile applications. [...]
I agree with enrique, but disagree on the comments…
What we see on the diesktop:
- first generation, app running on the desktop
- second generation: web browser based application
but thrid and remerging generation are rda, rich desktop application, typically air powered app.
I think that the idea is to take the best of both world: really simple exeperience for installation, still heavily network based with local caching, etc..
I think that this would be the best user experience, we already have the underlying technologies (j2me, flash, the browser) we just need the right glue! That’s the problem, Java don’t speak to adobe, browser maker don’t speak (too much) to VM vendor, etc…