When I was at University, I remember my compiler professor telling me the four rules of writing a compiler: “Make it right, make it right, make it right, make it fast”.  The point was that no matter how fast the compiler was, it was worthless if it didn’t operate correctly; and close wasn’t good enough!

It has been quite a few years since that class and I have learned that “absolute reliability” is rarely the best plan; of course, there is a big difference between making a compiler (or a bridge) and making a website.  (None of my projects have actually ever been life-or-death, despite what some of my clients have thought.)

Here are my updated “rules” for mobile developers:

  1. Keep it simple
  2. Keep it simple
  3. Keep it simple
  4. Form over function
  5. If you need documentation, it’s too complex!

Simplicity

Really, keep it simple!  Simple user interface, simple design, simple functions.  Don’t compete with a desktop application; if your users wanted a desktop application, they would have brought their computer with them.

People use mobile devices differently than they use their computer; there simply is not enough real-estate to stuff everything on-screen.  But more than that, people “think” differently when using mobile devices; they are in a different frame of mind.  Perhaps someone is in a waiting room, checking their e-mail: chances are they only want to know if anything urgent is going on; they are not going to reply to any significant topic or start some long involved process.

Mobile devices are filling in the gaps in our time; but they are not central.  Think about it, you plan your day around work or school or meetings, not around using your mobile phone .

Form over function

How can I really mean this; after all, aren’t people actually buying functionality?  If you want art, go to an art store…

Look, a certain degree of functionality is assumed: no one edits text with a hammer.  The truth is that we (developers) are already really good at dealing with functionality; we’re not so hot at dealing with form; so, if you start focusing on form, you will start to achieve a better balance.  If you design your user interface first, and you can’t find a good paradigm for letting your user select which of 247 tabs to display … perhaps you have too many tabs.  Like designing a good system architecture, if it doesn’t “work” holistically, you might be trying to stuff too much in one design.

If you need documentation, it’s too complex

I think this ought to go without saying, but this is not the case – far too often.  Our lives are getting jam-packed with … well, everything; as a result, we become more selective about where we are willing to invest our valuable time.  If I find a new camera app that looks really interesting, I might try it out.  If I do, it had better work and work easily; I don’t have time to “learn” how to use a new camera app – the one I have now is good enough.

Need another example?  When was the last time you actually read a car owner’s manual?  Okay, maybe you wanted to know the unlock code for the radio’s anti-theft device… but chances are you never even bothered with it before then.  Yet, you still drove the car.  Maybe you remember drivers’ education classes and carefully make sure you know where the wipers are before driving a rental car?  You probably just had to locate the wiper control and look at the symbols to see which way to turn the control.  How would you feel if you had to open the owner’s manual in order to find the wiper control; or if you need press a special button to select which wiper it controlled?  We take these simple matters of standardization and ergonomics for granted when dealing with cars; why should we have to become experts to operate our phones?