...
A year later Paul decides to use FourPlan again and is asked some questions about the events that have happened in the year between his last plan and the current date. FourPlan alters its internal state to reflect the courses that were completed and updates its plan, asking a few questions to resolve new issues that have arisen due to a conflict. Paul makes a change using direct manipulation based on his outside knowledge of courses that work well together.
Design 3 Analysis:
This interface’s big concept is “Ask as few questions as possible and do the work for the user.”
This interface is particularly learnable because it has exactly one thing of interest on the screen at any time, and there is a clear call to action. The current question is the only thing the user needs to be concerned about, rather than modes, tabs, panels, or menus. If the user is confused, they can skip a question.
The major theme of this interface is visibility into the software’s constraint solver. Sometimes very logical and practical decisions made by a computer can be reduced to a solution a human can’t explain. Instead of trying to find out why the system suggested an unusual plan, users often get frustrated. Therefore this interface is explicitly designed to show its reasoning behind every step. For example, when asking questions this design always begins with a reason such as “The 6-3 degree track requires you to take 2 AUS subjects.” This explains why the system is asking for which AUS subjects Paul wants to take. Furthermore this system also helps deal with more complicated situations such as when Paul has already specified he wants to take 6.805, which is an AUS. In that case this interface would ask “The 6-3 degree track requires you to take 2 AUS subjects, and you already have already indicated that you want to take 6.805. Please choose 1 additional AUS subject to take:” This sort of dynamic behavior helps give the user positive feedback about the process, since it is clear the interface is listening to the user’s inputs. This theme is further echoed when the user is shown the end result of the wizard. If a user mouses over a course, the constraint solver can show exactly why it picked to put the course in that semester. Instead of being confused, the user can query any decisions that seem odd.
One criticism of this interface is that it requires a leap of faith on the part of the user; the interface doesn’t make it easy for Paul to enter a bunch of things he has already decided. This could frustrate a particularly competent student who just wanted help on part of his schedule. One way around this would be to start with a set of questions about what things the user already know he wants to do. The constraint solver could then take those classes as givens. With this improvement, the interface is efficient because only the minimum number of questions needed by the constraint solver will be asked.
Another criticism is that until the questions are complete, there is very little evidence that Paul is making progress other than watching the number of questions he has answered increase. Constraint solving often involves major changes to the solution near the end of the constraint input process. Therefore this interface doesn’t do a particularly good job at keeping the user engaged through a big slog of questions. One possibility would be to show a schedule-in-progress, but this would take up screen space and potentially be highly annoying if every question radically changes the output. I suspect this aspect of visibility is one that will simply need to be a tradeoff; either the user sees an artificial measure of progress like a progress bar based on the number of questions, or the user simply doesn’t get any notification at all.
There is also a risk that the constraint solver might be slightly incomplete. In a particularly annoying edge case, users might be forced to game the system by guessing at what questions really mean and giving false answers so that their intended results will happen. This will only be fixed by making sure the constraint system is implemented thoroughly.
Minimal error prevention is implemented by checking that the user is giving reasonable responses to each question. It is also the case that no choices made by the user are expensive to undo. Should a user incorrectly answer a question, they can simply back up and change their answer. In this case, excessive error prevention such as confirmation dialogs is not worth implementing, because the cost to fix an error is so small.