Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.