Design

Implementation

We decided to implement our website using HTML/CSS/JavaScript for the frontend, the Flask web development framework for the backend, and SQLite for the database. Flask is written in Python, and while it is similar in principle to Django, it is much more lightweight, and therefore is easier to set up and use. It has a templating system for web pages that reduces the amount of code duplication. 

In our model (the database), we used three tables to represent the data: budget, projects, and student requests. They contained the following columns:

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. 

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.

The users were briefed by the testing explaining that we designed our project for a class and that they were our target users.  The scenario that we used in previous user testing was shortened, because the users were familiar with the roles of a house manager.  We wanted are target users to be able to understand the purpose of the application presented to them without a lot of explanation of the scenario.  The scenario was that the user was reassigned to manage a new building and the previous house manager used HManager and were then asked to perform tasks related to the scenario.  The tasks were that as being new to the dorm  they 1) wanted to be able to see how much money was left in their budget (this required scanning the page and clicking on the "View Budget" page), 2) view the overall status of the building (this required visiting the "Building Status" page), 3) Add a new project and edit an existing project (required visiting the "Projects" page), and 4) Add a student project to the list of project (required visiting the "View Student Requests" page).

Our final design has some serious usability issues.  Starting with the homepage the boxes on the right side of the screen provide feedback that they are clickable by underlining.  This is a consistency problem because even though are technically links to another page the are meant to be buttons.  This problem could be fixed by having the "buttons" change color when the mouse hovers over them, similar to the current navigation buttons at the top of every screen.

Reflection