Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

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

...

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

...

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.

Reflection

Akira

I had a lot of fun making this website. I had never used jQuery Mobile, which handles things very nicely for the most part. It was also interesting to see the different problems we found when opening our site on the computer and a smartphone: some codes that worked on the computer crashed on the smartphone, or the size of the smartphone screen was much smaller than we had imagined. When having our prototype tested, I thought it was really interesting to see how much people who use the application for the first time get confused with what the makers thought was easy to understand. Ideally, I would want to continue working on this site and make the changes that reflect on the comments we received from our testers.

Nahom

I really enjoyed working on this website, I especially enjoyed working on the front end aspect of the site. The biggest difference was probably working on a mobile site rather than an actual one mainly because you have to consider and prioritize different things such as screen size which play critical roles when you transition from desktops to mobile devices. Overall, I think one of the things I would of tried to understand/work on more would be figuring out what features we can add and implement into the site using Flask. This was my first experience with the Flask framework, so I think given more time it would be one of the things that I would of tried to understand more and add to our application.

Haoyi

We chose to do a mobile web app mainly because it was something none of us had done before, so it was new and novel: normal websites are well-studied, and so are native mobile apps. I think that it was a very interesting experience, given that I was in parallel developing a native Android application for 21w.789. The parallels between the two techniques (the apps look more or less the same) as well as the contrasts between them (native Android is much more painful!).
It was also the first time I had worked in a group setting with multiple people doing somewhat homogeneous tasks: previous group projects always had a very clear separation of labour: one person would focus on one section of the project, and thus there was not a lot of task assigning or delegation to do, as everyone already had their work cut out for them. In this case, we were much more interchangeable, with any of us working on any part of the app.