Design
USER ACCOUNT
In the final design, we added a login (with registration for new users) because of feedback we wanted to give users of students they’ve emailed before. We needed this specific to user so we created accounts.
MAIN PAGE
This is the main page of the search system.
In regards to the placement of everything, we hadn’t received any negative feedback and so although we’ve gone through iterative changes, the mains earch page layout has not changed much.
SEARCH INPUT
A lot of the feedback we received from the heuristic evaluation and user testing was that the autocomplete for the search did not do what users expected. Originally we had autocomplete filled with choices to suggest what the user meant. For example when the user typed in “6.813, 6.02” it would drop down with choices of either “6.813 OR 6.02” and “6.813 AND 6.02”. We presented that functionality in a different way (explained below) and left autocomplete to just complete the classes which is what our users expected with autocomplete.
To address the issue of unclear search requirements, we then moved everything to a pop-up that allowed users to select what they meant.
This is now used to clarify symbol confusions: using commas, spaces or such. We realize we still needed this functionality is some form, so we decided to separate it from the autocomplete function otherwise the list of suggestions would be growing exponentially.
HIDE
Another feature we had was the ability to “hide” a student from the list of matches. We added this capability for users who just wanted to clean up the students they had to look through.
We went to several iterations until we gave enough feedback to users. We had the “Undo” button on the top for the most recent “Hide” action. We also had a counter of how many students were hidden at a time on the top right. And clicking that button (which was only enabled when there was at least 1 student hidden) would pop up with a list of students that the user can now restore.
MATCH FILTERING/SORT
From user testing, we received feedback that called for being able to filter by year as well as a more clear way of sorting students. So we added settings that allow user to customize what they see.
One thing we could never get around was a way to distinguish all of the capabilities available, where users can 1. Hide 2. See Details and 3. Email. Only 1 and 2 are available student by student with just one click. Where for 3, emailing, users need to select a student and then click the email function. This is an advantage for users who like to email several students at once and so can go through and continue selecting students in between other actions. The problem is this is a tradeoff for users who like emailing student by student and sometimes is confused by the need to select one student then email, and repeat this process for each student.
The email pop-up hasn’t changed much either but we do make the subject and message fields required in order to send. There is also explicit feedback that what a user types will be saved and then closed with the “Save and Close” button.
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
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 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 handling 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 clauses" within "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 Confused" 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 usability.
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.
Briefing Used
You have been selected to try out a new search system for UROP candidates. You are Professor Smith and you are looking for a UROP student for your project.
1: Register and log in with a email
2: Search for students who have the classes and skills you think they should have.
-Try different combinations until you find what you deem fitting students.
Suggestions:
1. 6.005 or 6.813, and 11.127 with Java or C++ skills
2. 6.813 and 6.01 or 6.02 with big data or Javascript or JQuery skills
3. 2.001 or 2.002, and 2.006 with CAD or AutoCAD, and Solidworks skills
3: Look through some students
4: Hide a few students from the list
5: You change your mind so restore a few
6: Select and email a few students about interview times
Usability Problems
1. Catastrophic: “Resume” button was intended to show a student’s Résumé but a user could think it means resume back to the search screen. (User 1)
Solution: Change the button to display text “Résumé”.
2. Catastrophic: Searching for multiple “and” and “or” in one clause results in one suggestion repeated several times. (User 2)
Solution: Re-examine parser and suggested terms.
3. Major: When new users register an account, the previously entered information is stored in the text field. (Users 1,2,3)
Solution: Clear the text fields for registering a new account.
4. Major: If the requirements text field is empty, there is still a popup of Suggested Values. (Users 1,2)
Solution: Do not have the popup or have it say “You didn’t enter anything!”
5. Major: User didn’t realize the need to select a student and then e-mail. (Users 1,2)
Solution: Consider that with the hide functionality, the “Email Students” button could be clicked to default email all the students that match. Consider changing the “Email X students” button to say “Email X selected students”.
6. Major: Users don’t have an efficient way of emailing all students that match besides selecting them all one by one. (User 1,3)
Solution: Have a “Select All Students” button.
7. Major: User could not find documentation for learnability. (User 3)
Solution: Consider putting together a “Help” section for website capabilities.
8. Minor: User was misled by “Showing 40 matches” when only 6 were visible at a time. (Users 1,3)
Solution: Consider removing “Showing” or changing it to say “Showing 6 of 40 matches”.
9. Minor: Users can get confused with the inconsistency of having to select a student and then perform the Email action whereas the Hide action can be performed with or without selecting a student. (User 1,3)
Solution: None because of the tradeoff in scenarios where users need to hide in the middle of selecting students to email. Users can’t have freedom to change their minds in the middle of selecting students to e-mail.
10. Minor: Users didn’t know what to expectin clicking the gear icon. They understood it was settings of some somrt but didn’t know if it was view settings, search settings, or other miscellaneous settings. (Users 2,3)
Solution: Adding text to say “Filter/Sort Settings”
11. Minor: Search input beginning with “or” or “and” does not add the respective “or” or “and” clause, but always returns as an “and” clause. (User 2)
Solution: Have the parser account for the case of having an “or” clause before classes.
12. Minor: Users are not stopped in their search when the requirements return no results because they missed the feedback in the match results. (User 3)
Solution: Consider preventing users from adding more requirements if current requirements return none until the user updates the requirements to allow for more matches.
13. Cosmetic: User understands “Courses” requirement to mean either Course as in major or Course as in class. (User 3)
Solution: Consider either using “Classes” or “Subjects” or both.
Reflection
The iterative design process was definitely a learning process for our group. It was interesting to see the feedback that we would get after each stage, and useful to incorporate the feedback into the next iteration of our interface.
Design stage
One of the best things that we did during the design stage was to come together with many different ideas for an interface. Something we could have done better, however, was to keep the many initial designs of the individual group members in mind. After picking the initial elements from each design that we liked, we, as a whole, forgot about the rest of the ideas. There was a point in the final stage of developing the final prototype where all of us were not satisfied with a particular portion of our interface. In a fit of inspiration, however, we decided on an element we had turned down in the very beginnings of design, tabbed organization. Had we kept all of the ideas we had during the initial design stage, it is possible that we would have been able to solve our issues much earlier than we had.
Prototyping and user testing
The different stages of prototyping were very helpful in providing us with feedback. The initial paper prototype helped us fix issues with layout and confusing wording before coding even began. We were able to simply scrap parts of the paper prototype and quickly fix glaring issues between testers, if absolutely necessary.
The computer prototyping enabled us to actually witness our features in real time, and made it much easier for us to see the reactions of users to a particular functionality. This was most helpful in demonstrating what parts of the prototype made no sense logically. Thus, we were able to focus a lot of our time in making the "AND" and "OR" logic fully understandable and easily learnable to users, rather than continuing with what we thought made sense.
One of the most interesting things that our team learned was the drastic difference in the way users and developers thought. Logic and actions that made sense to us often completely baffled the user in ways that we had never guessed. There were many times where testers pointed out things that, after brought to our attention, seemed painfully obvious. At the time of development, however, we had been convinced that our method had no issues.