Versions Compared

Old Version 45

changes.mady.by.user Unknown User (summit@mit.edu)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (martelly@mit.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Panel
Design    

The main page is the default landing page for users. It's Its main use is to keep track of the current active tasks which may be complete or incomplete.

Image Modified

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 in the "Recent Activity" column on the left. On the right, users may can look up specific tasks or types of tasks and edit them as necessary.

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

Image Removed
Figure 3: A close up of the notifications section.

by using the search box and drop down filters. In addition most columns are sortable. When the page is first opened the default sorting is based on the last time a task was updated. The reason for this is that we figured that users would be changing a few tasks multiple times.

Image Added
Figure 2: When a task row is clicked, additional information about the task is displayed. Image Added
Figure 3Image Removed
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 Removed
Figure 5: Showing off the possible filters that can be used.

Implementation

main page.

When a relevant task is found in the table on the right, a user can click the row to see more information. The details displayed include a progress bar which indicates how many of the subtasks have been completed. Users can also easily update the subtasks by clicking the appropriate checkboxes. They are then able to click the "Save Changes" button so that the changes are pushed to the server. In order to give some feedback, the progress bar is updated when the button is clicked. There is also a button called “Edit Task” which takes a user to the task creation page. When returning to the main page from the task creation page, the task which was just changed gets a bold border for 5 seconds before disappearing. Another feature worth pointing out is the "Collapse Visible Tasks" button. The table used remembers which row details have been opened. This can cause clutter if a user has been looking at many tasks. The "Collapse Visible Tasks" is a simple way to close all the details of all tasks so that the clutter is gone.

Image Added
Figure 4: Showing off the possible filters that can be used.

There are several filters in effect. Users can use the search box and type in a name, a room number or almost any other query to narrow down the results. In addition, there are designated drop down menus which are used to filter based on whether all the subtasks are complete or not, what type of task it is, and what floor number we are examining.

Image Added
Figure 5: A close up of the notifications section.

The recent notifications column shows recently changed tasks. The notifications are automatically sorted by date. Currently a notification shows the room number, the date and a progress bar. Ideally, a future iteration would show which subtask was checked off most recently. However, our backend currently does not support this feature so instead we have used the progress bar. Clicking on a notification will automatically filter the table on the right and show the details of the tasks.

Implementation

Implementing many of the features of the table on the right was very easy thanks to an external library called DataTables. Once the API was learned many challenges were easily overcome. DataTables takes care of filtering based on search text. It can also deal with filters restricted to a single column. This feature was used for filtering using the drop down menus. In addition, it knows how to deal with showing details when a row is clicked. In order to populate the data table, all the tasks for a given floor are downloaded in a local copy and the data is added to the table one by one using an API call. When a task is updated, the local copy is changed so that the internal state is accurate and an update request is sent to the the Parse server we used. The reason we keep track of the local copy is that the Parse server can take several hundred milliseconds to make a change. This delay would most likely be noticeable to the user and undesirable.

When the "Edit Task" button is pressed, the object ID is passed as an argument in the URL and the page is changed to the task creation page. After submitting the changes, that same object ID is passed back to the main page. This object ID lets the main page know which task to highlight in the table for feedback.

The recent notifications column uses a similar local copy technique as used for the table. Only the top 15 most recent tasks are used for the notifications. The message is generated based on the completeness of the subtasks. If no subtasks have been completed, a task is considered to be new. If all subtasks have been completed, a task is considered to be complete. Anything else is considered an update on a task. In the future a better implementation may take into account what subtasks were completed and when.

Task Creation Page

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.


Figure 1: The start new task page.

One of the importance decision that 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.


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.


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.

  ------------> 
 Figure 4: Edit Task functionality

Implementation

This page follow follows 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 on the resident is stored on the Parse database since it will be dynamically changed over time. We utilize the convenience of Jquery JQuery UI in creating dialog dialogs and drop-down menumenus. We also make use of twitter bootstrap Twitter Bootstrap for organizing the layout. All of the 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 informations 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 rooms is update dynamically through parseParse. For example, if a person moves into a room, we update the current list of resident residents of that room and remove it from the list of the available roomrooms.

The MIT directory is design designed 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 is attached to the result to auto-fill the form.

The list of suggested tasks are is 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 types of objects that currently are present on the server: Resident, Task, and Room (See Figure 5). Each of this object will have these objects has 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.


Figure 5: The current state of the parse server.

...