...
To implement our interface, we used web programming technologies such as HTML, CSS, Javascript, JQuery, Boostrap, for our frontend, as well as Parse to store our database of constructed objects. These were used since we felt that the web was necessary for management staff to be able to use the application on their own devices and still communicate with each other, and these first five were standard tools in web programming that made our frontend implementation straightforward; Parse we used for our backend because of familiarity with it, and satisfaction with its robustness for this project. Our Parse data structures which we made for utility included the Room class, the Floor class, the Task class, and the Resident class; objects with natural hierarchy were doubly-linked for ease of manipulation (e.g. reference from a Room object to a Resident object for a resident staying in the room, and backwards).
Main Page
| Panel |
|---|
DesignThe main page is the default landing page for users. It's main use is to keep track of the current active tasks. |
...
| Panel |
|---|
Design:The form contains standard information that the dorm manager need to fill out when a resident moves in or moves out of the dorm. There are two main tasks including Move In and Move Out. The information on the page changes dynamically depending on the type of the task. This page will be visited very frequently by the user, so it's designed to be efficient for filling out information. The Useful information panel will contains auto-fill information that help the user speed up the filling out task. One of the important decision for this page is to fit the two panels into two scroll views without overflow the information to the whole page. The user can choose to scroll each panel separately without moving the whole window. It's because we want to user to make good use of the auto-fill function, so they can scroll the left panel up and down while keeping the right panel statically in the view port. Figure 1 demonstrates the interface of the Start New Task page.
One of the importance decision that effect effects the design is the affordances of this right panel. Many users mentioned that there wasn't enough affordances to show the auto-fill function of the information on the right. Therefore, we have decided to put a place holder on the input where the auto-fill information supposed to fill in when the user hovers over those information. Figure 2 shows the result of the auto-fill functionality. We chose this as our implementation for its simplicity over other methods such as having a tutorial pop-up or changing color or boxing around the auto-fill result.
Another important feature is when the user submits the form, if there are some missing fields, the user will receive a pop up noticing them about these fields. The user can have the option to go back and fill out those missing fields or save the form any way. Figure 3 demonstrates this functionality. This confirmation dialog will help prevent user from making mistake when submitting form. We choose this decision instead of preventing the user from submitting the form at all and have the missing fields highlighted at the beginning of the form because the user might want to leave those fields blank to fill in later. In addition, different dorms might have different requirement for required field, so providing them with confirmation dialog will help them decide on their own which field they want to keep.
In order to follow the CRUD model presented in class, we decided to let the user edit the task. The page will be pre-filled with the most recent updated information. Figure 4a and 4b demonstrates the edit task functionality of the website. ImplementationThis page follows follow the model view control (MVC) model. The database for MIT directory search is kept in a separate Javascript javascript file since this field is static, and the information of the resident is stored on the Parse database since it will be dynamically changed over time. We utilize the convenience of Jquery UI in creating the dialogs dialog and drop-down menu. We also make use of Twitter Bootstrap twitter bootstrap for organizing the layout. All of the controllers controller for listening to action are added separately in order to follow the MVC model and to keep the code modular. In addition, since there are different information is presented for each type of task (Move In versus Move Out), we decided to dynamically repaint the page instead of reload the page from scratch. This will help the user preserve some of the information that is are shared between these two tasks. The information about vacant rooms is room are update dynamically through Parseparse. For example, if a person moves into a room, we update the current list of resident of that room and remove it from the list of the available room. MIT directory is design to match with the current MIT directory on web.mit.edu/people to help user with recognition because most users are familiar with this interface already. After the information is generated, an the action listener is attached will be attach to the result to auto-fill the form. The list of suggested tasks are static data collected from the suggestion of the users. We also decided to add the default task button to speed up the filling process. The back end of this page is supported by Parse. There are three objects that currently present on the server: Resident, Task, and Room (See Figure 5). Each of this object will have a reference to the other objects so that whenever one object changes, it will also change the other. After the user submitting the task to the server, a task object will be created with each attribute corresponding to a field in the form. Then, the room and the resident will also be updated on the server to reflect the task i.e if a resident Move In to a room, the room becomes occupied and remove from the available room and the resident gets added to the system. For the updated task, we also have to make sure that we do not created duplicate object on the server since Parse doesn't automatically check for that. Since there are three main pages sharing the same source of information, we need to make sure that changes on one page will be reflected on other pages too. For example, if a person moves out, the main page will show that as a pending task and the floor plan also have to indicate that the room is now vacant. All of the information uploading to and downloading from the server are text-based, so the retrieving time is almost instantaneous which enables the user to see the current update from the server at no time. In addition, to respect the anonymity of 6.813, we also use fake data for our database which introduce some inconsistency among information. However, this doesn't present any usability problem for the user. |
...
Evaluation
Test User Selection
We selected our test users by the same criterion we used to select people for testing our paper prototype, since the user classes for our problem had not changed since then. Essentially, we had two major user classes, dorm managers and desk workers, and so we found users from those to test our prototype. We had just one of the users from previously test our interface this time to help see whether the fixes we had for problems before were found to be helpful by the users, and to make sure that we didn't have regression; this user was a desk worker, and we call him User 1 from here. For the second user, we asked a house manager we had not interacted before, from another dorm, to evaluate our interface; we felt that since they were new to the interface, they'd be able to evaluate our interface from the perspective of a total beginner. For the final user we tested for this iteration, we asked another desk worker from the dorm we live in who had not used the interface before; this time again for the sake of having a beginner test our interface, and also be from the desk worker class rather than the house manager class.
Test Briefing
Most of our users were the same ones we used for testing our paper prototype and so were already familiar with the scenario and the purpose of our interface. Nevertheless, we reminded them of the following scenario:
“You are a desk worker or dorm manager and you plan to use this interface to keep track of the progress of various tasks going on in the dorm. Right now, you’re focusing on helping residents move in and out, and keeping track of general housing information.”
Test Tasks
The following tasks were given to the user on paper. Additional prompting would given when it was observed that the user was having particular trouble completing a task.
The users that we selects are two desk workers and one dorm manager. They are in the mid 30 or 40 and familiar with technology and computer. In addition, they are doing these tasks quite frequently using very different platform including yellow card, spreadsheet, and web interface. We expect them to bring different views to our web interface based on their diverse background.
Test Briefing
Most of our users were the same ones we used for testing our paper prototype and so were already familiar with the scenario and the purpose of our interface. Nevertheless, we reminded them of the following scenario:
“You are a desk worker or dorm manager and you plan to use this interface to keep track of the progress of various tasks going on in the dorm. Right now, you’re focusing on helping residents move in and out, and keeping track of general housing information.”
Test Tasks
The following tasks were given to the user on paper. Additional prompting would given when it was observed that the user was having particular trouble completing a task.
| Panel |
|---|
Task 1: Document Completion of Subtask
Task 2: Determine Information about a Floor
Task 3: Start Moving a Student In
|
| Panel |
Task 1: Document Completion of Subtask
Task 2: Determine Information about a Floor
Task 3: Start Moving a Student In
Task 4: Start Moving a Student Out
Task 5: Identify Resident
|
...
- The user finished this task very quickly without any problem.
Task 2
- The user at first looks for the floor information on the main page, and only after suggestion from the facilitator navigates to the floor plan to look up the relevant information, after which he quickly solves the problem. Like the previous users, he didn't seem to realize a page other than the main page existed until it was pointed out; he noted that this was possibly due to the coloring on the navigation bar, which made it difficult to see the tabs that were unselected. Again, a learnability issue.
Task 3
- The user didn't notice the "useful information" section on the right-hand side, and so first filled out partial information. This represents the same problem as previously faced with users.
- The user moved to the floor plan page when he felt that he couldn't immediately fill in the information on the form; he then returned to the form after finding the information, but at that point his information had been cleared. It seemed that the user thought that his information would be saved on the form when he came back to it; this seemed to be a safety issue.
Task 4
- The user has no problem with finishing this task, and no critical incidents are noted.
Task 5
- The user had trouble at first finding the information, looking on the main page, and trying to use the "task management box"; when prompted by the facilitator, he found the information quickly on the Floor Plan. Again, this seemed to reflect the same issue as with previous users thinking the task management box is an "omnibox".
Iteration Considerations
- Since people seemed to have a lot of learnability issues rather than any efficiency issues, one idea is that we have a tutorial of some sort, or a guiding version of the interface for first time users so that they can become familiar with the system; more specifically, most people seemed to have issues with not knowing what tools existed for them, and so this seems like a good idea to try in the future.
- Another consideration we have is possibly to take the main page and make it omniscient; that is, right now, the main page is only for managing current tasks in the system, but multiple users seemed to feel that they could use the task management box for all sorts of queries, such as looking up arbitrary room or resident information. We are considering adding additional fields to the data structures and accordingly changing the objects in the data tables to support this functionality, or possibly adding different "modes" to the search box so that the functionality exists and is well organized, though at the slight cost of efficiency.
- We found a major safety issue with the 3rd user when he navigated off the task creation page and lost all the information he had filled in the form; we think that creating a modal dialog for this case to notify the user of what they're doing should be an appropriate fix, as we have with the form submit button.
- For the cases of task submission and task updates not being visible, we think that just doing something like highlighting the border of the inserted task or update to the main page should be sufficient for indicating the changes; this seemed to work for other parts of our interface.
- For the problems with the new task button not being visible, we think that changing the color to something more outstanding, or making the button bigger so that it's more visible may be a good idea.
- For the issue of the "useful information" section of the interface not being used, though the introductory video/interface first proposed should help, we also think that possibly adding something like a large, light arrow in the center of the page between the two columns may help to indicate the relationship between them.
- .
Task 2
- The user at first looks for the floor information on the main page, and only after suggestion from the facilitator navigates to the floor plan to look up the relevant information, after which he quickly solves the problem. Like the previous users, he didn't seem to realize a page other than the main page existed until it was pointed out; he noted that this was possibly due to the coloring on the navigation bar, which made it difficult to see the tabs that were unselected. Again, a learnability issue.
Task 3
- The user didn't notice the "useful information" section on the right-hand side, and so first filled out partial information. This represents the same problem as previously faced with users.
- The user moved to the floor plan page when he felt that he couldn't immediately fill in the information on the form; he then returned to the form after finding the information, but at that point his information had been cleared. It seemed that the user thought that his information would be saved on the form when he came back to it; this seemed to be a safety issue.
Task 4
- The user has no problem with finishing this task, and no critical incidents are noted.
Task 5
- The user had trouble at first finding the information, looking on the main page, and trying to use the "task management box"; when prompted by the facilitator, he found the information quickly on the Floor Plan. Again, this seemed to reflect the same issue as with previous users thinking the task management box is an "omnibox".
Iteration Considerations
Reflections
We all got a great deal of experience with web programming through this project. We learned how to use html, css, and jquery effectively and how to debug the problems we had. One consistent challenge that we ran into was clashes of external libraries. We learned to be very careful of external libraries especially when trying to mix them together. In addition, it would have been nice to receive some guidance on how to organize our files. For all of us, almost the entire code for a page was on one file or split into the html file and .js file. It would have been nice to know how UI programmers break up their coding process. Also, Sumit learned that linear algebra comes in handy when working with movable, zoomable maps.
...