...
Team members: Stephanie Chang, Qian Long, Isabella Lubin
Designs
The following table shows screenshots from our app:
...
Screen 13) Since the screens for viewing your budget and for viewing someone else’s budget look more or less identical, we added a brief popup/alerts (toast messages) informing the user to whose budget is currently being viewed. This message fades away after a few seconds, but when viewing someone else’s budget, their name also shows up in a header at the top of the screen, and persists until the user returns home.
Implementation
Details
We implemented the application with a model-view-controller design that naturally comes in the Android framework. The views are the xml files that defined the widgets and layouts of each of the screens of our app. The controller is made up of listeners in the Activity class that takes in user input and modifies the database and views based on it. The model consisted of two classes: Category and Expense. We stored all the the data locally on the phone in the built-in SQLite database to store user data in tables. We had two tables in our database, one for categories and one for expenses. The controller takes user inputs and modifies the database based on the input and also puts in the data to display in the views.
...
- In the Share screen, clicking “share” doesn’t actually share your budget with the email address you entered.
- In the Chart screen, the pie chart is static.
- When viewing budgets shared with you, the data doesn’t actually change to the other person’s data.
Evaluation
User Testing Procedure
When conducting the user tests, the administrator of our group first gave a briefing of our app (see briefing section below). Then the administrator gave the users the tasks one by one. The designated observer observed the users as they performed the tasks, asking them to think out loud. The observer took notes on what they did and what they said. Afterwards, we asked them for their comments on what they liked and what confused them.
...
Solution: Change the label of “edit” to more explicitly state that it was an edit budget tab, not an edit expense tab.
Reflection
The iterative design process was an incredibly interesting and unusual experience. As much as the instructors tried to impress on us how important it was to consider our user population and design the app for their use, each round of design and testing revealed new problems that users ran into with our design. We became so familiar with what the app was designed to do and how to navigate it that we had increasing difficulty separating ourselves from the model and understanding what user needs were as we went further and further into the design process. We became very attached to a particular style of the app fairly early on, and playing around with different prototypes in the paper prototyping and design stages could have resulted in a more innovative app.
It was much easier for us to respond to the paper prototyping than to the heuristic evaluation (because of our lack of experience in working with the Android platform). In retrospect, it would have been very valuable for us to do even more extensive paper prototyping and make our paper prototype feel more high-fidelity (creating two completely different prototypes and testing both of them would have been very useful as well, as we could have combined the best features from each rather than simply improving on one). Only one of us has any experience creating Android apps, so we spent a lot of time familiarizing ourselves with the platform and trying to debug our code. Simple things like making margins look attractive took us awhile to figure out, so we should have spent more time learning about Android before we started working on our computer prototype so that our prototype could have been better (and thus so our final implementation could incorporate more important user problems that only came up during our final implementation user testing but should have come up during heuristic evaluation).
One of the more interesting things that we learned during this experience is that even when the users came from similar backgrounds, what some users found easy to understand others did not (and changes that some users thought would be useful were not always universally helpful). For example, during the second round of paper prototyping we added certain features on the expenses page that made it clear to the users we were testing how the screen worked, but during user testing the fixes we made were not sufficient to reduce the new users’ confusion.
In addition to the design changes based on user testing, we would need to fully implement all of the currently shallow areas to make the app fully usable. In the future, we would also like to make the app overall more visual. One of the users during user testing particularly asked for more yellow and green to help her identify categories she had a lot of money left in. Since the information displayed on the screens right now is very text heavy, we can also utilize charts and graphical representations like progress bars to convey remaining and total amounts for each category. We hope that more graphical representation would increase the usability (particularly learnability) of the UI and make using it a more fun and engaging experience.