Since late last year, I have been working with Armando Fox to build an application for matching faculty with admits (based on rankings and research interests) and scheduling meetings between them on EECS Visit Day. Before, the EECS graduate admissions committee would manually schedule the meetings by hand on paper. Our application fully automates the process of collecting information and generating a meeting schedule. That system was used for EECS Visit Day 2011.
We discovered during the course of building the application and putting it through real use that full automation is not an effective means to solve this problem. The graduate admissions staff are usually flexible in their scheduling process, allowing late changes to info/preferences and accommodating exceptions to that process. This translates to either additional constraints and goals for the application to handle or additional work by the staff to modify a generated schedule. Adding additional constraints and goals to the application after deployment typically involves rushed development and introduction of bugs. Modifying a generated schedule can be difficult if the schedule is dense or the rationale behind individual assignments is not clear. Neither alternative is favorable.
Is there a different workflow which simultaneously avoids the tedium of building schedules by hand and provides enough flexibility to accommodate unexpected goals, constraints, and missing information?
I hypothesize that the answer is yes and that one possibility involves domain-specific languages. They offer structured ways of specifying and solving problems within well-defined domains.
I further hypothesize that given a structured way of specifying a meeting scheduling problem, different problems within that class can be specified and solved efficiently by the user without developer intervention.
Our primary users are the members of the EECS graduate admissions committee. Some of our users are non-programmers.
We will design and implement the beginnings of a graphical domain-specific language for solving the problem of matching hosts and visitors by preference and generating a meeting schedule while optimizing for arbitrary goals and constraints. Using the goals, constraints, and issues which arose during EECS Visit Day 2011 as guidelines, our system will, at a minimum, allow scheduling EECS Visit Day 2012. Time allowing, we hope to arrive at a system with enough generality to also allow scheduling graduate students with admits in events preceding Visit Day.
We will recruit from our primary users, time allowing, and possibly UC Berkeley students. We will compare our proposed system with the fully-automated application and the fully-manual by-hand approach in a series of scheduling tasks similar that of EECS Visit Day. We will measure task completion time, schedule churn (modifications not leading to progress), and user opinion. In having primary users evaluate the proposed system in a real-world task, we hope to show the efficacy of our approach.
Depending on how much expressiveness we choose to build into the system or what features we choose to include, this project may require more time than we have. Moreover, our primary users are busy people and it may be difficult to have them evaluate our system. Regardless, this will be a continuing project, and we hope to have something substantial to show by the end of the semester.