Posted by Joel Low on 3 September 2013 | 11 Comments

Tags: , , ,

This is a direct response to the requirements for Assignment 2.

Background

Apple developed iOS Maps in response to the maturity of Android as a competitor to the iPhone. It wanted to remove the dependence on Google's Map APIs that the iOS Maps application has used since it was first written. However, the implementation of the application was poor for the first iteration, leading to much criticism over Apple's decision to replace Google's Maps in iOS 6. There were a few key takeaways from the presentation (among many)

Takeaway 1: What you build has consequences

This should be true. Otherwise, it just means that what you've built is inconsequential, and we should not be concerning ourselves with inconsequential things (there are more important things in life!) Maps was evidently a heavily used application in the iOS ecosystem, as shown by the backlash that accompanied the change. Changing its data stream from Google (tried and tested) to TomTom and AutoNavi (should be reliable, right? They manufacture GPS navigation systems!) resulted in many criticisms.

We saw a few examples of the new Maps application's failures: cities being placed in wrong locations, "roads" leading to nowhere, roads which don't exist. A couple got stranded in the middle of a desert area because Maps brought them offroad. This could have been dangerous if they were stranded. In this situation, not only does it affect people, it could even be life threatening!

The question then is, what should you do in situations like this?

Changing innards: a software engineer's perspective

It's probably a bad idea to change something that is already working. We have a saying in software engineering: if it ain't broken, don't fix it. So why did Apple do something like that?

Even if they really were dead certain that the alternative solution they were proposing was actually better than the existing solution, were they able to back that up? It seemed as though the decision to change their data stream was not considered properly, or that it was not perceived that Maps was an important application. Both were proven false, on hindsight.

Why didn't you test?

What was even more interesting, from my perspective while listening to the presentation was, why didn't you test? Maps is a world-wide application. If they did test, who was it with? Just 5 Apple employees? Testing should have weeded out these inconsistencies before the public ever saw it.

Throughout my stint in CVWO, anyone who dared present anything without testing would be shot down. I'm sure out there in the cruel, cruel world out there, the same is true. It's common sense - always test before you do anything. But in the heat of development, it's hard. Apple probably made this mistake. We should try not to repeat this.

The easy way out

Apple could have just done what Google's famous for doing. It's a beta.

Takeaway 2: Polish affects impressions

It's not just for this app, but for all the other presentations as well. This struck me especially for iOS Maps because of Apple's reputation of creating human user experiences. Apart from the main gripe about accuracy and usefulness of data, the rest of the complaints were all UX. Apple has been chided for not having good offline map support. The app also has awkward one-handed use, needing two hands to smoothly use the app.

Build good user experiences

The majority of the apps I've written were for myself or small scale apps. I did not have a professional dedicated to UX, so I came up with the best I could. Which arguably probably wasn't the best. However, I should pick up some of the ropes. The UX could be the only thing the user ever deals with (because otherwise they get so frustrated and then refuse to use your app any further.) Good, thoughtful UXes generally got positive praise and users tend to remain faithful to it; badly designed UXes cause users to loathe the app and they will eventually stop using it.

Know your use cases

A side effect of this was that Apple probably lost track of what the use cases were. Apple probably thought the Maps app to be used only for driving, and optimised purely for that. They should have done some use-case analysis to see that their expectations matched that of their users, and implement features as such.

Contrasting with gothere

Gothere was also presented as an earlier app. I found that while Gothere was purely for Singapore, I think they did not make the same mistake that Apple made with Maps. Kudos to them. Sometimes, small is nimble, agile, and beautiful. :)