For as active as iPhone application development community is, achieving success in iTunes has been an elusive affair for those who participate in this vertical. The two main obstacles presented to anyone who wants to create an iPhone applications are: one, finding resources/developers with the right skill set; and two, marketing the application after the application has been submitted. The bad news is Apple keeps iTunes a black box. Unless your application has been reviewed or mentioned on review sites or blogs, no one will be able to find your application outside of iTunes. This makes marketing your application relatively difficult. Here’s the good news: the cost to build an iPhone application should come down substantially as it no longer requires a developer with an exclusive knowledge to a specific technology to build an application for iPhone.
When Apple first announced to openly accept applications from developers, the prerequisite for the developer is a somewhat extensive knowledge in a language called “Objective-C.” For a short while, it would seem as though the developers who could produce Objective-C codes were superstars that also came with a superstar price tag. Such stardom, however, did not last. When
was released in the commercial sector that provided the necessary development tools to the vast number of C# developers across multiple platforms. And to unhinge the final bar from the floodgates, Adobe has
that the next release of Flash is capable of compiling a flash project directly into native iPhone application. Simply put, a project can go from design to finish without even being touched by a developer.
The implication for this phenomenon is a curious one: how will Apple respond to the rush of new applications when the floodgates are finally open? Will Apple still be able to keep its manual review process intact? When the market is saturated with developers and applications, will Apple be able to to maintain iTunes exclusive distribution channel and continue to motivate merchants to participate?
How all of this will affect Apple or iPhone developers is yet to be seen. However, one thing that seems to be true is that when given enough demands, people will find ways to liberate a technology regardless of how businesses are structured around it.
My New Smile 1.1 iPhone application is available! For those of you who aren’t familiar with it, it’s a clever little application that allows you to first capture photos of friends and put some wicked “smiles” on them.
How does it work? You first pick a victim from the existing iPhone photo gallery (or take one on the fly.) Once that’s done, you may use the interface available to zoom in the mouth area and draw an outline around the mouth. Now, you can choose a new set of death for your friends… if you do it correct, you just may have a real creepy photo on your hands that you may share with your victim’s friends and family.
Download and give it a try!
Until web coders and designers become one and the same, how does one deal with designing a website that is user interface heavy? Does it mean that all designers should learn to code? Or should all coders learn how to design?
I often come across site specification that came with both feature description and mock designs attached to it. In the olden days when everything is static, this was perfect. Each mock is treated as a definite state and you can easily see the flow operational flow from one mock to the next. For example, if you have a form submission page, then you have a submission result page. As a user, you are trained to think that everything works like a two-step cha-cha: submit, result, submit , result, Ba da bing, ba da boom.
This web behavior, however, is changing. As functionally heavy sties such as social network sites start to emerge, people start to demand instantaneous feedback. Out goes the dedicated landing page for submission result, and in comes the thank you popup powered by Ajax. Although the underpinning of the web infrastructure hasn’t changed, the change of behavior provides a sense of orientation and expedited response that makes users feel more empowered.
Now, what does it all mean for the designers? No longer is it enough for a designer to just make things look pretty. These days things need to be both pretty and functional. Without actually coding to demonstrate the user interaction, designers will be forced to spend incredible amount of time documenting and create a mock for all possible interactions. Worse than being inefficient in using the designers’ time is that coders struggle with the case mysterious user interface and make up their own interaction.
As web design is starting to lean towards the user interface design, I have no doubt that the line that separates a web graphic designer and a web coder will be blurred even more. Until then, I think the best compromise is for people to rely heavily on the communication between the designers and the coders. Some may compare the separation between coders and designers like the model and view, and argue that this separation is necessary. I certainly agree that it’s necessary when it comes to software engineering. I would even agree with that on the theoretic level. But when it comes to human engineering, I would still say that talking is the best user interface there is.