...
Design 2: Text-based interface
When Miak enters the application, he sees a single text box, where he can type various commands, on a bar on the left. There are a series of examples below the text box, and Miak is able to deduce from them how to use the interface. He types in the commands to select HASS-D 2, 4, and 5, select CI-H, and input his schedule.
On the panel to the right of this toolbar, there are several components, including an ASCII calendar and a list of classes that match Miak's criteria. With every command that Miak enters, the panel updates itself to reflect his changes. After Miak is done, he uses additional commands in the text box to manipulate his search results. For example, he types "sort: rating" to sort his results by descending rating. After some deliberation, Miak decides to choose "Stagecraft" and "Linguistics" by typing the command "select: 24.900" and "select: 21M.606", which flags those classes.
After selecting his classes, Miak copies the ascii schedule provided for him into a Word document and prints it out.
Now Miak is curious about what classes his friends are taking. He navigates to the "Friends" page using the menu and adds his friends using the search box provided, which lets him search by first or last name. He is delighted to see that 3 of his friends are also taking 24.100. However, nobody else is taking Stagecraft. Miak doesn't want to be the only one! He uses the menu to return to the search results page and uncheck Stagecraft , where he types "unselect:21M.606" so that he is no longer listed as taking it.
...
Task: Search
When Miak first enters the site, he sees a bunch of tags like “HASS-D 4” and “NO FINAL” scattered around the screen. There is a marked area at the center of the screen where he can drag and drop tags with the search criteria he wants. Ben Miak selects “HASS-D 2”, “HASS-D 4”, “HASS-D 5”, “CI-H”, and “FITS MY SCHEDULE”
...
Although the design does not include many barriers to prevent users from making errors, most tasks are easily reversible so that error correction is quite good. If a user changes their mind about a class that they have selected or a search tag they have chosen, they can simply and painlessly drag it out of the selection area to get rid of it. And in the “search” and “sift” views, if a user accidentally removes a class or a tag, it is readily available to be selected again. However, if a user removes a class while in the “Friends” view (as Ben Miak does in the above storyboard), an accidental deletion could mean the user has to redo their entire search to find the class again. In that situation, we may want to present him with a confirmation dialogue box.