The Human Interface in Mobile Applications - CiteSeerX
The Human Interface in Mobile Applications Lynne Baillie and Oliver Jorns ftw., Donau-City-Strasse 1, 1220 Vienna, Austria {baillie, jorns}@ftw.at http://www.ftw.at
Abstract. This paper describes a new type of application, which we foresee will be available on mobile devices in the future. In this paper we describe how we designed the application. The application is a parking ticket application (V-Ticket) for use on mobile devices. The application tries to match the needs of the user whilst taking into account the problems inherent in small wireless handheld devices such as limited network bandwidth, limited processing power and display dimensions.
1
Introduction
We wished to build a practical application for use on a mobile device. We brainstormed various possible concepts and this resulted in the scenario of a user wishing to buy a parking ticket. Scenarios have been used in the past to aid designers in building applications which take into account users needs[1, 2]. We first of all used a conceptual scenario to aid us in our discussions with users and to help us collect user stories. ISO13407[3] recommends that we should understand the specific context of use and try to understand and specify the users’ requirements. By collecting user stories and incorporating these into our conceptual scenarios we hoped that we were fulfilling part of the ISO13407 remit. Some of the issues raised by users were common place and recognisable to all of us who have undertaken the task of purchasing a parking ticket e.g. not having enough change for the ticket machine, paying for time not used, having to locate the nearest ticket machine and having to dispose of the ticket after use. We further learned that users have only a very limited time span in which to carry out the task of ordering a ticket. After collating the user stories we began to move away from a very conceptual scenario to a more concrete one. For each of the user stories in the corpus we worked through the descriptions identify the various objects and the actions that are performed. From this we constructed a concrete scenario that contained more detail and more precise information about the application and how the user would interact with it. We then moved onto the third part of our user centred design process: production of possible design solutions. In the first part of the paper we describe the application and how it is anticipated the user will interact with it. In the second and third parts we describe
the underlying architecture. In the final part of the paper we look to the future and describe the user trials we will undertake.
2 2.1
Application The Application (user view)
The application enables a user to order a parking ticket via their handheld device if it has a GPRS connection. The following steps are carried out by the user in order for them to be able to download the application and access the service: 1. Apply for the service via a website. 2. Fill in an electronic application form (this requests the following information from the user: name, car registration, phone number, two security questions and email address. 3. Download the application to their mobile device (this only takes a few seconds and only needs to be done once). In our discussions with users they raised the point that they may share one or more cars, therefore the system enables the user to registration more than one car. We realised that this was an important addition to the application as a car can play an important role in a user’s family and company life. Figure 1
Fig. 1. Ordering Interfaces
shows the three screens that a user would have to navigate to order a ticket. The screen on the left hand side is the first screen the user will see. The interface offers the following menu options: order a new ticket, cancel a ticket, or view a ticket. If the user decides to order a ticket they merely have to scroll down to ‘Order Ticket‘ and press ’Submit’. Once they have done this the next interface appears which has a list of the vehicle licence plates they have registered. The user in Figure 1 has registered three licence plates and has decided to choose the first licence plate. The user merely scrolls (using the ‘up and down‘ cursor buttons) to the appropriate licence number to select it and then presses ’Send’. Pressing the ’Send’ button initiates the ticket ordering process. After the ticket is registered in the database, the server sends information back to the user which indicates that the ticket ordering process was successful (how the confirmation
looks to the user is shown in the right most screen). The user stories had alerted us to the fact that the users would like to know how long they have been parked for; therefore we included this possibility in the design of the application. This option allows the user transparent control and interaction at any time. Figure 2 depicts the three step sequence to view a current ticket for a licence plate. The user can easily and quickly view the current ticket
Fig. 2. View Ticket Status
and know how long it is since they ordered it, in this case 17 minutes. The user can then either return to the main menu or exit the program. By selecting the second item on the main menu as it is depicted in Figure 3 the ticket cancelling process is initiated. The display shows the active ticket.
Fig. 3. Menu sequence for cancelling tickets
Again it can clearly be seen how easy it is for the user to navigate the system and complete the task. 2.2
The Application (System view)
We now explain, the same operations from the systems point of view, this includes a concise explanation of the underlying database. Once the user has registered on the website the user’s details are captured and a password is automatically generated and emailed or sent via SMS to the user. This password must be used the first time the user activates the application or when the user’s details
change i.e. when the user wants to add a new vehicle license plate or change their personal details. We realize that this does not provide an adequate level of security and would, therefore propose that the password could be used for signing device dependent information using asymmetric encryption techniques. After the validation of a user (e.g. checks to ensure authenticity of phone number etc) and system checks (e.g. the person is not already registered) have taken place each user’s registration information is stored in the systems database. The database stores information about the cars, which are uniquely identified by the license plate number. The concept of user groups (families or businesses) implies that each car may be shared by several users and each user may have access to more than one car, a separate table in the database defines the relationship between the user and the cars they have registered. Once all information about user and their cars is stored in the database the user can start to order tickets. 2.3
System Architecture Overview
In this section we give a brief overview of how data and instructions are exchanged between the mobile device and the server. The components and technologies used in order to produce this prototype application are also explained. During registration the user has to select at least one service, e.g. the V-Ticket application. As figure 4 depicts, the V-Ticket application may be one of many
V−ticket appl. data exchange (iii)
V−ticket (i) appl. request
Service location
(ii)
V−ticket appl. response
Service provider
Fig. 4. System Architecture Overview
services offered by a provider. The user can add or delete an application via the internet or directly from their mobile. If the user wishes to add a new, or delete, an old application the the management software checks whether the new or existing service is available and initiates either a cancellation or a setup operation. We used Java 2 Micro Edition software to help us write the code for the mobile application (API[4]). The communication between the mobile clients and the server is realized by using an open source implementation called kXML-RPC[6] of the XML-RPC[9] protocol which was preferred over kSOAP[5] because of its simplicity. Basically, XML-RPC allows remote procedure calls between a mobile device and a server in a straight forward manner using XML. On the server side XML-RPC is integrated into a Servlet based environment which connects to a MySQL[10] database.
3
Discussion and Future Work
We found that we had many problems in realizing the application. The first problem we encountered in building the application was how complex should it be? For example should we include in our conceptual scenario the possibility of businesses registering their whole fleet of cars? Should the order of the menu change once the user has ordered a ticket with view ticket coming first? What words should we use to confirm the ticket status? We found that discussing the parking ticket scenario with users helped us to concretize the main functions that the application should have. It also helped us to decide that the first prototype application would not take into account the company concept as we could not, as yet, deal with the security issues. On the wording and ordering of the menus we tried to make the interaction as quick and as straightforward as possible. When we were in doubt as to whether we were making the correct choices we would go back to the users who had worked through the original parking scenario with us and ask them their opinion. We did this by sending them the screen shots of the application and a short explanation of the envisioned interaction. We think that this application shows the future possibilities for such applications and is an improvement on the existing SMS system which allows a user to pay for parking via SMS, as that system setup requires the user to pay in advance for their parking or via credit card. This application gives the user the freedom to order tickets whenever they want, for as many different cars as they want and to pay for the parking at their normal billing time. We expect that in the next few months we will undertake some live trials of the application (we have already conducted some mock trials) in Vienna. We would like to add that this is only one possible use for an application of this type and in fact this type of application could be used quickly and easily to pay for all sorts of services.
References 1. Carroll, J.M. (1996) Becoming Social: Expanding Scenario-based Approaches in HCI. Behavior and Information Technology, 15(4), 266-275. 2. Carroll, J.M., Rosson, M.B., Chin, G. & Koenemann, J. (1998) Requirements Develop-ment in scenario-based design. IEEE Transactions on Software Engineering, 24(12), 1156-1170. 3. ISO13407 (1999) Human-Centered Design Processes for Interactive Systems. 4. Java 2 Platform, Micro Edition (J2ME), (2003) URL: http://java.sun.com/j2me/. 5. kSOAP Project. (2003) URL: http://ksoap.enhydra.org/. 6. kXML-RPC Project. (2003) URL: http://kxmlrpc.enhydra.org/. 7. Legion of the Bouncy Castle, (2003) URL: http://www.bouncycastle.org/. 8. Lipp, P., Bratko, D., Farmer J., Platzer W. & Strebenz A. (2000) Sicherheit und Kryptographie in Java. Addison-Wesley. 9. XML-RPC.com. (2003) URL: http://www.xmlrpc.org/. 10. MySQL.com. (2003) URL: http://www.mysql.org/.
Abstract. This paper describes a new type of application, which we foresee will be available on mobile devices in the future. In this paper we describe how we designed the application. The application is a parking ticket application (V-Ticket) for use on mobile devices. The application tries to match the needs of the user whilst taking into account the problems inherent in small wireless handheld devices such as limited network bandwidth, limited processing power and display dimensions.
1
Introduction
We wished to build a practical application for use on a mobile device. We brainstormed various possible concepts and this resulted in the scenario of a user wishing to buy a parking ticket. Scenarios have been used in the past to aid designers in building applications which take into account users needs[1, 2]. We first of all used a conceptual scenario to aid us in our discussions with users and to help us collect user stories. ISO13407[3] recommends that we should understand the specific context of use and try to understand and specify the users’ requirements. By collecting user stories and incorporating these into our conceptual scenarios we hoped that we were fulfilling part of the ISO13407 remit. Some of the issues raised by users were common place and recognisable to all of us who have undertaken the task of purchasing a parking ticket e.g. not having enough change for the ticket machine, paying for time not used, having to locate the nearest ticket machine and having to dispose of the ticket after use. We further learned that users have only a very limited time span in which to carry out the task of ordering a ticket. After collating the user stories we began to move away from a very conceptual scenario to a more concrete one. For each of the user stories in the corpus we worked through the descriptions identify the various objects and the actions that are performed. From this we constructed a concrete scenario that contained more detail and more precise information about the application and how the user would interact with it. We then moved onto the third part of our user centred design process: production of possible design solutions. In the first part of the paper we describe the application and how it is anticipated the user will interact with it. In the second and third parts we describe
the underlying architecture. In the final part of the paper we look to the future and describe the user trials we will undertake.
2 2.1
Application The Application (user view)
The application enables a user to order a parking ticket via their handheld device if it has a GPRS connection. The following steps are carried out by the user in order for them to be able to download the application and access the service: 1. Apply for the service via a website. 2. Fill in an electronic application form (this requests the following information from the user: name, car registration, phone number, two security questions and email address. 3. Download the application to their mobile device (this only takes a few seconds and only needs to be done once). In our discussions with users they raised the point that they may share one or more cars, therefore the system enables the user to registration more than one car. We realised that this was an important addition to the application as a car can play an important role in a user’s family and company life. Figure 1
Fig. 1. Ordering Interfaces
shows the three screens that a user would have to navigate to order a ticket. The screen on the left hand side is the first screen the user will see. The interface offers the following menu options: order a new ticket, cancel a ticket, or view a ticket. If the user decides to order a ticket they merely have to scroll down to ‘Order Ticket‘ and press ’Submit’. Once they have done this the next interface appears which has a list of the vehicle licence plates they have registered. The user in Figure 1 has registered three licence plates and has decided to choose the first licence plate. The user merely scrolls (using the ‘up and down‘ cursor buttons) to the appropriate licence number to select it and then presses ’Send’. Pressing the ’Send’ button initiates the ticket ordering process. After the ticket is registered in the database, the server sends information back to the user which indicates that the ticket ordering process was successful (how the confirmation
looks to the user is shown in the right most screen). The user stories had alerted us to the fact that the users would like to know how long they have been parked for; therefore we included this possibility in the design of the application. This option allows the user transparent control and interaction at any time. Figure 2 depicts the three step sequence to view a current ticket for a licence plate. The user can easily and quickly view the current ticket
Fig. 2. View Ticket Status
and know how long it is since they ordered it, in this case 17 minutes. The user can then either return to the main menu or exit the program. By selecting the second item on the main menu as it is depicted in Figure 3 the ticket cancelling process is initiated. The display shows the active ticket.
Fig. 3. Menu sequence for cancelling tickets
Again it can clearly be seen how easy it is for the user to navigate the system and complete the task. 2.2
The Application (System view)
We now explain, the same operations from the systems point of view, this includes a concise explanation of the underlying database. Once the user has registered on the website the user’s details are captured and a password is automatically generated and emailed or sent via SMS to the user. This password must be used the first time the user activates the application or when the user’s details
change i.e. when the user wants to add a new vehicle license plate or change their personal details. We realize that this does not provide an adequate level of security and would, therefore propose that the password could be used for signing device dependent information using asymmetric encryption techniques. After the validation of a user (e.g. checks to ensure authenticity of phone number etc) and system checks (e.g. the person is not already registered) have taken place each user’s registration information is stored in the systems database. The database stores information about the cars, which are uniquely identified by the license plate number. The concept of user groups (families or businesses) implies that each car may be shared by several users and each user may have access to more than one car, a separate table in the database defines the relationship between the user and the cars they have registered. Once all information about user and their cars is stored in the database the user can start to order tickets. 2.3
System Architecture Overview
In this section we give a brief overview of how data and instructions are exchanged between the mobile device and the server. The components and technologies used in order to produce this prototype application are also explained. During registration the user has to select at least one service, e.g. the V-Ticket application. As figure 4 depicts, the V-Ticket application may be one of many
V−ticket appl. data exchange (iii)
V−ticket (i) appl. request
Service location
(ii)
V−ticket appl. response
Service provider
Fig. 4. System Architecture Overview
services offered by a provider. The user can add or delete an application via the internet or directly from their mobile. If the user wishes to add a new, or delete, an old application the the management software checks whether the new or existing service is available and initiates either a cancellation or a setup operation. We used Java 2 Micro Edition software to help us write the code for the mobile application (API[4]). The communication between the mobile clients and the server is realized by using an open source implementation called kXML-RPC[6] of the XML-RPC[9] protocol which was preferred over kSOAP[5] because of its simplicity. Basically, XML-RPC allows remote procedure calls between a mobile device and a server in a straight forward manner using XML. On the server side XML-RPC is integrated into a Servlet based environment which connects to a MySQL[10] database.
3
Discussion and Future Work
We found that we had many problems in realizing the application. The first problem we encountered in building the application was how complex should it be? For example should we include in our conceptual scenario the possibility of businesses registering their whole fleet of cars? Should the order of the menu change once the user has ordered a ticket with view ticket coming first? What words should we use to confirm the ticket status? We found that discussing the parking ticket scenario with users helped us to concretize the main functions that the application should have. It also helped us to decide that the first prototype application would not take into account the company concept as we could not, as yet, deal with the security issues. On the wording and ordering of the menus we tried to make the interaction as quick and as straightforward as possible. When we were in doubt as to whether we were making the correct choices we would go back to the users who had worked through the original parking scenario with us and ask them their opinion. We did this by sending them the screen shots of the application and a short explanation of the envisioned interaction. We think that this application shows the future possibilities for such applications and is an improvement on the existing SMS system which allows a user to pay for parking via SMS, as that system setup requires the user to pay in advance for their parking or via credit card. This application gives the user the freedom to order tickets whenever they want, for as many different cars as they want and to pay for the parking at their normal billing time. We expect that in the next few months we will undertake some live trials of the application (we have already conducted some mock trials) in Vienna. We would like to add that this is only one possible use for an application of this type and in fact this type of application could be used quickly and easily to pay for all sorts of services.
References 1. Carroll, J.M. (1996) Becoming Social: Expanding Scenario-based Approaches in HCI. Behavior and Information Technology, 15(4), 266-275. 2. Carroll, J.M., Rosson, M.B., Chin, G. & Koenemann, J. (1998) Requirements Develop-ment in scenario-based design. IEEE Transactions on Software Engineering, 24(12), 1156-1170. 3. ISO13407 (1999) Human-Centered Design Processes for Interactive Systems. 4. Java 2 Platform, Micro Edition (J2ME), (2003) URL: http://java.sun.com/j2me/. 5. kSOAP Project. (2003) URL: http://ksoap.enhydra.org/. 6. kXML-RPC Project. (2003) URL: http://kxmlrpc.enhydra.org/. 7. Legion of the Bouncy Castle, (2003) URL: http://www.bouncycastle.org/. 8. Lipp, P., Bratko, D., Farmer J., Platzer W. & Strebenz A. (2000) Sicherheit und Kryptographie in Java. Addison-Wesley. 9. XML-RPC.com. (2003) URL: http://www.xmlrpc.org/. 10. MySQL.com. (2003) URL: http://www.mysql.org/.
