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
The implementation of our interface was divided into several main parts: Parsing and grouping, filtering and results, and history tracking.
Parsing and grouping
One of the most difficult features to implement was the ability to easily handle and display the requirements (classes and skills) that the user would input. There were many different aspects to consider.
Parsing
We wanted the user to have a lot of freedom in picking and choosing which requirements were necessary. That is to say, we allowed them to have access to "AND" or "OR" clauses, indicating which combinations of requirements were desired. The parser initially implemented this by predicting which symbols and predicates were the most common (e.g. ",", "+", "/", "and", "or"), separating requirements based on how they were textually connected. We later changed this, deciding that it would be too confusing if we incorrectly predicted the mindset behind a user picking a particular symbol. The parser now simply separates requirements based on spaces or any symbols, and queries the user for choices on the groupings of "OR" and "AND" clauses should there be any ambiguity.
Grouping
The implementation of autocomplete was one of the most confusing features to the user. Initially, we implemented the autocomplete as a method to allow the user to see the various different combinations of "AND"s and "OR"s as they typed multiple requirements. The autocomplete did not show a list of possible requirements based on what the user was typing. For example, if the user had just finished typing "6.813" and was in the process of typing the "6." for "6.831", the user would see "6.813 AND 6." and "6.813 OR 6." in the autocomplete instead of the more intuitive display of the possible classes starting with "6.". For many users, however, this proved confusing, as it contradicted the common usage of autocomplete. Correctly implementing this for good learnability and what we thought would be useful proved to be very difficult. After many iterations, we chose to implement autocomplete with the more common usage (to show users options that complete what they are currently typing), and resolve any ambiguity by asking the user with a popup containing all the possible "AND"/"OR" choices.
Another problem we had when grouping requirements was how to properly display the grouping to the user. We decided pretty early on that a good way to show the "OR" clauses between requirements would be to have a physical "or block" displaying which requirements were bound by the "OR". In one iteration, we displayed the "AND" clauses also as "and blocks", with a visual box encapsulating the related elements. This proved confusing to look at, however, as the requirements quickly were surrounded by many boxes and lines. We lastly settled on "or blocks" grouping "OR" clauses, and a simple "and" shown between any elements bound by an "and clause".
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 useability.
Groupings -> JS class that represents ANDs and ORs in code. Will automatically flatten to the smallest component.
Terminator -> Takes in a valid output from Parser and converts it to Groupings
Parser -> Takes in any string and gives back a list of possible options (for and/or and parenthesis) where ambiguity might occur
objectFilter -> Takes in a grouping and list of JS objects and will filter those objects based off the grouping
Set.js -> Modified implementation of a Set class in JS
File: Data.js -> Loads the data from the backend, including courses and skills
State -> A global variable that maintains application state. Used to update "Start New Search" button and track other things
Front end code logic:
1) When you enter a term into courses/skills, it will attempt to autocomplete based off the loaded file from data.js
2) When clicking "add," it takes your entry and sends it to parser. It then truncates that list to 16 "best" items.
3) This list is fed back to the UI code. If there's only one item, it runs with it. Otherwise, it shows the "We're confused" dialog.
4) After resolving any confusion, it adds this new grouping as an AND block the the global Course or Skills search item.
5) Since this should change search results, it calls Grouping.toString() and sends this new query to the backend, attempting to filter data.
6) Clicking a student will add them to the Selected state property. Hiding a student will add them to the Hidden state property.
7) Adjusting a filter updates the State property and triggers a new search again.
8) Current page is a state property.
9) Entered subject/message for e-mail are state properties.
Not sure what else Tanya wants.
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.