Versions Compared

Old Version 10

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

Saved on

compared with

New Version Current

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

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Now, not only is there feedback that the email has been sent successfully, but the system also tracks when was the last time a student was emailed. This is the reason why we added the user accounts mentioned above.

Implementation

We primarily used javascript and jQuery to handle the front end UI implementation. The styling of the different elements and popups of our interface were primarily handled by CSS files. All of the popups, with the exception of the alert used if the user tries to leave the page (which is browser dependent) are all formatted the same for the sake of consistency. 

The back end of our interface was primarily implemented with javascript and python. The parser used to handle input from users and the class responsible for grouping "AND" and "OR" clauses were implemented using javascript

We decided to use Flask to implement the web app. 

...

Frontend Implementation

The front end is a combination of HTML, CSS, and JavaScript. (Data is loaded via JSON; more on that later.)

We use a variety of libraries for many reasons:

  • jQuery (JS) - We used jQuery to make our life easier.  Its selectors, event handling, and AJAX support helps simplify the amount of code necessary to implement features.  It also helped greatly with cross-browser implementations.
  • jQuery UI (JS, CSS) - We used jQuery UI primarily for its autocomplete feature.  It was robust enough to offer us the inline tweaking support we wanted for the tagging system.
  • Underscore.js (JS) - Underscore.js is a collections manipulation library.  We used this to simplify what we needed to write since JS's built in collections support is fairly weak and inconsistent cross-browser at times.
  • Bootstrap (CSS) - We used Bootstrap all over the place.  The CSS component was used to generate styles for our website, helping us produce a professional and clean layout.  This layout also has responsive features, provided by Bootstrap.
  • Bootstrap (JS) - Bootstrap's JS library was also used.  Its primary usage was the alerts (notifications shown at the top of the page when you hide a student/send an email), tabs (seen in the Full Student Profile page), tooltips (in the Full Student Profile page when hovering over class numbers), popovers (used for the e-mail timestamp), and the dropdown (used for the options menu.)  If we did this again, Modals would also be reimplemented with Bootstrap.

Backend Implementation

The backend was implemented both in the browser (pagination, hidden students, filters) with JavaScript and also in the server (filtering, loading the data, tracking emailed students) with Python.  The Parser that converts generic input into potential AND/OR groupings is written in JavaScript.  The Terminator which converts a Parser output into a Grouping (the boolean representation of the query) was originally written in JavaScript for GR4 but was also ported to Python for GR5. (Both are used in the final implementation.)  The Grouping class is also both JavaScript and Python.  ObjectFilter, which was originally JavaScript (GR4), was converted to Python for GR5.  It takings a Grouping and filters out the students.

The backend server was implemented using Flask.  We chose Flask because of Sarah and Chris's familiarity with it.  Python was the language chosen because the whole team was familiar with it.

The login system is implemented entirely in the backend.  We store only three pieces of information: e-mails (usernames), sha256 hashes of passwords, and a list of all emailed students for that user.  Password hashing is done via Python's hashlib.

Compiling the Templates File

We wrote a custom build scripts (bin/compile.py) that would take our templates (.html files), dump them as a JSON object (so, just a string), and then write this JSON object to a file.  This let us access our templates in JS.  It was only necessary to recompile after editing the templates.

Content

The images that we used for the student cards are images that we took off of Google. The data that we used for the students was a combination of fake data and modified real data. We sent out a survey to students at MIT to gather data, reasoning that it would be the simplest way to gather a good variety of classes and skills. The data we received in return was manually organized and formatted into a database of students, skills, and classes. Though the data is added to the database with a python Python script, they are stored as JSON objects and are later accessed by javascript functions.

When collecting the data, we wrote a collection form in PHP.  This form wrote to a SQL database.  Then, our dumper.php script read the database and translated it to a form that our Python backend would read.  We then manually transferred this data and corrected any inconsistencies and typos.

Collection form: http://sz-ex.com/chris/813/

Data dumper: http://sz-ex.com/chris/813/dumper.php

Challenges

By far the most difficult thing to implement was the logic behind groupinghandling of the user boolean input for Courses and Skills. We had to rework the parser and grouping code several times before we reached a balance of utility and learnability. One feature we had to entirely remove from grouping was the ability to nest "and AND clauses" within "or OR clauses" (e.g. (6.831 OR (6.813 AND 6.005)) AND 6.01). This quickly became very confusing, and exponentially increased the number of options that would be shown to the user in the "We're confusedConfused" dialogue used to clarify ambiguous groupings. We decided that this was an unnecessary implementation given the other capabilities of our interface, and chose to drop it in favor of maintaining simple learnability and useabilityusability. 

Evaluation

Our target user population is professors, administrators and project leads who need to fill positions with qualified and fitting MIT students. We tried to select our users to have different backgrounds. User 1 is an administrator who looks for a variety of students, from all different majors depending on the temporary position she’s looking to fill. User 2 is a MIT professor who works with Media Lab and the Department of Urban Studies and Planning and generally looks for Course 6 students. User 3 is a project lead who works to search for engineering students to fit the program she oversees, generally Course 2 and 6.

...