If you’ve seen any of Chris’ various videos on technology, then you have probably heard him talk about something called “user experience.” Usually when he mentions this term, he is talking about iOS, Android, or some other software. But just what is user experience, and what does it mean?
As a developer, I try to make the things I develop as easy to use for the user as it is for me. It’s easy for me to use, obviously, because I’m the one developing it. I am able to design the application to my specific use case. The problem with that, however, lies in the fact that not everyone will use my app like I do.
To give an example, I develop an app called Hubroid, self-proclaimed as “the awesome GitHub app for Android.” When I initially developed it, I looked at what I did on GitHub’s website and tried my best to emulate my typical workflow on the mobile app. Many iterations of the app have come to pass, however, and many people have chimed in to make suggestions that would improve the application for their use case. They made suggestions that would improve their user experience.
According to Wikipedia, ISO 9421-210 defines user experience as “a person’s perceptions and responses that result from the use or anticipated use of a product, system, or service.” To put things simply, user experience is all subjective. What one user wants to utilize software for will be different than what another might want to do. In the case of iOS vs. Android, iOS offers a very simple, refined user interface that contributes to its user experience. Android, on the other hand, offers a wide array of customization that it promotes to the user. Each operating system has a different idea in mind as to what the user experience should be like. They have their own strengths as well as their own weaknesses. As a result, some people admire an operating system for its strengths, while others admire a different operating system for its strengths.
Of course, there are traits that should be common to any good user experience:
- A stable environment is the first thing that should be established, as it lays the foundation for everything else that follows. If an OS or application is crashing left and right, the user will probably be rethinking their decision to use it.
- Defined, obvious areas to perform common functions are also a must. To use Android as an example, all notifications, no matter where they come from, will appear in the status bar and pull-down notification view. Users know from using Android that that is the area where they should be looking for notifications, so if a dialog pops up all of a sudden to announce a new text message, it would probably confuse them.
- Consistent UI controls are required to ensure clarity. If the default Android drop-down selection control (also known as the Spinner) looks one way, and the same control is styled drastically different in an app, the user might not even know that the two controls behave in the same fashion. Custom styles are okay, of course, but not to the point that a control looks completely foreign to the user.
- A feedback button would also be a much appreciated addition. While it seems like if an app’s experience is good enough it shouldn’t need such a button, I do not doubt that the end user would be comforted to know that the developer cares. Whether they receive bug reports or suggestions, it’ll improve the user experience all the same. Who knows? The developer in question might even get some fan mail.
A few years ago at Google I/O, there was a talk about “jank” on Android. The speaker defined jank as being sluggishness and bad response times. Eliminating “jankiness” is therefore another goal when developing software. If a user presses a button and all of a sudden the application locks up while it tries to perform a function in response, the user will be put off and your app might even be killed for unresponsiveness (known as an ANR in Android). If you’re a developer, make sure any work that might take a while to complete is performed in a thread, as that will allow the UI to remain smooth and usable.
For developers, specifically, here’s a list of things that might cause unresponsiveness on Android if you’re not careful. The same probably holds true for iOS, but as I have never developed for that platform I can’t say for certain.):
- Failing to thread network operations is the number one reason why many applications become unresponsive. For example, what if a user submits a tweet in a Twitter app and it completely freezes the UI while it attempts to send the tweet? You must always assume the network will be slow, and keep the user informed that stuff is going on in the background.
- File I/O, specifically writes to the file system, can be terribly slow. While you might not think saving an image to the SD card or a similar action would take too long, the fact of the matter is that it can. Move file I/O operations to a separate thread.
- Any other long operations should be kept on a separate thread as well. Something like sorting a long list of tasks, for example, could possibly take a couple of seconds to complete.
A general rule of thumb for developers to follow is that if an action takes longer than 200 ms, it should be done on a separate thread so as to not make the UI feel unresponsive or buggy. Doing these things will improve your UI over all and, as a result, the general user experience of your software.
So to recap, when you hear “user experience,” do not assume that it is a strict set of rules on how things must be done. To some extent there are some things common with any experience, but first and foremost, user experience depends on you, the user. If you don’t like the way software works, voice your opinions; it should be allowable through some sort of feedback function provided by the developer. Software development should revolve around workflow, so make sure yours is well known.