Attachment

We attached the PDF version of the Report.

Traxx

Akira Monri

Haoyi Li

Nahom Workie

Design

Record Page

Our record expenditure page is where the user lands upon opening our mobile website, and is the place where the user records down an expenditure that just occurred. This view includes an area for the user to enter the amount recorded, dropdowns to set the date of the expenditure (auto-filled to today) as well as the a dropdown to select what kind of expenditure it is. It also shows a map, to let the user know where the phone thinks the user currently is.

There is a button to associate debts to this record, as well as one to submit the record to the database.

The expected use case for this screen is immediately after the user has spent money. In this case, the only thing the user has to input is the amount: the date and location should already be correct, and the type of expenditure (cash) should be correct for the majority of cases.

The Add Debts button is for the common case where an expenditure is shared by multiple people, and a single person pays for everyone else’s expenditure. This allows the spender to easily jot down who owes who money, such that these debts can be resolved later.

The changes to this page include:

• Removal of the “Take Photo” method of recording the receipt; this was due to technical reasons, as the device camera is not fully supported across mobile browsers
• Modifying the wording into sentence-form: “I spent 0.00” instead of “amount spent: 0.00”, as it is easier for first time users to understand when structured this way

Analytic

Our Analytics page has three views: a List view, which is a sorted list of all transactions that have occured. A Chart view, which allows aggregate expenditures to be viewed over a period of a week or a month. A Map view, which plots out the positions of the various expenditures on a Google Map, for the user to spot geographical trends.

The List view is pretty straightforward. On the Chart view, we wanted to make the chart interactive, but were unable to find a mobile-compatible javascript charts library. As a result, the Chart is static.

The Maps view allows the user to see where he spends money. Clicking on any individual marker will bring you to the detail page for that record, allowing you to view the amount spent and other data associated with that record.

The major change to this set of pages was the separation of the three pages. Initially, the three pages were meant as different views of the same data-set: similar to how google analytics works, filtering by something on one page (e.g. by a certain area on the map) would filter the other views (list and chart) as well, when the user navigated there. We had thought that this sort of filtering would be incredibly powerful and easy to use, but it turned out to be difficult to understand, especially because we did not have space to add any breadcrumb trail to indicate what filters are currently being applied.

As a result, these pages are now completely separate, with different ways of being filtered and sorted. It is a loss of utility, but at a great gain in usability.

Add Debts/Transfers

These pages are relatively typical CRUD (Create, Read, Update, Delete) pages, and as such did not have a huge amount of design going into them. The one major change was to convert the helper text into sentence-format, similar to on the records page, so the user immediately knows what he has to do.

Debts Listing

d
The debts listing page allows the user to see all the debts involving him in the system, whether created by himself or by other people. Initially, it displays the net debts per person, and clicking on each person would bring you to a full listing of the individual debts related to that person.

We found that this was somewhat confusing, as the two views of net-debts-per-person and every-debt-relating-to-a-person look incredibly similar, but are in face completely different, and people were indeed getting lost. As a result, we added a small list-view-divider at the top of the list indicating what the user was looking at (net debts, or debts relating to a person) in orer to remove the ambiguity.

Implementation

We used Flask which made it very easy to use templates. We also used jQuery Mobile to make the visuals of the page look nice and simple. We utilized Google maps API to display expenses on the map, and attempted to use Google Charts API. However, the Google charts API produced its chart using SVG which does not display properly on the Android OS, so we resorted to using another API even though it was not interactive.Our application is a mobile web app, and the individual pages are simple HTML, generated by a web server, which also stores all data. Our stack comprises, from bottom up:

1. Amazon EC2
2. Nginx
3. Flask
4. JQuery Mobile

The actual logic is about 300 lines of Python, and compact enough that it fits in two files. For external API’s, we used the Google Maps API to render all the pretty maps.
We do not have a database layer; all data is stored in memory as lists of Python objects, and disappears when the server is turned off. We currently have no security: no protection against CSRF for example, and no input validation before it goes into the data-set. These shortcomings are a conscious trade-off to focus more on the user interface.

Evaluation

We conducted our user tests at two different places: one at a fraternity, and one at the student center on campus.

We found smartphone users with a variety of backgrounds and told them that this website is to keep track of their expenditures. They were not shown any demos. The tasks given were to:

1. Create your account
2. You just ate at a restaurant and paid 18 dollars as cash. You lend Akira/Haoyi/Nahom (Person who’s talking to the tester) 8 dollars. Record your spending.
3. View my spending record as a map.
4. View my spending for the month.
5. Logout.

Results

Overall, we found that people really liked the Analytics portion of the app: being able to visualize spending geographically and temporally was very novel for many people, and they really enjoyed using it. The confusion that arose from our initial version of analytics, with the clever 3-way filter, was all gone.

The process of recording an expenditure was not bad - people generally had no problems with it - but could be improved. Possibilities for improvement would be a short NUX (New User Experience) that pops up the first time a new user visits the page, to help guide him through using the application and what he is meant to do. We are reluctant to put an explicit “How to use the App” landing page, as although it would increase initial learnability, having to repeatedly go to that page would limit efficiency in the long run

The process of adding a debt was universally confusing to people. This is something we did not expect, but we can see how it would be the case: adding a new debt requires navigating to a separate page, without any indication that it is related to the original record you were modifying. Furthermore, adding more than one debt requires taking you to yet another page: although this linked-list style of debt recording was convenient to implement, it is not a style of interface which users are generally used to. Ideally, we would fold the debts page into the record page, such that users would have immediate feedback that the debt they are adding is related to an individual record.

Individual Results

“C. B.” - Course VI - Male - Droid user - Sophomore

1. Took a little bit to find out how to log-in
   1. mostly didn’t read the login screen until few seconds later
   2. found out eventually on his own
2. Record process good
3. found map
4. found chart.
5. logged out successfully

Comments: Nice interface

“B. K.” - Course IX - Male - Droid user - Senior

1. Create account - login successful
2. Recording 18 dollars okay
3. Recording debt fail
   1. used transfer.... got confused, but went with it anyway.
4. Viewing chart and map successful
5. logged out

Comments: The debts and transfers was a bit confusing.

“Y. D.” - Course III - Female - Senior

1. login went well
2. Record process went well
3. Got confused when creating debts and then having to resubmit under records
   1. took a while to figure out the purpose of transfer
4. Viewed chart and map successfully
5. Logged out

General Comments:
-Very easy to use interface
-Really useful on a day-to-day basis
-Some features (map tracking) really enable the user to see where the user spent their money.

Suggestions:
-Add debits should be it's own tab, the process of recording a spending vs. recording a debt can sometime be confusing to the user.
-The transfer option is kind of confusing because you can’t really transfer cash to cash, some type of of lock their would make it a bit simpler for the user.

“R. A.” - Course VI - Male - Grad

1. Login went well
2. Recording process started slow but went well
3. Transferred $20 to cash from card
4. Map and chart view successfully
5. logged out

General Comments:
-Attractive interface allows users to easily learn the features
-The multiple visualizations in Analyze allow the user to see their spending in multiple ways which is something that I really like about this app.
-I like the fact that the app takes into account and keeps track when you switch from debit/credit t cash.

Suggestions:
-Add debits should be it's own tab, it’s really confusing when I have to submit twice in order to keep track of various debts.
-I don’t like the fact that the records screen is the first screen that you end up seeing. It gets really confusing as first page you get to seen on this site because it gives no background or info on what your actually supposed to do.