...
IV. Summary of Transactions Page
Clicking the middle icon of the bottom navigation bar takes the user to the summary page. Here, the user can view his or her net balance with all of the other users that he or she has transactions with. The interface is a simple list interface, and when a list item is clicked, it takes the user to the individual summary page of that particular user.
V. Details of Transactions with User Page
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 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.
...
Important Design Decisions
The most important design decision that we made early on was to use Jquery Mobile. Jquery mobile provides a very sleek interface as well as a myriad of API commands that work on mobile devices. By using Jquery Mobile, we were able to implement a clean, sleek user-interface that's finger-friendly. Another important design decision was to use the Django web-framework. Django made it very easy to implement a simple backend to handle data-processing and storage without having to deal with SQL.
Implementation Problems
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.
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 katrinaTask #2: Determine how much marco owe youTask #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 OverviewThe 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:
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).
User 1: Task 1 and 2: No problems.Task 3: Hesitated on which icon to tap on the navigation toolbar. Added a dollar-sign to the amount field but corrected it after getting an input validation error upon submit. Did not know what "include me in transaction" meant. Task 4 and 5: No problemsTask 6: Confused about the organization of transactions by date. Task 7 and 8: No problems. User #2: Task 1 and 2: No problems. Task 3: Toggled 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 after getting accustomed to it from Task 3Tasks 5-8: No problemsUser #3: Task 1 and 2: No problems.Task 3: User was confused about “include me” button and selected it. Upon entering second transaction page, he understood and corrected the selection by inputting custom split.Task 4-8: No problems
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.
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.