Page History

Design    

The main page is the default landing page for users. It's main use is to keep track of the current active tasks.

Figure 1: An overall view of the main page.

Users are able to receive what is essentially a news feed of recent changes by looking at the "Recent Activity" column on the left. On the right, users may look up specific tasks and edit them as necessary.

Image Modified
Figure 2: When a task row is clicked, additional information about the task is displayed.

Figure 3: A close up of the notifications section.

Image Modified
Figure 4: After a task is created or edited on the Task Creation Page, that task will be highlight with a border for 5 seconds upon returning to the main page.

Image Modified
Figure 5: Showing off the possible filters that can be used.

Implementation

Design:

The form contains standard information that the dorm manager need needs 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 Information" panel will contains auto-fill information that help the user speed up the filling out taskcontains tabs which pop out buttons and search tools that help to autofill the information on the left, helping the user complete task creation quickly. One of the important decision decisions for this page is was to fit the two panels into two scroll views without overflow the information to the whole page. The separate scrolls views, so that the user can choose to scroll each panel separately without moving the whole window. It's This was necessary 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.; being able to scroll the two panes separately allows the autofilling to be done independently of the reading position of the form, something which we and users found to be simple.

 
Image Modified
Figure 1: The start new task page

One of the importance decision that effect the design is the affordances of this Another important decision was regarding the affordances associated with the right panel. Many users mentioned that there wasnweren'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 temporarily auto-fill the input boxes with grayed-out text with the auto-fill information supposed to fill in when the user hovers hovered over those that information. Figure 2 shows the result an example 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.

Image Modified
Figure 2: Auto-fill information when hover over item.

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.

Image Modified
Figure 3: Missing fields notification when submitting the form

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.

Image Modified ---------------> Image Modified

Figure 4: Edit Task functionality

Implementation

In addition, since there are different information 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 are shared between these two tasks.

The information about vacant room are update dynamically through parse. 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, the action listener 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 reflect on other pages too. For example, if a person moves move 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 enable 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.

Image Modified
Figure 5: The current state of the parse server.

Design

The Floor Plan page was designed to address an issue that dorm management staff had noted about having difficulty determining positioning information about rooms on both macro- and micro-scales. As shown here, the page includes the navigation bar present throughout our entire interface for consistency, safety, and user control; the rest of the page is used for addressing the problem just mentioned. In the center we placed a large image of the floor for visibility, and because it is the most important part of this section of our interface - on the right side of that we horizontally aligned tables of useful on-hand information; on the left we placed extra UI elements (also horizontally aligned) for helping to navigate to other parts of the building besides the current floor; and above we placed a search bar for helping to navigate the floor plan.

The choices for alignment were mainly for the sake of aesthetics, since separation of the UI elements already seemed clear to us and users; however, positioning was important. We placed the search bar on top so that it'd be very visible, static on-hand information on the right since it fell into the same category and would be easer to process, and the floor switcher on the left since we wanted it to be both visible and because it was dynamic content.

Image Added

Figure 1: A screenshot of the entire floor plan page. You can see each of the elements described on the image.

The image in the center shows current floor of the floor plan of the dorm being managed*;* it is annotated with colored labels (described with the legend) so that the user can gather information from quick glances as color is a good visual differentiator. Because floor plans might be large and difficult to understand at a glance, we also made sure to have the image be both pannable and zoomable, so that the user could examine particular areas of a floor more carefully if they wanted; we decided to make the interface work similarly to Google maps both for the sake of external consistency and efficiency (shoutout to Google). The zooming is done by moving the slider on the top left of the image, and the panning is done by either holding the mouse down over the arrows in the top left, or by using the mouse to do real-time panning.

Image Added
Figure 2: A closeup of the image of the pannable, zoomable floor plan.

In addition to the other wonderful features of the floor plan we've already discussed, we also made the floor plan clickable, with click events over rooms generating dialog boxes (top left corner on center of room) displaying information about the room. The current interface had information only about the room number and the residents staying in the room, but it is likely in the future more relevant information will be included to help the management staff with making rooming decisions. From the dialog, a user can create a new task by clicking on the large button present on the dialog, and can also exit out of the dialog by clicking on the X-button. The dialog was created this way for external consistency; for safety, we made sure that multiple dialog boxes could not pop up on the screen and crowd each other - we also made sure that the dialog scales and moves with the image when panned or zoomed.

On the right you can see a floor-switcher; we created this piece of dynamic content for the sake of helping users navigate floors in a floor plan (as indicated by the name), since we felt that there was only space to put one floor in the viewport at a time. The selected floor is highlighted differently, and each floor is represented by a text box which has the affordances of a button, for external consistency. We chose the colors for the sake of unity with the rest of the interface, as well as because the blues we chose for selection, highlighting, and deselection were all discernible. 

Image Added                   Image Added

Figure 3: Screenshots of the dialog which pops up on clicking the floor plan (left) and the floor switcher (right).

So that the user would be able to discern the information provided by the color labels on the floor plan, we have a large legend on the right side - since color doesn't inherently indicate any meaning in floor plans or our context, our heuristic evaluators and users found that something like this was necessary (information scent).

For efficiency, we also included the floor statistics table - horizontally and vertically aligned with a large header and line width mostly for the sake of aesthetics and readability. We included the floor statistics table below the legend due to information scent - when viewers see the necessary legend, their eyes easily move to the table below.

Image Added Image Added

Figure 4: Zoomed screenshots of the legend and floor statistics table.

Lastly, we have a search bar on this page for helping the user navigate the floor image efficiently. The search bar has the typical affordances and benefits of search bars, like autocomplete for safety, as well as border highlighting to indicate selection. The user can search by room number, or name of resident - on selection, the floor plan automatically pans so that the room selected (or room of the resident) is close to the top left corner of the image (next to borders so it's visible), and also pops out the dialog for the room (for visibility of the changes).

Image Added
Figure 5: The search bar for the floor plan.

Implementation