From idea to app: what’s the path?

In recent weeks I’ve had the opportunity to help a few members of the Instant Developer community set up projects using the Cloud edition, working from their own app ideas. It was a very interesting experience because it helped me understand what obstacles must be overcome for people who have already developed a lot of software and now want to tackle apps.

Naturally, we approach a new world using the criteria we already know, and people who develop software for a living are therefore tempted to reduce the problem to the technological level, thinking that the solution for creating an app is to learn to use new languages, new frameworks, and new platforms.

What’s the problem with this approach? That there are crucial differences between classic applications and apps that are difficult to detect at first glance; only by understanding them fully can we create apps able to bring the proper substance to the many great ideas I’ve seen.

But what are these differences? I think they can be summed up in three main points.

The first and most essential difference is that apps are not general purpose containers that let you do a little bit of everything. Instead, they run specific and carefully characterized processes. So, a very important rule to keep in mind is to always focus the app.

The second difference is that apps are software as a service. No one will ever be tasked with physically installing the apps on the devices: users do this themselves. And no one expects to attend a training course to learn how to use an app, because it’s operation should be natural.

The third difference is that apps have to offer a state-of-the-art user experience. And today, the state of the art is very, very advanced: professional graphics, real-time operation, and support for native device characteristics are the minimum requirements for keeping up with the competition.

Those people who, like many of us, have already developed a great deal of software, use different criteria: they analyze, develop, and test with a method that doesn’t usually take these differences into consideration. What can help is to set aside the technological aspect until later, and begin with a product design phase.

I’m not trying to steal any work from professional designers here; they are definitely crucial in complex cases. But I do think that there is a basic level that’s within everyone’s reach, and it’s often enough to create prototypes that hit the mark.

In upcoming articles I’d like to go into detail and see how we have handled this basic level in the cases I’ve had the chance to be involved with, so I can present you with a method that might work for everyone.

Would you be interested? Have you ever faced this level of design in building software?