You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

MoneyManager - GR6

>> Back to MoneyManager

Team members: Stephanie Chang, Qian Long, Isabella Lubin

Designs

The following table shows screenshots from our app:

 
1) The login screen

 
2) The home screen, before a budget has been created

   
3) Editing a budget

   
4) Adding categories and amounts to the budget

 
5) The home screen after a budget has been created and
expenses have been added. There are quick links to common
features. All tabs are now activated as well.

   
6) The budget editing page, where users can see how much money
has been allocated to each category, and how much is unallocated.

   
7) Adding an expense. You may also add multiple expenses
at once, or cancel one or all of your unsaved entries.

   
8) A summary page of budget categories and money spent in each.

   
9) Editing a previously saved expense

   
10) A pie chart depicting breakdowns of budget money by category.

   
11) The Share Budget page, where users can see who
else can view their budgets and expenses.

   
12) Giving viewing permissions to another person.

 
13) Viewing someone else's budget. Note that editing budget
and adding expenses have been disabled.

 

 

 

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

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.

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.

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