MoneyManager - GR6

>> Back to MoneyManager

Team members: Stephanie Chang, Qian Long, Isabella Lubin

Designs

The following table shows screenshots from our app:

Design Decisions

App-wide) To accommodate different types of users, we tried to incorporate both visual and textual indicators in our design. For example, main tabs have icons indicating their functions, as well as text labels for added clarity. When users are able to edit an item, there is a pencil icon indicating editability as well as textual instructions (ie, “Click a row to edit expense”).

App-wide) Landscape view is disabled in MoneyManager, so users are only able to view the app in a vertical orientation. Since there are often two rows of tabs, this relegates several pages to an awkwardly small screen space. For example, scrolling tables may only only occupy less than half of the vertical space in a landscape orientation. The login page and chart page, which normally don’t require scrolling, would actually need scrolling in a landscape orientation. Since allowing the app to rotate views created several problems with layout, we decided to disable landscape view altogether and just show the app in portrait view.

Screens 2 and 13) We decided to disable tabs for features that users are not able to access. For example, adding expenses and editing budget categories are disabled when viewing someone else’s budget. Also, adding expenses and viewing budget summary and charts is disabled for a user if he or she does not have a budget created yet. This eliminates some safety concerns, and also helps with directing first-time users towards the “Create Budget” page, since that is one of the few buttons they can actually click on. Disabled tabs are blacked out, so users can’t actually see their image or label; although this sometimes creates strange tab layouts, we thought that doing so would eliminate the scenario where users constantly try to click on a tab that doesn’t do anything.

Screen 4) During paper prototyping, users were confused about whether or not their category changes were being saved. Although categories are saved into our database immediately after entry, so that in case of a crash categories will still be retained, we added a save button for user comfort and visibility. Multiple categories may be entered on the same screen, and pressing Save brings the user back to the budget summary page.

Screens 5 and 8) When users have exceeded their monthly budget (or the budget for a specific category), the “money remaining” text shows up in red, to clearly alert users to the fact that they are overspending.

Screens 6, 7, and 11) Our initial design used plus and minus icons to allow users to add and delete categories, expenses, or shared contacts. However, our heuristic evaluators were confused about what the minus icon did at times, especially without a plus icon to compare with. Our final design includes “Add another category” and “Add another expense” buttons; these are cleaner and allow users to click on the entire button, rather than an icon to the side of a text message. When initially adding expenses or categories, there is an X icon signifying a cancel feature. Deleting saved expenses or contacts is a button as well.

Screen 7) During paper prototyping, many users expressed the wish to add multiple expenses at one time, so we added this feature to our final design. After saving all expenses, users are returned to the budget summary page. Although one heuristic evaluator thought that it would be better to reset the expense form to one blank expense, we decided that users might become confused, think that we simply reset their form without saving their expenses, and try reentering all of their expenses. By redirecting the user and showing a toast message (pop up text) indicating they have saved their expenses, they will be able to see that their expenses have been saved.

Screen 13) Since the screens for viewing your budget and for viewing someone else’s budget look very similar (especially since our implementation of viewing someone else’s budget was shallow and the data shown remained the same), 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.

We used two layers of tabs for the main navigation through the app. It was implemented used nested tab widgets that came with the Android GUI toolkit. The first layer is for Home, View, and Expenses, so that they are easily accessible. The View activity contains another layer of tabs for the Summary, Chart, Edit, and Share screens.

Besides exceptions discussed in the “Shallowness” section below, we implemented a working backend for our app. All of the user input is reflected in the views; the data is stored, updated, and deleted accordingly in the backend database based on user action, so that the views are updated when changes are made.

Design Decisions

There were several design choices that we made while implementing the app that differed from our computer prototype. First of all, we decided to replace all of the “plus” icons with buttons that explicitly stated “add another category” and “add another expense” because we decided that adding text would be more clear than icons (we felt that conceptually parts of the app were not easy to understand and that text would clear up the confusion). Fortunately, there was room to do so without severely changing the layout from our previous design. In the implementation, we also added more feedback for user actions, in the form of Toast messages, which are little snippets of text that popup briefly at the bottom of the screen. Toast messages were used to give feedback on invalid user inputs such as trying to allocate more money to a category than the total allowed, entering blank category names, when an email is not formatted correctly, and when switching to and back from viewing someone else’s budget.

Another design decision we made in the implementation process was to add more guidance for the user when they first create their budget. This is done by disabling the View and Expenses tab until the user has created a budget, so the only way of creating a budget for the first time was by clicking the “Create a Budget” button in the home screen. When they click on that button, they are brought to the edit screen and a dialog automatically pops up prompting them to enter a total. Also, we added a “save budget” button in the edit budget screen to guide users on what to do after they have created a budget. These design choices do limit the user for a brief period of time, but they ensure that the user has properly created a budget (entering a total and at least one category) before using other features of the app because the other features, particularly entering an expense, rely on a properly created budget.

Implementation Issues

One implementation issue that we ran across was that the category drop down widget when entering expenses would show up as blank if no categories were entered, and it was unclear how to dismiss the widget. As said above, all users were required to enter at least one category when creating a budget.  Although this limits the users slightly, categories are a necessary part of any budget and we imagine that most users will naturally enter in more than one category without prompting. Another implementation issue that occurred was the situation when a user decides to delete a category. We weren’t sure how the expenses tied to that category would be dealt with, such as deleting all of those expenses or putting them in a default uncategorized category because it could greatly complicate the database. Since this situation wasn’t one of our main usage cases, we decided to remove this issue from this iteration by not allowing users to delete categories. This, of course, has severe limitations on the user, and is definitely an issue to be addressed in future iterations.

One of the biggest pieces of feedback we received during computer prototyping was that the layout of our app needed a great deal of improvement.  We did not use margins and spacing well in the computer prototype, and also struggled with the formatting of the popup windows.  We made a definite effort to improve layout and general aesthetics of the final implementation, so although there is a great deal of information represented in tables, that information is now better formatted and, because of margins, far more learnable.

Shallow Parts

• 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.

User Population

Our target user population is split into two main groups: students and parents. We were able to find three users who were part of the student population for this round of user testing, but not users from the 2nd user population.

Briefing Read to Users

This is a user testing trial for an android app created for the User Interface Design Class 6.813.  The app that we created, MoneyManager, allows its users to create a monthly budget, enter expenses, and make sure their spending is on track for the month.  Users can also share their budget with their friends and family, so they can compare their budget with others’ and show their parents that they are spending their money wisely.

We’ll now ask you to complete a number of tasks one at a time using the app.  We will be observing how you interact with the app (and what you find clear and what you find confusing).  Please think out loud as you work - this will help us improve our design!

Tasks Given to Users:

Task 1: Register and create a budget with 2 different categories.
Task 2: Enter several expenses.
Task 3: Oh no! You make an error on the last expense. Fix it!
Task 4: Share your budget with your parents.
Task 5: Your brother Luke shares his budget with you. View a pie chart of his spending.

List of Usability Problems from User Testing

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.