...
Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
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. For instance, joining a household is optional on the signup page, so a user does not have to worry about this feature and can opt to do it at a later time. 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.
INSERT PIC OF FIRST PAGE SEEN AFTER SIGN-IN
Implementation
Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
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 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 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.
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.
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
Describe how you found your users and how representative they are of your target user population (but don't identify your users by name).
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
...
...
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
List the usability problems you found, and discuss how you might solve them.
...
Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.
Our group learned many things about development, design, and prototyping throughout this course and the iterative design process of making our application. One of the main things was that we aren't the users. We realized that you don't know how users will interact with your product until you allow them to access it in some level 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, most times there were 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 as a result of not being able to see the top of the prototype easily from their seat. This provided us only limited feedback as we began computer prototyping.