private and commercial development over the past 2 years. The itch to do more in this direction became a motivator that finally could not be ignored. Besides the legal aspects (will talk more on that at another time) the desire to merge the design side which life has been preparing for us (Architecture, Engineering, Modeling, Rendering, Project Management, Design Applications and Utilities and more) and see where it may land. So with that rough framework in place we wanted to apply this to development for the iPhone, which brings me to the first principal we went through looking for what to develop:
Dev Design Principal 01 (in both Revit Utilities and iPhone applications) is to look for things that you need or use on a regular basis. In the case of 100 Percent anytime we are at a meeting or working with numbers, financial reports, etc.. percentages always come up and having quick access to these is pretty important. A few years ago we created a spreadsheet (want a simplified copy, get it here) that has all of this included (rather than recreating the wheel each time). Now that we are using the iPhone in place of a notebook (and surprisingly we are using it more than the netbooks now too) we move into our next design principal (great segue don't you think).
Dev Design Principal 02 - Review what has already been done, if it does not exist this could be a good niche. But what if it has already been done? In our case we saw a couple at the time that had similar features (and for some reason tip calculators are very popular). If the other apps that exist you have to come to terms with the design, if the developers have done a great job on it then go ahead and purchase their app (in the case of iPhone, buy from the app store and support their efforts).
Side Note: You could also look at purchasing to own source code and rights from the developer too, that is outside the scope of this post but one that you *may* want to consider if you have means and methods to do this.
If you believe you can do a better design job than others have, then put your time and resources into it. In our case we believed that spending the time to come up with a great design and interface would mean a better product. In our case one of the more costly examples we did was to avoid using the existing options for numeric entry with-in the Apple SDK. Others have used it and frankly it just did not give us the experience we were looking for, or to put it another way it looked horrid:
Doing this of course meant extra work and provided some hidden gotchas as we went through the debug process and in the end we think this was more intuitive and just feels better:
There is a lot more that goes into the development process and even more prior to that in just getting set-up and approved by Apple (small fact: It took us about 6 weeks to get all the paperwork approved as we were a new company, officially an LLC, and had to resend the same documents a few times to "prove" it). Which of course is another good segue into our next principal.
Dev Design Principal 03 - Define your timeline and make it as short as possible. If you are creating the application as a learning process then you may not be so concerned with the time it takes you to complete. If you are looking at releasing this on the app store the time it takes you to release is very important.
Side Note: There are around
70,000+ 85,000+ apps and growing for the iPhone out there. Within that you can find most everything within the range of Junk to Amazing. Keep a watch for other similar apps during your development efforts.
Your application may not need to have every single item that you want in its first release. For our first app, we scaled back and put in the core essentials. This will hopefully help us in the long run as we now have a released product, the overall UI is complete and allows us to scale it up with planned additional features. The other "surprise" side of this is that releasing asap allows you to get feedback for future releases that might surprise you and take your product in an unplanned direction. While it is too early to see this with 100 Percent, this has occured with other utilities and applications we developed in the past.
Dev Design Principal 04 - Prepare for contingencies as best as you can (aka do not let stupid fixable mistakes be the nails you dropped that pops your own tires). You will want to continue reviewing any similar apps that are released all through the design process. In our case early on we thought we had the perfect name and used that all the way through our dev cycles. Things were going swimmingly and then 1 day before we wrapped up the code for the app store to review and approve another application came out that used that name. You are going to run into any number of items that could slow or stop your project; needing to hire a developer to help, crashed computer and lost source code and more. Keep a back-up system in place at a minimum have the code stored in another location accessible to you, your partners and developers in case something comes up. While we have been lucky so far, others have far worse stories and are put further behind in their development.
Dev Design Principal 05 - Continue pushing up hill and forge the new path. Right now we have a few more ideas that passed Principal #1 & #2 and are currently underway. Since this is a relatively new industry the rules are not all written yet. A good example for us is how we want to market the apps to let people know. On launch day we were not fooled by the mantra "Just launch it and people will buy", we knew a small portion of people would buy because of that. Instead we wanted to sort it out methodically, launch first, add one marketing element at a time to help get the word out at a time. On launch day we posted only a twitter and facebook update to see what would happen. There are several sites out there that will help to review your application, we looked at these prior to purchasing other apps for our own use. This can be helpful and one we are currently working on as not every app gets featured in the nice commercials. :)
Side Note: If you elect to work with the App Review websites, most have a pretty large backlog themselves. Some say days, some say weeks and some just say we have too many!
So this is a new direction for us and one that we are excited about as it compliments the work we do in our current day jobs and lifestyle. So for a new start-up we do not yet have the formula for marketing this down. It is something we are working on as we also are developing more apps, which will come out over the next few months. If you have any ideas that you want to share or thoughts to offer that might be low to no cost options for getting these out to others please comment or contact us.
As an added bonus if you have read this far, a video example of the 100 Percent application as the UI evolved can be seen here:
We are the first to admit that we do not know it all but if you are curious to know more about the process, what we have gone through or some of the other steps we have taken or more we are happy to share with you. If you happen to have an iPhone or iPod touch and have a need for a percentages calculator then please keep "100 Percent" in mind. For now back to work on future applications... ;)