...
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 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.
...
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.
...
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.
...
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. With the technical difficulties we later encountered, getting more initial feedback would have allowed us to avoid some of the issues and spend more time developing more useful features.
As we mentioned in our Implementation section, we had numerous issues resulting from our decision to use Scripts. Another regret of our group was that we did not choose another development platform