Design

The following is the 'Home' page. It is intended to provide a visually appealing introduction to the site, and offers links to every other useful page in the site. Based on heuristic feedback, we increased the clickable area of the buttons to include the entire button and not just the text.  Also from our heuristic testing, we removed the slideshow and instead kept a still video.  There was a major issue, in which the alignment of the menu bar changed drastically depending on what page was being displayed. We fixed that issue after receiving feedback and having it pointed out.

The "Budgets" page provides a representation of the user's yearly budget. The column on the left shows the amount of money available, and the amount of money allocated to projects within a particular month. The column on the right shows the months of the year. The table on the far right shows the recent projects created or updated, and is automatically edited whenever a user makes a change elsewhere on the site.  Due to time constraints and the nature of this page, we decided to not have it connect to the database for user testing.  The task that this page involved was only viewing it and determining if the user understood what the page was trying to convey.  We added the data so that it matched the information in the table to the information in the budget graphic, this allowed to still test the user interface without having to connect the page to the backend database.

The "Building Status" page presents an overall view of projects taking place in the building. We completely redid the building status page, since we were not able to implement the original version described in our paper prototype. We chose to use a Gantt chart to display a visual representation of any number of projects and their estimated completion time.  This was further motivated by the heuristic testing, when it was pointed out that the original design was a little confusing. Due to time constraints and the nature of this page, we decided to not have it connect to the database for user testing.  The task that this page involved was only viewing it and determining if the user understood what the page was trying to convey.  

The "Projects" page presents an overview of all of the projects that have been created for the building. New projects can be created, and existing projects can be modified by clicking a row on the table. For the Projects page, we aligned the "Add New Project" form fields based on feedback received from the heuristic evaluations. We also made the table columns unresizable by the user. We made it more obvious that the table rows were clickable by having the mouse cursor change to a pointer when it hovered over the rows. Users were able to find the "Update Projects" form much more easily.  The "Update Projects" page would pop up in front of the main Projects page both of these features are connected to the main database.

The 'Student Requests' page provides a view of incoming requests. The user can then choose to create a project out of any request, and clicking on the "Add Project" button takes them to an "Add New Project" form.  The "Add New Project" form is automatically filled with the relevant information provided by the student.  The request date becomes the start date, the request description becomes the description of the project and the floor is automatically transferred.  This page is also connected to the main database.

We provided an "About" page to enable users to identify the site creators (and contact them if necessary). Also it was intended to provide a bit of information about the website. This was added based on feedback from the heuristic evaluation. 

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. 

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, except in the places where it wasn't connected to the frontend because of time constraints.

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 usability issues:  

Starting with the homepage the boxes on the right side of the screen provide feedback that they are clickable by underlining (cosmetic).  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.  

The usability reported by two users was that when trying to add or edit a project, it was not clear what fields are required (minor).  We can easily add a popup when a field is not filled in, as well as using asterisks to define which fields are required, with a footnote denoting whether or not the value was required.  

From one of the house managers unknown should be a possible selection for Floor, Completion Date and Cost, because those fields aren't always know when a project is being started (minor).  This would be a simple fix, but adding an indicator to the fields that are required or having an error message appear saying what fields are missing.

There is also and inconsistency between the alignment and layout of the "Add New Project" form and the "Update Project" form.  A simple solution would be to keep the layout consistent to avoid errors and confusing the user. 

The "email residents" checkbox was unclear to one of the test subjects as to who was getting emailed, whether if it was the email of the person/student who created the event or someone else (minor issue).  This could be fixed by changing the text to "Email all dormitory residents" or adding a tooltip.  

Another usability issue is that when a project from students request is added to the main projects, the project was not removed from the "Student Request" page which caused a lot of confusion with user testing (major).  A simple fix would be to make sure that the project that was added is removed from the "Student Request" page.

A final main usability issue is error messages, this pertains especially to when data was being entered (catastrophic).  If something was entered incorrectly then they were taken to page that displayed "Bad Request" although this is better than not displaying anything and putting invalid data in our database, we could create more descriptive error messages to help the user.

Reflection

We learned that UI design can be a long and iterative process. We were constantly challenged to change our assumptions, and learned that often, the smallest of details matter.  Most importantly, we learned that we needed to be flexible with our designs and be prepared to change them even if they passed user testing if it would be impossible to implement.

If we were to do this again, we would probably start earlier, and find outside help for parts that were a little more difficult, such as connecting the database.  A lot of the trickier parts of our implementation were bottlenecked by the database, so we would try to work around that.  We ended up implementing most of the features we prototyped, with the one change in the status that was different from what we prototyped.  As far as which prototype techniques to use, I think that both the paper prototype and the heuristic evaluation was valuable, although I believe the paper prototype was a little more useful to see what people actually wanted.  The heuristic evaluation mainly told us small things that we needed to fix, rather than what is wanted by the users.