GR2 - Designs

Scenario

Miak Zan is searching for HASS classes for the upcoming spring semester. He is an intelligent and exceptionally good-looking sophomore who breezed his way through his first three semesters, taking classes that matched his interests without worrying much about HASS requirements. But his advisor has warned him that he will be in Great Danger if he doesn’t take a CI-H this semester, and Miak realizes that the time has come to buckle down and get his HASS in gear.

Miak has previously taken several HASSes including Advanced Fiction Workshop, and Intro to Acting. He is currently anticipating 4 classes in course 6, and needs his HASS classes to fit into his already established schedule. He would like to take multiple HASS classes if there are more than one that interests him, but he needs at least one class that fulfills his requirements. To help him figure out which classes to take, he decides to try a helpful HASS picker tool called “I can has HASS”.

Miak begins by running a search with the following options: HASS-D category 2, 4, or 5; CI-H yes; open-times: MWF 9-11, MW 12-2, TR 12-1, MTWR 3-5. The application provides him with all the classes fitting this description.

Miak sifts through the list. He sorts the classes by rating and number enrolled, and organizes them by various constraints (department, topic, time) to help him focus his search. He views the class descriptions of many classes. Eventually, he selects Bioethics, which is HASS-D 2 and a CI-H. He flags Bioethics as “taking this term”. He also flags several other classes in his result set as “interested in.”

There is nothing good on TV, so Miak decides he wants to see what his friends are taking. He updates his friends list on the site by adding all his closest friends.

Some of his friends also use I can has HASS, and Miak looks up what classes they are taking. He finds several additional classes he thinks are interesting and flags them for the future.

The application automatically saves Miak’s selections. Miak prints out a schedule of his classes this semester and leaves the site feeling emotionally and spiritually fulfilled.

Designs

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)

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 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. Miak selects “HASS-D 2”, “HASS-D 4”, “HASS-D 5”, “CI-H”, and “FITS MY SCHEDULE”

When Miak drags the “FITS MY SCHEDULE” tag to the center of the screen, a pop-up window labeled “My Schedule” appears with a grid divided into hour-long slots for each day of the week. Miak clicks on the slots for which he already has a prior commitment, marking them with an “X”. When he makes a mistake, he simply clicks on a slot again and the X disappears.

When he has finished, he clicks “OK” and the window vanishes. He’s satisfied with his selected criteria, so he clicks a button at the bottom of the page to begin his search.

Task: Sift
Miak’s search results are displayed as a collection of objects (“balloons”) floating around the screen. They are labeled with their course number, and when Miak clicks on a balloon, a small dialog box appears nearby with more information about the class. The dialog box stays visible until Miak clicks an ‘x’ in the corner to close it.

Miak is a little overwhelmed by all his results, so he selects “Sort by HASS category” from a list of sorting options at the top of the screen. In response, the balloons self-segregate into 3 labeled categories: HASS-D 2, HASS-D 4, and HASS-D-5.

Eventually, Miak decides that Bioethics (STS.006) looks interesting, so he drags its balloon into a bucket at the bottom of the screen for classes that he plans to take.
He also thinks 21H.467 looks interesting, but he isn’t sure if he’ll have time for it, so he drags it into a second bucket for classes that he’s interested in.

Task: Share
Miak wants to know what classes his friends are taking, so he uses the menu to navigate to the “Friends” page. He types the Athena names of his closest friends into a search bar to add them to his list of friends. The names of all of Miak’s friends who also use I Can Has HASS appear on the page, followed by the classes that they have flagged as “taking” or “interested in.” Miak’s own “Taking” and “Interested In” buckets are still visible at the bottom of the screen.

Miak sees that his good friend Alyssa P. Hacker is taking Rhetoric, which is also a category 2 HASS. He decides that he would rather take Rhetoric with Alyssa than take Bioethics by himself, so he drags “21W.747 Rhetoric” from Alyssa’s list into his “I plan on taking” bucket. He drags Bioethics out of the bucket and it disappears with a puff of smoke.

Task:  Sync/Save
Finally, Miak uses the menu to navigate to the “Export Schedule” section of the site. It displays the classes that he plans on taking (21W.747 Rhetoric) and three options:  Email these classes to me, Print my Schedule, or Sync with Gmail. Miak clicks “Email” and the name of the class, along with its description and a link to its Stellar site, is sent to his MIT email address.
If Miak returns to the site, it will recognize his MIT certificate, and his list of friends and class choices will be saved for him.

Learnability

This design makes heavy use of drag-and-drop operations. The use of drag-and-drop has been growing in popularity so many users should feel comfortable with it, especially those who are familiar with the Mac operating system.  For those familiar with them, drag-and-drop interfaces are among the most intuitive and easy to learn because they mirror the way we manipulate things in the physical world. However, drag-and-drop interactions are still not nearly as prevalent as the more traditional point-and-click paradigm, and therefore may pose some learnability problems, especially for users who are not as familiar with drag and drop. For this reason, we will need to take extra care to convey clear dragability affordances, such as changing the mouse pointer to a hand when it is hovering over a drag-able object.

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.

Visibility

This design makes some visibility tradeoffs. On the one hand, displaying results as free-floating “balloons” that can be dynamically sorted makes it very easy to see large trends, such as how many departments are represented or how many results there are from each HASS category. Another visibility advantage of this design is that it makes it very easy to compare two results side-by-side. However, this comes at the expense of being able to quickly browse through results. In order to see the details associated with a particular result, the user needs to click on that result, which can become tedious. In addition, if the user has details for many results open, then the screen may become crowded, further diminishing visibility.

Efficiency

This design is not very efficient, due largely to the visibility problems described above which make it difficult for the user to quickly browse results. In addition, when there are many results the balloons may become very small, greatly increasing the amount of time needed for the user to click on them according to Fitts’s Law. Finally, the efficiency also suffers from the heavy use of drag and drop interactions, which take much more time and require more mouse movement than either clicking or using the keyboard.

Error prevention

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 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.