...
Required Title, Total Amount, and Description of Transaction
Required Title, Total Amount, and Description of TransactionThe add transaction page contains fields for the user to enter the title, total amount, and description of the new transaction the user wants to create. These fields are required and if they are completed, PennyPincher will alert the user.
...
The details of transactions with user page gives the user of the application a detailed breakdown of each transaction he or she has with a particular user (in this case, the particular user is "bina"). The view is organized in with collapsible rows to preserve screen space especially on mobile devices. The top level collapsible is the date of the transaction. Within this collapsible holds the titles of different transactions that occurred on that date. Each transaction collapsible holds a "settle" or "dispute" button. Transactions where the user owes "bina" money are disputable and transactions where the user paid for "bina" can be settled when "bina" pays the user back. When a transaction is disputed, a flag icon appears on the transaction collapsible as well as the date collapsible as well, making it easily noticeable to the user. When all transactions of a particular date are settled, the view automatically refreshes, popping the newly settled date down into the "settled transactions" section, and the color of the top level collapsible changes to green.
The option to "dispute" or "settle" a transaction is shown as a checkbox. An alternate design that we considered was using a toggle switch. However, we decided that a checkbox would be more intuitive for a user to tell if the transaction has been disputed or settled. The flags and "settled transactions" section also helped make the status of the transaction clearer to the user.
Implementation
Important Design Decisions
...
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. 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.
2. The testers suggested that there be options on the summary page for how the transactions are listed (by date, reverse by date, name, title, etc). We will definitely take this into account in the next round of implementation.
3. On the first transaction page, the "tap-hold" to delete functionality was not universally liked. Some testers had to read the instructions and think for a bit in order to figure out exactly how to delete a user from the transaction. Overall, the general consensus was that an "x" button to the right of each list element would be easier to understand and use.
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: easy, no problems
Task 3: said “hmm.. this looks like it might add something..”; at first added $ sign to the total amount input field, corrected after received an error prompt on submit; “what does “include me in transaction mean?”
Task 4 and 5: easy
Task 6: confused about the organization by dates
Task 7 and 8: easy
...