...
Choosing People Involved in the Transaction
When adding a new transaction, the user has the choice to be included in the transaction. The "Add Transaction" form contains a checkbox labeled, "include me in transaction". If the user checks this checkbox, the "People in Transaction" list beneath the search bar will contain "Me" to show that the user has decided to be included in the transaction. To add another user to the transaction, the user uses the search bar, labeled "Search Names". The search bar uses autocomplete, which is populated by a list of all users. To include another user in the transaction, the user simply taps a user's name to select that user. This user's name is then added to the "People in Transaction" list. Additionally, PennyPincher is also set up so that a user cannot appear in the "People in Transaction" list more than once. This eliminates the possibility of users being charged twice in a transaction. If the user made a mistake and accidentally added a user to the transaction, the user can just tap and hold the user's name in the "People in Transaction" list to delete this user.
-Adding a Transaction with One Other Person
...
Although Jquery Mobile made front-end design easier and Django made back-end design easier, linking the two together turned to be more difficult than we originally imagined. One of the largest problems we ran into was performing an AJAX request upon the tap of the "dispute" or "settle" buttons. Since the AJAX request was performed by Jquery, the AJAX request would often not work, causing the entire Jquery method to breakdown and the UI to not update correctly. Besides this issue, however, other implementation problems lied in the use of Jquery mobile, but were all eventually resolved through trial-and-error. In addition to this, we found that while we initially used a binary toggle button to represent "dispute/undispute" and "settled/unsettled," we found that checkboxes functioned much better in terms of programability and cleanliness of interface.
Evaluation
The user testers we found were all volunteers from outside 6.813/6.831. Below is the briefing that we provided along with the tasks we asked them to perform. We decided not to provide a video demo as we felt that PennyPincher was already of minimalist design and funcitonality; watching a video would hinder us from discovering how first-time users would “learn” how to use the application.
Briefing
Thanks for agreeing to help us out! What you see here is part of a project we’re working on for the User Interface Design class (6.813). Today, you’ll be helping us test a new system for keeping track of outstanding expenses among friends and acquaintances. This system, called PennyPincher, and we’re testing parts that allow you to post new transactions to declare that someone owes you money, dispute a transaction you think is incorrect, and view a history of all transactions with a particular individual.
Please keep in mind that we're testing the computer system and design, we're not testing you. The system is at an early stage of development and is likely to have problems that might make it hard to use, so we need your help to find those problems.
Please feel free to think out loud to help us understand your thought process, too! The results will be completely confidential, and you can stop at any time you want. Do you have any questions we can answer before we begin?
Scenario Tasks
- Task #1: Determine how do you owe katrina
- Task #2: Determine how much marco owe you
- Task #3:
...
- * *You went to Urban Outfitters with yolo. He was short on cash and promised to pay you back so you spotted him $5. Create a new transaction that reflects this.
- Task #4: You went to grab dessert with Alex and Jackie that you initially paid for. The total bill (you included) cost $12 and you’ve decided to split evenly. Create a new transaction that reflects this.
- Task #5: You want to see all the transactions you’ve had with alex; navigate to the summary page with Alex.
- Task #6: alex has paid you back for the dessert trip you went on earlier. Mark that transaction as “settled”
- Task #7: katrina posted a transaction stating that you owe her $3.25 for midnight snacks at verdes, but you’ve already paid her back! Mark that transaction as “disputed”
- Task #8: (a) start a new transaction and add marco, eugene, katherine, and aaron. (b) you then realize that eugene and katherine actually weren’t involved in the transaction.. remove them from “selected names”
Testing Overview
The users tested were a Junior course 10 female, a Senior course 6 male, and a Graduate course 15 male. The overall responses/suggestions were as follows:. Because the PennyPincher target audience consists of college students or those who have recently graduated-people for whom even a couple of dollars is pretty important-this sampling adequately represents the user population quite well. The users were all briefed with the briefing shown and the tasks performed are also listed in the Scenario Tasts section. A demo was not performed as we did not think it necessary with the minimalist. Further, we wanted to see the learnability of our application.
One of the usability problems that consistently arose was ambiguity for what the "include me" radio button in the "add transaction" section of the application represented. While all users finally understood what it was there for after the first transaction, there should be a way for us to let them know (perhaps via a dialogue or help message) about its function. While we strove hard to fix a number of the usability problems discovered during the paper prototyping and computer prototyping, there were still some things that were unavoidable and we still had some responses and suggestions as follows:
1. The "include me" button is still a bit confusing initially, but all users managed to figure out its functionality after performing one transaction. Interesting enough, when asked how to improve this, none of the testers could provide good suggestions.
...
Color-Blind Test: We asked a color-blind (red/green) user to test out the application. The user said he could distinguish between the red and green coloring scheme on the home page but felt that the grey icons used in the navigation toolbar looked pink (he wasn't sure if it was grey or pink).
Specific Results
User 1:
Task 1 and 2: No easy, no problems.
Task 3: Hesitated on which icon to tap on the navigation toolbar. Added a dollar-said “hmm.. this looks like it might add something..”; at first added $ sign to the total amount input field but , corrected it after getting received an input validation error upon submit. Did not know what "include prompt on submit; “what does “include me in transaction " meant.mean?”
Task 4 and 5: No problemseasy
Task 6: Confused confused about the organization of transactions by date.dates
Task 7 and 8: easy
User 2:
No problems. User #2: Task 1 and 2: No problems.
Task 3: Toggled toggles the include me button a few times and said , “I don’t know what this means”. User ; initially doesn’t add description until prompted by error on submit--wants to have it made obvious that it is required (or not make it required)
Task 4: No problems easy after getting accustomed to it from Task task 3
Tasks 5-8: No problemseasy
User #33:
Task 1 and 2: No problems.easy
Task 3: User was confused about “include me” button and selected it. Upon ; upon entering second transaction page, he understood and corrected the selection by inputting custom split.
Task 4-8: No problemseasyReflection
Reflection
The development of the PennyPincher application was a long-term, iterative process. Throughout the course of this semester, we discovered the incredible value that lies in user feedback. Every single one of us has gotten many requests for "user testing" before, but none of us really understood how necessary these tests are in developing a great user interface. If we could do it all over again, we would definitely take more time in paper prototyping the single user summary page as well as the overall summary page. The reason for this is after implementing our computer prototype, we realized there were still some grey areas in the design in which we have no agreed on or solidified. Since paper prototyping is much easier than computer prototyping, we would definitely take more time in considering all of the views that the user will use equally, instead of focusing most of our attention on views where there will be a lot of user input. Along with more detailed paper prototyping for each view, we would definitely reconsider the way we tested each tester. Our biggest mistake the first time around was not asking enough questions to the testers and assuming that if the tester doesn't say anything, that the feature/design was "good." Next time around, if we have any doubt about a particular design decision, we will make it a point to ask the user about it, even if the user passed a particular task using that exact feature/design. The lesson learned here is that is best to write and develop a product that will be usable for most people, focusing on usability risks that are likely to arise.
Additionally, if we were to extend or continue this project, we would add a lot more granularity for types of transactions and filter functionality. The summary page, for instance, currently only features a simple aggregated list of all users. However, it would be helpful for users to specify whether they would like to see an overview of all the transactions based on date (and with that in which "recency" ordering) and/or title as well. The "custom split" feature on the "add transaction" section would be fully implemented such that filling in certain boxes would auto-fill the remaining amounts.
Overall, we as a team thoroughly enjoyed the iterative design and implementation process throughout the semester. This semester-long project really gave us all some insight into how difficult it really is to develop a user interface that satisfies the majority of the user population.