...
Design 1: Weekly calendar
When Miak first enters the site, he is taken to the Schedule tab. Here, he is able to choose the criteria for his HASS classes. He checks off the boxes for HASS-D 2, 4, and 5, chooses the "CI-H" button, and chooses the "don't care" button under final exams. He also checks every department in the scroll list. He then changes the calendar to "Free Mode" and selects all the times he is free by creating and dragging boxes. When he is done, he pushes the SUBMIT button.
The application then takes Miak to the browse page, which displays all the results of his search and allows him to manipulate data. He can sort the results by choosing an option in the sort drop-down menu. He clicks on the accordion arrows to expand the page and view detailed description of each class. Eventually, he decides to pick Bioethics. He clicks on the star next to that class and the application records his selection.
Miak then clicks on the friends tab. He adds his friends "Michaela" and "Mary" by typing their Athena usernames into the search box. After each addition, the friend is added to the lists friends that displayed on the screen. Miak can then easily look at all the friends he's added and which classes they are taking. When he hovers over a class, a box pops up that displays information about the class and options to flag the class. This box is identical in format to the information box for each class in the Browse tab (so it is not displayed below)
after "Save" is clicked...
Learnability
- The interface for creating schedule blocks is very similar to calendar programs, such as Google Calendar, so users who have used similar programs can quickly be able to learn how to use this interface.
- Additionally, the interface makes use of checkboxes and radio buttons, which users are already familiar with. This will help them quickly learn the interface.
- However, the use of "modes" in the scheduler and search criteria (selecting 'busy' or 'free' spots in the schedule, selecting 'old' or 'new' HASS system) may be confusing to users
Visibility
- Almost all information of interest (search settings, schedule, search results, class details) are visible in a single screen. This makes it very easy for users to quickly refer to any piece of information they might need.
- It is easy to quickly browse through results and see all the relevant details (class description, HKN rating, etc)
- For new users this large amount of information may be difficult to process, and it may not be clear where they should focus their attention.
- It is hard to compare two classes; for example, to compare a class at the top of the results list to a class at the bottom, this would require rapidly scrolling back and forth between the two results.
- Some visibility tradeoffs have been made with the department selector. It has been placed inside an iframe, which helps the visibility of the page overall because it means that all the selection criteria in the sidebar can be seen without scrolling. However, the individual department selections are not very visible. The user must scroll through iframe in order to see them all.
Efficiency
- While you can change other options (like HASS-D categories) on the same page as the results, you have to return to the schedule page to make any changes to your free and busy slots. However, since your schedule is the least likely to vary, this should be not a big problem.
- The process for selecting departments is very inefficient, because it requires users to alternate between checking the check boxes and then scrolling down in the iframe.
- Having class descriptions in collapsible accordions makes browsing through results less efficient; however, it also enables you to see more results at once which increasing the efficiency of comparing to specific classes.
Error prevention
- Because the calendar has a constant visual representation, you get immediate feedback on how your schedule looks when you click and drag.
- It supports CRUD, by allowing you to create new schedule blocks, update previously created blocks, and deleting blocks.
- If users decide they want to filter by different search criteria, they can edit their choices in the side panel and the results will update dynamically, so it is very easy to correct mistakes in search specifications.
- All radio button selectors include a "don't care" option, alleviating a common error correction problem with radio buttons: once you've clicked one, you cannot deselect.
- As mentioned above, the user needs to begin the search again in order to change their schedule, making this a potentially costly error.
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, where he types "unselect:21M.606" so that he is no longer listed as taking it.
Learnability
- Learnability for this interface is generally low, since users have to keep knowledge of commands and valid tags in their head, rather than having that knowledge available "in the world."
- In addition, text based interfaces are very uncommon in web applications, so even users familiar with such interfaces may be caught off-guard.
- However, its resemblance to a Unix shell may increase learnability for users who are familiar with Linux or who use the command line frequently
Visibility
- For low numbers of results, the visibility for this design is very good because all of the auxiliary information is clearly displayed in a table, in a straighforward, easy to browse format.
- However, as the number of results becomes larger, visibility decreases as the user needs to do a large amount of scrolling to see all the results. By the time they reach the bottom of the list, they may have forgotten what was at the top.
Efficiency
- For expert users, this interface is extremely efficient, since all most of the input is done on the keyboard.
- However, things like scrolling through a long list of items will suffer in efficiency, since the user must switch to using the mouse.
- Pure text output has the advantage of high compatibility with other applications. For example, the user can easily copy their schedule and paste it into the body of an email, or write a script to download their list of courses to a spreadsheet.
Error prevention
- Error prevention and correction for this design is very poor. For example, if a user tries to input an invalid tag, the system will do nothing to stop them from committing the mistake until they try to enter the tag and are unpleasantly surprised by an error message. In addition, if a user wishes to change their search criteria they need to start the entire search over again.
Design 3: Balloons
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”
...
Another possible learnability issue is that the menu options may not make it completely clear what tasks a user can accomplish in that section of the site; in other words the information scent for menu options is not very good. For example, it is not obvious that a user can edit their class choices within the “Friends” tab.
...
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.