...

These database tables were used to populate the tables on the site. When a user made created a new project, a new entry was created in the database via a SQL query. Likewise, if a user edited an already existent project, that project's entry in the database was updated via SQL. The 'budget' page used the information in the database to generate the graphic displayed on the left side of the page, as well as its tooltips. Our intention was to completely integrate the backend of each view with every other view. For example, creating, deleting or modifying a project should update its corresponding entry in the budgets table. We were not able to implement that feature in time, so we used dummy information to generate the budget view. 

Because our site is so heavily dependent on the backend, bugs in the implementation of the backend severely hampered its usability. Until the backend was fixed, there was no way for users to generate or interact with data. Once it was fixed though, it worked as intended.

Evaluation

Our user population for this project was a building manager, more specifically a house manager.  Finding our users was simple and straight forward because there are twelve undergraduate dorms and 7 graduate residences each with their own housemaster.  We attempted to set up appointments with the house managers and was only able to secure testing opportunities with two, one managing an undergraduate dorm and one managing a graduate residence.  Our third user was a housemaster of an undergraduate dorm.  Even though the housemaster is not the house manager, they are familiar with the duties of a house manager and sometimes share similar responsibilities, such as managing a budget, projects, and receiving student ideas and concerns.

...