Android User Experience
User-experience is a pretty big compound word. That’s why I like to call it UX. Not as many….you know….those things when you clap your hands as you say the words ‘parts’….uhhh…..oh, it’s ‘syllables.’ Not as many of those syllable things, its easier to spell but mostly because it’s easier to spell.
User Experience described
User Experience describes the feeling or the emotion, or what have you, that the user…feels when he or she using a mobile device…or anything for that matter. Usability of a consumer device is incredibly important. There are various philosophies behind what a good user experience is comprised of. But common factors are: ease-of-use, predictability, accessibility and the design of the general workflow that the operating system or software guides the user through to complete a task without creating any confusion on what needs to happen next.
Documenting the Process
I produced a little clip of the Android workflow nended to place a shortcut of an application on one of the panels of the home screen. It really is a simple process, but there’s always a mitigating circumstance…for everything. And what separates a good user experience from a poor user experience is the engineering and the thought behind any and every possibility that can exist. For example, the steps behind placing a shortcut of an application on the Android home screen takes 3 to 4 gestures: a tap and hold, another tap to select an app, or a swipe or two to find the app and tap to select. Then there is an optional replacement of the icon if you don’t like where it’s placed the first time.
Thats it. Just a couple/three.
But sometimes, conditions exist that will change the operating environment. These require contingencies. Contingency is completely reliant on how an UX engineer or a System Engineer creating a custom workflow solution (in the case of application-stringing where multiple applications must be used to complete a process) envisions the user completing the task and plans ahead to account for a condition, ‘What if’ this and ‘what if’ that. In this case we are placing a native app on the device springboard (home screen in Android-grunt) which is completely controlled by the operating system. So the group responsible for this workflow resides within the team that Andy Rubin used to be in charge of, Google’s Android department.
Why user experience is different from device to device
There are five kinds of people:
- Those who have no initiative
- Those who strive for mediocrity
- Those who produce the absolute best they can provide
- Those who quit before finishing for no apparent reason, and
? A myriad of things can occur in between the time that the user decides to initiate the workflow and when the user finishes. For example:
- An incoming call
- Incoming SMS
- Loss of data
- User gets distracted mid-process
- Malware launches pop-up campaign
- Random advertisement presentation
The list goes on. User experience is also influenced by conditions. For example, placing a shortcut on the springboard if you are a first time user attempting to complete this task for the very first time, differs from the experience that someone gets when they have already completed this task. Information pop-ups to help the new user won’t re-occur for someone who has already dismissed the info dialogue box with the ‘don’t show again’ checked.
These are the things that need to be taken into consideration prior to allowing the user to complete task.
Watch the video below for an example of what happens, how a user will react, and the extra steps a user will have to complete to finish the task because the UX engineer was A #5 ‘kind of person’ in the list above. 🙂 Keep in mind that this is simply an Android example. User experience challenges happen across all operating systems. The impact, as stated above, is completely dependent on the kind of person that was in charge of directing the process: