Category Archives: Programming

Less is More!

At the end of every release of Mouseaddict I go into a slight depression. Why? Because we have to compile a feature list for the next version of Mouseaddict. We look at the ideas we have for a new version of the app. Most of Gene and my ideas come from our own usage of our app. It is, basically, a navigation app. It’s job? To tell you where to go in the Disneyland resort to find what you are interested in finding. As Mouseaddict developers, what is the problem with this? We generally use the app *very* differently. So we see different features as important.

Gene’s idea of the perfect app has very few features — thought out very well and laid out in perfect harmony. Think of Gene as the “Apple way”. My idea of the perfect app? *Generally* the same, but we see the word *few* differently. I see it to mean “simple” — not “less”. I used to think that you could have many many simple features in an app and it would work. I was wrong.

I have known Gene for 20 years. Think about that — 20 years! The biggest lessons I have learned from him, I learned in the last 2 years — working on Mouseaddict. What are they?

1. Less means less: Sometimes it is not that you shouldn’t implement a feature. Sometimes the feature just needs to be moved or designed differently.
2. The customer is NOT always right: Sometimes the customer does not even understand what they want enough to tell you what it is!
3. Consider ongoing costs when you implement a feature: Standalone features are best. Features that require server-side support? Not so much.
and 4. KISS: Keep it simple stupid! Things should be easy to find. The icons should denote what they do. As much as you can, keep to real-world-idioms.

Interface design is important. It is the single smartest thing you can spend time on in your app. It is not as simple as “touch this button to do this action”. A major feature in Mouseaddict is a map. Simple, right? Well we didn’t start out this way. We originally started out by making you go through up to 4 touches to find a location. Why? We saw the implementation differently. To illustrate:

Originally we presented a list of “Lands” in the resort — such as Fantasyland or Tomorrowland. When you touched a “Land”, we presented a list of categories in that land — such as Ice Cream, Coffee, etc. Then, when you touched the category, we presented a list of “places” that pertain to that category. Touching any of these “places” allowed you to go to the detail screen for the “place”. On the upper right of the list of places there was a simple button that said “Map”. This button, once triggered, would take you to the map view that displayed all of these places.

Well, Mouseaddict does not work that way anymore. Why? We found out that many more people were touching on the Map button and skipping the detail screen. It took a bit of time for us to come up with a good solution. Mouseaddict now has a category chooser at the bottom of the map screen. Simply go to the map screen in the app, slide the chooser to the category and touch the category icon. All the pins drop on that map for the places that pertain to that category.

This is a much cleaner solution — and is a solution that would not have come about had I not learned the lessons from Gene. Less is almost always more.

An App for an Audience

Well, our app has been released. You can see it at: MouseAddict….. So, you would think I would be done, right? Wrong! redesign , changes, doubts and guessing are all part of my life now. This is an introduction the mind of a MouseAddict:

So you made the perfect iPhoneOS app! Blood, sweat and tears went into the final product. But wait? After release you realize it is not compatible with around 72% of the iPhone OS product line because you forgot to compile it for anything other than v3.1.3 of iPhoneOS? Urgh. Back to the drawing board. This one is easy. A simple recompile with a new setting for both the Lite and Full versions of MouseAddict. Resubmit it to the app store and wait a short time for re-approval — re-approvals are generally (in my mind) easier…but they are in actuality probably the same to Apple.

Okay, waiting is easy right? Wrong! You see, it is roughly at this point that I call Gene and say: “Hey Gene: I know we just submitted the original app a week ago buuuuuut since we had to do a resubmission anyway, why don’t we add this cool new feature.

Timeout: It is about this time I can hear the blood pressure monitor (that is at my house) start beeping frantically — and it is not even turned on. See, Gene used it once and it has this kind of psychic connection with him ever since.

Okay, time to soften my approach. “Just a minute, Gene … just listen. ” etc, etc, etc. It basically does no good! You see, I made this agreement that MouseAddict would be a specialized program — yet with every idea I have I want to expand it. Not that this is wrong. Brainstorming is great — *if* you stay within the idea of “A small, easy-to-use app with a cool function and a great interface”. The minute you try to shoehorn unnecessary functionality in the app is the minute it ceases to become easy and begins to become confusing.

Here is my main issue: I really want this app to take off. I think it is a good app for people who, like me, go to the park and want to know where to find things. I know this is not the app for people who want to be “socially connected” while at the park. It is hard enough (with the spotty 3G service at the parks) for any “social app” to work reliably. When there are that many people using that many cell phones within that small of a local area then the data portion of anyone’s smartphone is going to suffer. So, to rely on a “social” aspect of any app to always work is not a good idea. So, we did not include a social aspect to this app. Our app is simple. It uses GPS to locate yourself in the park and allows you to choose which “addiction” you want to find. Even without a data connection our app works to locate you, locate your “addiction” and give instructions on how to get there from where you are (using both text and pictures of the area).

For all my complaining about wanting more things in this app, I think we did right limiting the scope. Wanna find a Churro? There’s an app for that!

iPhone Programming Hell

Having decided to create a Native iPhone app last month (more on that in a future entry) I have run up against many brick walls. The biggest trouble, it seems, is that while Apple protects “Look and Feel” for the apps they approve, they cause hell for the developers during implementation.

My App is almost complete and my friend Gene and I decided to release it as a “fremium” style app. This is one where the base app is free but allows an in-app upgrade to an extended feature set. Easier said than done. There are many ways to do this but here are just a few things I have run across:
Parental Controls: If these are turned on, in-app purchasing may be disabled.
Interruption of a purchase: If the user is in the middle of purchasing your upgrade inside the app they are able to, for instance, answer an incoming call. This call/interruption could happen in the middle of your (the app’s) attempt to “check out”. So, Apple, in it’s infinite wisdom sends you a restoreTransaction message the next time your app opens. This would not be a bad idea, actually it is quite a good idea, except: every time my app starts, I will have to check for restoreTransaction. No big deal. Just another layer of complexity.
Network Availability: Apple requires you to monitor network availability during your app if it uses the network at all. This is really not a problem since they provide the code to do this, however it is frustrating to read things like the following by noob programmers: “I could not get the Reachability.h code to work, so I simply fake it.” or “I did not understand how to implement this Reachability so I simply attempt to get a file from my own website. If it times out, the network must be down.” This really proves that the wrong people are attempting to make apps. They are not people who care why these tests are implemented nor do they care about the user experience degradation when they are implemented incorrectly.
Here is the main problem: Apple documentation is like the documentation of many programming environments out there. They give details on the routine, the arguments to the routine and what it does. What they are woefully lacking in is well-written, error free examples of using that routine. Reachability, for example. There is documentation here for Reachability. Not really documentation, but an app that actually does compile. However, they leave it up to you for any kind of instructions on how you would implement this in your app. Reachability is important to many apps…but they create an app that shows status of network interfaces. They do not give suggestions on what commands to put in which methods in your own app.

So, here I am at 10:30 on a Friday night (I know…no social life) congratulating myself that I actually got Reachability functioning and now find myself dreading wading into the uncertain waters of In-App-Purchasing.

Wish me luck.