Design
On the first page of our site, we wanted to emphasize that the user has two options: to sign up for an account, or to sign in with an existing username and password. Because of this, we used buttons large enough to pass the squint test, and made them stand out by coloring them green. This first page of the site also has a blurb about Housebill's functionality, which we intended to attract new users, or to remind existing ones of our purpose.
We wanted to make signing up for an account a simple, no-frills task. This meant that the user would have to supply only a minimal amount of information. The goal here is to have the user exploring the site as soon as possible, which minimizes the likelihood that a user gets frustrated with the signup and decides to devote their time elsewhere.
Once the user is logged into the site, they are offered several different pieces of information, each of which take up their own corner of the screen real estate. In the top left, there is the total amount that the user owes, and the number of overdue bills appears in a large, red font. This will quickly attract the user's attention to any overdue bills, which we expect them to correct promptly. On the right side of the screen, the user sees their bills for the current month. This calendar serves as an overview. There is a larger version of this calendar available on a different tab, if a user wants to explore further than the bills for the current month. Next, there are two very prominent buttons towards the bottom of the screen, allowing the user to add a bill or to pay a bill. We expect these to be very common tasks on our site, and as such made these actions stand out on the page. The buttons are large, which comes from the application of Fitt's Law.
Overall, we wanted to emphasize what we thought were the most important pieces of information to the user, similar to Google's homepage.
We had intended to include a profile page with personal account information about the user, but we cut this after paper prototyping because no one seemed to find it useful. However, we did keep the display indicating how much money the user owes, putting it on the homepage instead.
One of the main tasks that a user will perform on the site is adding new bills. Because of this, we try to make this action straightforward, helping the user along as much as possible. For instance, when a user inputs the total amount for a bill, that amount is automatically subdivided up amongst all of the selected users. Similarly, a calendar pops up when the user wants to select the due date for the bill. This makes the selection process a simple point-and-click, instead of using drop-down menus or another selection scheme.
We also changed some of our features due to user confusion during paper prototyping. For example, the interface to allow users to set the portion of each bill paid by each member of the household was originally a slider, but users had trouble working with it, so we switched to a series of text boxes. The calendar was added to the homepage to draw users' attention to it, since otherwise they often did not notice that the calendar was there.
Final: 
Before: 
A user can see all of their bills on a single page. We took an idea from the way that groupon lets users organize their groupons. In particular, users can see bills that have already been paid, and those that are yet to be paid. This gives us a high degree of error correction, in case a user accidentally marks a bill as paid. This means that bills are never actually deleted, and gives the user a full record of their payments.
Any bill that has not been paid can be edited by the user. This page looks very similar to the page for adding a bill, except for the fact the the existing bill's information is pre-loaded into the text box fields. In this way, the user can exactly see the bill state at any time, and can change any aspect of the bill.
Because all of our users will have slightly different preferences, we offer them slightly different ways to view their bills. One of our views in the timeline. This lets the user scroll a slider to a desired point in time, for example three weeks from the current day. The interface will then show the user all of the bills that are due within three weeks.
During the paper prototype user testing, our users had a tough time using the timeline view. This was originally supposed to be the only way that users could sort and arrange their bills. However, after the difficulties, we decided to include a more traditional calendar view, in addition to the timeline. Also, we chose to display more limited information on each bill to provide a cleaner interface and eventually allow sorting.
Now: 
Before: 
A different approach is our dedicated calendar view. As opposed to the small calendar on the user page (shown immediately after the user logs in) this calendar gives the user to search for any month in any year, not just the current month.
Bills are displayed as due on a certain day. We took this design approach, instead of listing out all of the bills due on a certain calendar day, so that the user would not be overwhelmed with information on a single screen. When the user clicks on a calendar day that says it has bills due, the user is brought to a page that displays all of the bills due on the selected day. It is on this screen that we give the user all of the information about the bills for the day.
Design Changes
We evolved our final design significantly from our original idea. A lot of our original idea, as presented by GR1, centered around the household, and we envisioned presenting bills to the user that pertained to the household they were part of. This meant that a user would see the bills for a the entire household, including ones that they were not personally responsible for. The rationale for this was that a user could be part of more than one household. This could be, for instance, a summer house and a college dorm. Our user testing, however, showed us that very few users actually have more than one household. Because of this discovery, we changed our application to center around the bills for a single user, instead of those for a household. This changed some of our tasks. For instance, we do not have a household graph of expenses. Instead, we present all of the user's bills to them.
Implementation
For the frontend, Housebill uses HTML5 with CSS, as well as jQuery. The database used is MySQL, and the backend functionality is written in Ruby on Rails.
Currently, the site is hosted on scripts.mit.edu, which uses Apache to serve the HTML pages generated by the backend. We chose to use Scripts because it handles the set up and initialization of the the web framework and the database structure.
We originally chose to use Rails as a backend because one member in our group was very efficient in it and another had previously worked with it. We wanted to choose a backend that we were comfortable with so that the majority of our efforts could be focused on the frontend, which is the focus of 6.813.
A critical implementation error we encountered was that Scripts only supports Rails 2, which neither member in our group had worked with before. The changes in the API in Rails from Rails 2 to Rails 3 caused some development problems that we did not expect as we realized that Rails did not necessarily have the functionality that we had thought. Some of the resulted problems included Rails 2's lack of support for accessing multiple tables and a different routing schema. This also prevented us from using some of the gems (add on's or external classes) that we were acquainted with from being used, causing us to write this functionality and using more time.
Another resulting problem of Scripts was that without sudo access to the server we had a difficulties trying to create a development set of code from a production set of code. Because we were never able to solve this problem, we had to wait while our GR4 was being graded to begin coding GR5, which resulted in us losing a valuable week of development time.
We went with a MySQL database structure because using a relational database was perfect for this kind of project, and MySQL was easy to configure with the Ruby on Rails backend, especially on Scripts, which handles the connection between Rails and MySQL.
The database holds information about the Users, Households, and Bills.
The Users table holds all of the information pertaining to individual users, and their accounts. This table contains the following columns: username, password, household, and id. The idea here is that each user has a unique account, and users are grouped together into households. The Households table only contains an id column and a column titled 'household' that is a string of the household's name. Each bill in the Bills table has an id, name, due_date, creator_id, household, total_amount, category, and paid_all. The creator_id field holds the id of the user that created the bill. The last column, paid_all, is used to tell if all of the users on a particular bill have paid their share. There is also a table called User_Bills that connects Bills to Users. This last table is necessary because the relationship between Users and Bills is many-to-many.
We decided to use HTML5 with CSS for the frontend because it made our implementation easier to construct. Ruby on Rails allows for the creation of dynamic HTML pages, which means that we can put content from our database directly into our HTML, depending on the users' requests. We used CSS to make the site visually appealing to the user. Using CSS also allowed us to have a different color scheme for alerts that we presented to the user for, for instance, incorrect data entry. The use of HTML5 and CSS3 proved to be a good choice because it allowed us to rely upon the two's enhanced abilities to do much of our graphic work, like gradients, instead of having to spend the time to create the graphics and then implement them in our site.
We used jQuery wherever we wanted to change the contents of a page without having the user reload the page in their browser. For instance when a user inputs the total amount for a bill, we automatically split the bill up amongst the members of the household and show the user these amounts as they are typing.
Evaluation
Users were given a briefing and then given each task individually as tasks are completed.
Users
Our users were found in our dorms, living groups, and acquaintances on campus. While all users may not currently be living in a group setting where an application like HouseBill would be needed, users had all at least previously lived in a group setting such as during a summer internship. While all users being in current group settings would have been a better representation, these users still understood the problem and situation.
Briefing
HouseBill is a bill organization system for people living in a group setting. It lets everyone within a household see how much they owe, and when it is due. This makes paying bills more transparent, because you can see exactly where your money is going, and you can plan accordingly. It also allows the everyone to help handle the "treasury" duties of the household so the entire responsibility does not fall upon one person.
Scenario Tasks
Part 1
- Create a user account with whatever username and password you want, join the household 'Test House'
- Add a bill: Test Bill, Due: 6/1/2011, Split cost evenly amongst all roommates, Total amount for bill is $100.00
- Log out of the interface
Part 2
- Log into the interface as Username: Demo and Password: demo
- Pay all bills due within two weeks from today
- Edit a bill: Change the due date of the Test Bill to 6/10
Usability Problems
Issues found during user testing included:
- User while editing a bill removed himself from the bill accidentally. Since the bill no longer affected him, he could not access the bill again to re-add himself to the bill
Severity: Major
Solution: Show all bills connected to the household under household so that user has access to bills even if they do not apply to him at the current moment.
- User entered password incorrectly when signing up and then could not log into account.
Severity: Major
Solution: Have a confirm password entry textbox where the user must type in a matching password.
- User accidentally paid a bill and was confused when the bill disappeared.
Severity: Minor
Solution: Have a pop-up that asks if the user is sure of their action. However, the bills are still available to the user under the "Paid Bills" section and they can correct their mistake there.
- User could not understand timeline functionality.
Severity: Major
Solution: Have bills ordered by date so that it is clearer to see that bills are being added by date when the slider moves.
- User thought that slider on timeline was too small, and had trouble clicking on it to drag it
Severity: cosmetic
Solution: make the slider larger and more visible to the user
- User was unable to find all bills due within two weeks
Severity: Minor
Solution: Order bills by date on the view bills page or include the timeline as another part of the view bills page and consolidate the two features
- User tried to click on the number in the Overdue Bills section on the main page to access their overdue bill
Severity: Minor
Solution: Allow clicking on the overdue bills section to take the user to all of the bill that are overdue
Reflection
Our group learned many things about development, design, and prototyping throughout this course. We learned about the iterative design process of making an application. One of the main things that we had to deal with was that we are not the users. We realized that you don't know how users will interact with your product until you actually allow them to access it. This comes in the form of prototyping, which provides challenges we were not used to as a developer. It is difficult to design a backend for an ever changing front end implementation.
Another thing we learned was that in design there is not always a right answer. In class, when we viewed Hall of Shame examples, there were often blatant aspects that we as a class could agree made the interface more difficult to use. However, most applications don't have clearly defined lines like this. We frequently encountered user issues where one user might consider an aspect a convenient feature while another user considers it a terrible design flaw. We encountered these decisions even amongst our own team members, such as when we were deciding how to do self populating fields in our add/edit bill interface.
As prototyping was new to all members of our team, we made some 'rookie' mistakes during paper prototyping that resulted in a lost of valuable feedback. Instead of focusing on the interface's usability, our users were distracted with issues in our tasks' wording and navigation blunders. The latter problem occurred as a result of not being able to see the top of the prototype easily from the tester's seat. This provided us only limited feedback as we began computer prototyping. With the technical difficulties we later encountered, getting more initial feedback would have allowed us to avoid some of the issues we encountered and spend more time developing more useful features.
Our inexperience also led to another blunder of being overly ambitious with our prototypes. While our prototypes showed the opportunity of what we could do with the idea at hand, the prototypes that we made, especially the paper prototype, were not realistic with our abilities and the time given. During our paper prototyping, we created many superflous features that were not necessarily needed for critical operation. This then lead to an expectation of having those features on the final product of our site. Instead of focusing on developing the critical aspects of the site while computer prototyping, we put more effort into trying to prototype all of the features. This resulted in weaker features all around and many of the features that we tried to prototype were not ready for GR4 and/or GR5, which made it seem like wasted effort. If we could redo the project, we would have created more realistic prototypes with basic features and then enhanced the site from basic usability.
This would mean implementing the bare bones functionality, and having users test that. From our experience, having a focus group test the interface with the bare functionality gives us a good idea of what the users want as an interface. This would cut down on the number of revisions that we have to make during our redesign phases.
As we mentioned in our Implementation section, we had numerous issues resulting from our decision to use Scripts. When we realized that it was going to limit us and undermine our development progress, we should have used another host service that would give us the freedom we needed to develop more easily. However, this choice would have been a more expensive option.
Overall, our application grew and evolved throughout this term. There were many mistakes that we can say we made while developing, such as choosing the wrong suggestions to take and weighting having more features over developing the current ones to the fullest. That being said, we think developing Housebill gave us insight in what it is like in a startup or business to develop a real product and see the choices that have to be made and made us all wiser individuals.