Why is a phone UI so different from a PC application (part 2) ?
In part 1, I discussed why a mobile phone set of applications is radically different from that of a PC, and why it matters. In this second part, I discuss more specifically about the difference in terms of user interface of the applications.
In a PC application, the user can find all the possible actions in a single screen. This is possible and efficient because the user’s actions are executed by clicking on a position of the screen (ie. through a widget) with a pointing device. Additional screens are often used to specify some rarely modified parameters. When an action needs more than one screen, wizard-type screens are used in a one-dimensional navigation way (ie. back/forward navigation). The installation of a new hardware is typical of such a succession of screens.
This means that when an action needs to be defined (ie. information must be entered in several fields, boxes must be checked, items must be selected within lists,...) it's up to the user to decide in which order to enter this information, and he can always see/check all of it at once. There is no pre-programmed navigation.
Furthermore, a PC application is rarely interrupted by unexpected events coming from the platform itself. Of course, on a laptop, a battery alert may be displayed by the underlying system but it will not really interrupt the user, who will just have to acknowledge that by clicking on a button in a window that is clearly not part of the current application.
Last but not least, a PC user has usually been trained to use his computer and he is using it in a dedicated place such as an office....
Things are very different with a mobile phone. First of all, the screen is small and there is usually no pointing device (ie. no mouse nor touch screen). This means that when a component needs to get more than a single information from the user, it must do so by chaining several screens. But in order to ensure a consistent experience, each screen must be specially designed to stay intuitive. As many of these screens are part of the overall application, a screen may often be used in several different contexts: it must be generic, but properly so; otherwise, the user gets lost... For instance, a screen designed to select an entry from the phonebook is used at least in the phonebook, the call manager and the text message composer. Building a generic screen that maintains consistency while guarantying that the action expected from the user is never ambiguous is a real challenge.
So an action is very often split across several screens, each of them being used in several contexts to perform distinct actions.
A mobile phone must also handle unexpected, disruptive events in real time. For instance a phone call may occur at any moment when the user is in the middle of a succession of screens to perform a complex task. During this call, a second call may also occur, and in a well-designed device, the user must be able to directly insert the details of the second caller in his phone book ! In the meantime, the SIM toolkit may issue a request, or a text message may arrive...
If we consider that any of these events must be handled with the proper priority level, and that many qualifications requirements (GSM, STK...) must also be respected, the hierarchy tree of all these screens may get very complex. Much more so than any PC application regarding the ease of use and the cinematic of the actions.
And all this must be kept simple for my mother in law to use !
There are other points making the development of mobile phones' applications complex. One of them for instance is when the handset is sold by operators, which is often the case. In that case, the operator is considered by its customer to be ultimately responsible for the quality of the complete offer, from the handset hardware to the network coverage. Any weakness in this chain is considered a service breakdown. So the applications embedded in the handset must be "carrier grade" and need to minimize calls to the operator’s customer care service. So manufacturers need to design applications with two customers in mind: the operator and the end-customer itself. An additional factor of complexity, and not a small one.
In a PC application, the user can find all the possible actions in a single screen. This is possible and efficient because the user’s actions are executed by clicking on a position of the screen (ie. through a widget) with a pointing device. Additional screens are often used to specify some rarely modified parameters. When an action needs more than one screen, wizard-type screens are used in a one-dimensional navigation way (ie. back/forward navigation). The installation of a new hardware is typical of such a succession of screens.
This means that when an action needs to be defined (ie. information must be entered in several fields, boxes must be checked, items must be selected within lists,...) it's up to the user to decide in which order to enter this information, and he can always see/check all of it at once. There is no pre-programmed navigation.
Furthermore, a PC application is rarely interrupted by unexpected events coming from the platform itself. Of course, on a laptop, a battery alert may be displayed by the underlying system but it will not really interrupt the user, who will just have to acknowledge that by clicking on a button in a window that is clearly not part of the current application.
Last but not least, a PC user has usually been trained to use his computer and he is using it in a dedicated place such as an office....
Things are very different with a mobile phone. First of all, the screen is small and there is usually no pointing device (ie. no mouse nor touch screen). This means that when a component needs to get more than a single information from the user, it must do so by chaining several screens. But in order to ensure a consistent experience, each screen must be specially designed to stay intuitive. As many of these screens are part of the overall application, a screen may often be used in several different contexts: it must be generic, but properly so; otherwise, the user gets lost... For instance, a screen designed to select an entry from the phonebook is used at least in the phonebook, the call manager and the text message composer. Building a generic screen that maintains consistency while guarantying that the action expected from the user is never ambiguous is a real challenge.
So an action is very often split across several screens, each of them being used in several contexts to perform distinct actions.
A mobile phone must also handle unexpected, disruptive events in real time. For instance a phone call may occur at any moment when the user is in the middle of a succession of screens to perform a complex task. During this call, a second call may also occur, and in a well-designed device, the user must be able to directly insert the details of the second caller in his phone book ! In the meantime, the SIM toolkit may issue a request, or a text message may arrive...
If we consider that any of these events must be handled with the proper priority level, and that many qualifications requirements (GSM, STK...) must also be respected, the hierarchy tree of all these screens may get very complex. Much more so than any PC application regarding the ease of use and the cinematic of the actions.
And all this must be kept simple for my mother in law to use !
There are other points making the development of mobile phones' applications complex. One of them for instance is when the handset is sold by operators, which is often the case. In that case, the operator is considered by its customer to be ultimately responsible for the quality of the complete offer, from the handset hardware to the network coverage. Any weakness in this chain is considered a service breakdown. So the applications embedded in the handset must be "carrier grade" and need to minimize calls to the operator’s customer care service. So manufacturers need to design applications with two customers in mind: the operator and the end-customer itself. An additional factor of complexity, and not a small one.
posted by BB | Permanent link
2 Comments:
This comment has been removed by a blog administrator.
This comment has been removed by a blog administrator.
Post a Comment
<< Home