Today, I want to write about a crucial topic in app development - software design. It is based on my own experience developing and designing softwares since 1990s. But let me indicate here that I do not have ANY computer subjects qualifications. I do not know a lot of computing terms, jargons, methodologies and I am not even well versed in deployment process, staging, unit tests, CID, blah blah yadda yadda. I was an Electrical & Electronics Engineering Major. But I have always find software development interesting and fun. To create something that people use and benefit from. But I think it is mostly due to the no-bullshit work environment. You cannot lie to your computer. And your computer cannot lie to you. If you input a = 1; There is no way in hell, your computer would say a = 2; Unless you told the computer to add a 1 to it. The honesty with coding, is satisfying.
There are grey areas though. Especially happens when you do not understand the code you are writing. For example, a global variable that is non exclusive, and has multiple threads accessing it, and you are using that variable to do something else, an unexpected result may occur. But the unexpected result occurred by truth. And not by lies. So, if you traverse the thread, slowly, you will be able to see the problem and pin point the cause.
Some people calls Apple fans as sheeple 🐑- dumb sheep that just support Apple whatever they do. I guess, that would be true for any groups of people. There are those who see and acknowledge the truth in a system. And there are those, who follow blindly. As for me, I'd like to believe that I saw the genius in Apple (back when Jobs was still alive anyways). What makes Apple great, was how intricate the consideration in designing every single little things, and how all of them have connections to user ability by human beings. Hence why the Apple's User guidelines were dubbed the "Human Interface Guidelines". There are plenty of extremely important guidelines in there. A traditional software may have a User Manual. But Apple's softwares shall have a Human Manuals. A reminder that the users are actual human beings with feelings, limbs and eyes.
An example of Jobs' genius, is in the simplicity of the OS, namely iOS. Back then, the iOS is so simple, that using the limited iOS fits well in the small device that we carry on our hands. Thus we are more focused in doing work rather than wasting time to figure out how to enable a feature.
There are so many other genius ideas, like gestures, magnetic power port, positioning of power button and volume buttons accessible easily by the thumb, and so on.
Traditional developers often work from codes, to peripherals, to hands and fingers that use them. They prioritize code simplicity and focused on functionality 100%. Apple developers, are taught to work from their bodies, to their hands, fingers, eyes, to peripherals and finally the code and functionality. It is at 180 degrees from what traditional developers do. And that is why it was able to capture so many people by heart.
To visualize and therefore prove the definition of this "reversed approach", lets take a simple data collection represented by a UITableView. I will take my latest app under development as an example, Cars.tomizer:
Looks good? Job well done? Take a look again. What is the problem? Let me list down the issue with this design. It appears that there are only 3 cars here. The scrollbar for UITableView is hidden. So it is not immediately obvious that you can scroll for more. How do we apply the Jobs' Design Principle here? Many ways:
1. Add shadow to the bottom bar, so it appears that the list is behind the bar, and human will guess there are more.
Better right?
2. Alternatively, adjust the cell height, so that the default view cuts off half of the third car, implying, there are more down there. Or combine both:
Now it is even more obvious that this data is scrollable, and there are more down there.
3. Go a little bit further - add a tiny scrolling animation upon opening the view.
4. You can think of any other ways to achieve this. These are just examples of the extra considerations in order to apply Jobs' Design principle.
Most traditional developers will stop at the first step. Their mindset is stuck at the functionality, and as far as functionality is concerned, their job is done. And that is where they are wrong. This case is just one example of the Design Principle taught by Steve Jobs. Go the extra mile to make every little things, work and present themselves in the best way.
And when you start applying these principles, you will find your users, easily figure out things in your apps, and that makes them happy. Their workflow improved greatly, and hopefully that 4 or 5 Stars are coming in.
Testing Your Apps
Once your app is done, as developer or programmer, you often cannot be bothered to really test your app. You are tired and exhausted from coding. So having a beta test team is critical. Their job is to scrutinize your work. Condemn it to hell. And complain for every tiny thing that bothers them. And developer MUST fix all of them.
As for me, a solo indie hobbyist developer, I often simply give it to my kids to test. If even a kid can't figure out how things work, it is a clear indicator that your app design is problematic. And what's more important is for you to SEE the app in action used by another person. See how they interact with it. Which button do they press first, and so on.
Stress test is also important. If you app involves saving data into the phone, add up as much data as possible and try saving and loading repeatedly. Make sure the app does not crash. These are typical test procedures, on the surface. If you wish you could go deeper by testing your app using Intruments or Profiling tool in XCode. I have not really used them though. I rely on good old user test methods.
Summary
As a summary, what I can say about Jobs' Design Principle is - your job as developer does not stop at functionality. Go the extra mile, with human interaction considerations. Add that 5 or 10 more methods, 500 lines of codes or more, to polish the app, so it is easy to use, easy to recognize, that essentially, your ultimate aim is to the point that the user won't even need to "Read Instructions". And particularly, HOW a particular feature works. Does it also involve way too many steps to achieve a simple job? Eliminate steps, eliminate button presses. Use gestures, but don't overuse them. It will be hard to make things simple, as Jobs' said:
Go the extra mile and happy coding!
No comments:
Post a Comment