![]() |
|
![]() |
|
| Home | Introduction | The Team | Back-end | Cellphone Interface | Web Interface | Downloads |
![]() By Tshifhiwa Ramuhaheli |
|
The use of Cellphones has increased significantly over the past few years. As a result of these developments, the need for Cellphone applications has increased significantly. These applications are very useful in order to accomplish certain tasks at hand since many people usually carry their Cellphones everywhere they go. The Cellphone interface is aimed at solving shopping list problems by allowing users to manage their shopping lists efficiently.
+ Design and Implementation 1. Design and ImplementationThe Cellphone Shopper application was designed using a user-centred design approach. Users were involved from the beginning for the purpose of gathering system requirements and in the prototype stage. The communication protocol used by the Cellphone interface and back-end of the system is SOAP over General Packet Radio Service (GPRS).1.1. Technology and ToolsJava 2 Micro Edition (J2ME) was chosen as the development environment for the Cellphone interface since it provides cross platform applications and there are more Java-enabled phones on the market. The platform independence provided by J2ME can therefore determine the success of an application due to the wider coverage of handheld devices. The device profile supported is MIDP 2.0 since it provides support for SMS, MMS, calendars, contacts and Bluetooth in the form of JSR-82. Even though J2ME applications are slower since Java applications run on the Kilobyte Virtual Machine (KVM), these applications still provide reasonable response times.1.2. Interface DesignTwo groups of users were involved in the design of the Cellphone interface. Different types of users were interviewed ranging from people who do not use computers regularly to frequent users.1.2.1. Gathering System RequirementsThe first group of users was selected and interviewed to find out how they manipulate shopping lists. This group of users was comprised of people who do shopping for the whole family to users who shop for themselves only. Different shopping patterns and habits were discovered through this interview process. The users were also given a chance to suggest which features they would like to see in the system. The features which were suggested include:
1.2.2. First Prototype SessionThe second group was composed of mobile experts and they were involved in the actual design of the interfaces through a paper prototype session. The prototype was presented as a basic interface with limited functionality and was improved during the session in order to provide better functionality. The interface was designed in such a way that will suit the small screen and at the same time making it much easier to access the features of the system. The resulting interface was also assessed in order to remove any aspects of the design that did not conform to the design principles for mobile devices. Another aspect that was addressed in the session was designing an interface that can support both novice and expert users of the system. This was illustrated by having an interface with the same icons in the different interfaces which will match and best represent the tasks at hand.Some of the suggestions made included having auto-complete for the item name and drop down boxes for item category and shop name. The multi-select screen for delete could also use strike-through text for deleted items. Options can be mapped to shortcut keys that are oriented or numbered as in the interface. For example, while viewing the list by category name the right arrow can be used to select a category and the left arrow used to go back. Some of the suggestions made were addressed towards the functionality of the system like caching of events on the phone and sending the information to the server as a batch in order to minimise the cost of creating a connection every time a change is made within the application. 1.2.3. Second Prototype SessionThe second prototype session included some of the expert users from the first session and new users. The aim of the second session was to assess the developed system since the first prototype session. The second session was conducted using the Sun Mobile Phone emulator and all the options available were ran at least once and assessed. The aim of the session was to improve on the usability of the system as a whole. Several screen layouts were rearranged in order to group similar functions together and at the same time improving on the usability of the system. Changes made included regrouping of menu options in the main menu and renaming some menu options in order to remove any ambiguities that may arise.The order in which fields are arranged while adding a new Item to the list was also changed. The item fields were rearranged based on importance or by putting first fields that are commonly used when adding new items. The screenshot on the left shows the order of fields for the prototype and the screen on the right shows the final arrangement adopted. The Item category field was placed second since it is needed when arranging lists based on shop layout and it is very crucial in defining the type of item being created. The item note field was placed last since users indicated that they use notes for items less frequently on shopping lists. Other suggestions included adding more options for a user while they are viewing items in the list. New options that were added to the menu include allowing users to change the ordering of items in the list, a quicker way to switch to another shopping list and a quicker way to switch to shopping mode. Users should not be shown list options that are not applicable, like delete items, edit items and start shopping if the list is empty. Options like add reminder were removed from the list and placed under the reminders menu. This was done in order to minimise the number of options available when viewing items since the number of options available were increasing beyond the desirable number that can be displayed on a small screen. Another option that was removed was "View Item Details" which was now mapped to the select button, so that when a user presses the select button the item details are displayed. 1.3. User Interface Work FlowWhen a user runs the application the Login screen is displayed where the user has to enter the username and password information that is used for authentication purposes. Once the user is logged in the next screen shown is the notification screen which displays all the changes made to the lists since the user's last session. Reminders which are due are also displayed as part of the notifications. If the notifications are not available the user's default list is then displayed. When viewing the available list the following options are available:
In the figure above, above the Screen at the centre displays the current list being viewed and the others screens represent the options that are available. 2. TestingSeveral tests were conducted on the system in order to detect any errors and bugs that are in the system. The aim of these tests was to make sure that the quality of the software being developed is up to standard. Black Box and White Box testing methodologies were conducted in order to fully test the system as whole. These tests were done before the final user studies were conducted in order to make sure that the system is robust and does not affect the usability test conducted with users. After the system was deemed reasonably functional the final user studies were conducted in order to evaluate the usability of the system.2.1. System TestingThe system was developed using an iterative approach where modules were integrated to the system one at a time. After a module was integrated into the system, tests were conducted in order to identify any problems that may arise from the integration process.2.1.1. Black Box TestingBlack box testing was used to test the functionality of the system to make sure that all the requirements specified are satisfied by the system. Data used for some of the tests was carefully selected in order to assess the correctness of the system. Incorrect data was used to determine if the system would be able to handle the data accordingly. As a result the incorrect data could not be accepted by the system since input data fields were restricted to certain data types. The system was able to pass all these tests and as result passed the testing phase. The following test cases elaborate more on the different tests that were conducted.2.1.2. White Box TestingWhite Box Testing was conducted mostly to assess how the Cellphone application will deal with network problems. These tests were conducted to cover the different scenarios that are handled by the cache and the phone's internal memory when updates can not be sent to the server. This was achieved by using the application when there was no network or when the phone did not have airtime. These tests were conducted in order to fully test all the cases that were handled by the Cache module for storing updates on the phone's internal memory. White Box testing was used mostly to test the final application in order to fully test all the available paths of the system after the integration process. The Application was able to pass all the tests conducted to address the paths that wouldn't normally be taken when using the application.3. User EvaluationUsers were involved in the final testing of the developed interface. This was done in order to evaluate the usability of the interface. Usability testing was conducted with nine users, where three were considered to be experts in the field of mobile devices. Fours users were considered to be novices and they did not really have any experience in using mobile applications. The other two were average users who occasionally used mobile applications.The tests were performed on a Nokia 6288 and each user was asked to perform a set of pre-determined tasks on the application. These tasks covered all of the core features that are available on the mobile application. For each new screen that a user encountered they were asked to explain what they think the various components on the screen are for. Users were asked to perform the following tasks on the system:
4. ConclusionsThe Cellphone Shopper application was developed for the purpose of managing shopping lists that can be shared among several users. The developed application meets most of the requirements that were specified and allows users to share shopping lists efficiently. Here is the list of problems that the project was supposed to address:
> Show All Sections < Hide All Sections |
| Home | Introduction | The Team | Back-end | Cellphone Interface | Web Interface | Downloads |
Cellphone Shopper, a 2007 University of Cape Town Computer Science honours project
|