...

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.

...