GR3 - Paper Prototypes

The following photos are from our final iteration prototype.

Close up of the class info sidebar:

Close-up of Alert dialog:

Login window

Briefing

When students arrive at MIT, they are faced with a daunting task of deciding what classes to take for the next four years. The task is complicated by institute graduation requirements, HASS requirements, Major requirements, and overall credit requirements. Additionally, some classes require prerequisites and some are only offered during in either the fall or spring semester.

One group of incoming students sets out to conquer this task with a tool such as excel. They research all the classes they could ever want to take, lookup a degree requirement chart, and begin trying different class selections. For each different selection, due to courses constraints, the resulting maps get shuffled and the task of keeping track of GIRs and Major requirements becomes more confusing. With this approach, designing a reasonable course map can take on the order of several hours.

The other group of incoming students tackles MIT semester by semester without taking time to plan out a map from the beginning. This approach works out well in some cases, but in other cases it results in a senior year scramble to complete required graduation requirements that had been previously neglected.

FourPlan seeks to help both of these groups of students, the ones who are too lazy to plan, and the ones who spend way too long planning, by working with the student to more quickly populate a desired map. FourPlan comes with several features that aid in speeding up and simplifying the selection process:

  1. The program launches a pre-generated course map for the user's specified major.
  2. A direct manipulation on the courses in the map allows users to drag and drop courses to any semester a course is offered, and easily modify course data.
  3. Classes can be added to and removed from the map at will.
  4. Graduation requirements are placed onto the map from the beginning and the inclusion of these courses in the map is enforced. In cases where multiple classes can be chosen to satisfy a requirement, a generic "GIR", "AUS" or "HASS" course will be placed onto the map and the user can modify this to specify an exact course. The system makes sure that any class chosen indeed satisfies these requirements.
  5. The system keeps track of prerequisite and semester offerings to ensure that courses are placed into valid times.
  6. Users can manage preferences for each of the course offerings and allow the program to automatically assign the course a position in the map.

It is our belief that FourPlan provides incoming students an opportunity to play with their course maps in a fun situation, allowing them to focus on the classes they want to take rather than worrying about what they need to take in order to graduate.

Tasks

1. You are a freshman entering MIT in fall 2010 and you know you probably want to be course 6-3. Please login to Fourplan to start creating your schedule.

2. You've heard awesome things about Prof. Sadoway and really want to take 3.091 instead of 5.111. Please change your schedule accordingly.

3. You've already received AP credit for 18.01, so you want to take 18.02 and 18.03 instead of 18.01 and 18.02 during your freshman year. Please make the appropriate changes.

4. You decide you'd rather get started on Course 6 classes early, so you want to move 6.01 to Spring 2011 and postpone Bio to Fall 2011.

5. Congratulation! It's now May 2011, and you just completed your freshman year. Please mark all your freshman classes as "completed" and enter the appropriate grades.

Observations and Revisions

(not separated by user)

Overall, we ran 7 users: 3 for the first iteration and 4 for the second iteration of the prototype.

Observations from first iteration:

1) Freshman don't have departments yet.

2) Even though users could change the classes for each block, most users would delete and then add a class instead of changing the block. This may be partially because the affordances that show something can be edited are harded to convey with paper.

3) Users also had to be told that classes could be moved with drag-and-drop. This might be more obvious on a computer interface.

4) People would create a new class for 18.03, even though one already existed on the page.

5) People would try to remove 18.01 completely from the schedule, but our model is to make sure all requirements appear somewhere, so we need to address this.

6) We explained that moving 7.013 to the fall is not allowed, but this was confusing. Also, freshman may not understand the different course numbers for Bio.

7) We need to have a clearer explanation of why things can't be done (i.e. fall and spring classes)

8) The difference between "completed" and "already received credit" was confusing.

Changes to Prototype

We did not change anything major in our design, but did some minor tweaking to make some things more clear.

1) We added an additional column to the schedule that represented "Classes with credit from AP classes or ASEs". This meant that if students had a course like 18.01 that htey passed out of, it had a reasonable place to go on the 4-year plan. (NOTE: The reason this is important in the long run, other than from an organization standpoint, is that our automatic scheduling algorithm will need to run a check on all requirements.)

2) We got rid of the "Already received credit" option and just added more options in the grade dropdown (i.e. P and S) These are automatically filled in if the class is dragged into the "AP Credit" semester.

3) We added an alert feature that has some explanations for why you can't do things. For example, when they tried to move 7.013 to the fall, it suggests that they take 7.012 instead since 7.013 isn't offered.

Final observations and thoughts

The changes we made eliminated most of the confusion that we had during the first iteration. The alerting for moving classes around that weren't offered during certain semesters seemed to be really helpful. One final thing that came up was that we do make a lot of assumptions about what students know, and we have to realize that incoming students wont' be familiar with a lot of MIT's numbering. For example, we should provide ways to access info about the majors (through links) and make sure that at least the number and title appear on all of the course boxes. Overall, however, our design and idea seemed very well received by our test subjects.

  • No labels

1 Comment

    • Glad that you receive lots of feedback from users and made improvement to your iterations.
    • The briefing isn't quite brief. Few lines would already suffice and we should let users explore what the site has to offers by theirselves.
    • To make classes look more drag-able, you can use visual metaphor like a post-it notes or show visual feedback when users mouse over, such as a hand cursor.
    • I haven't seen a dedicated screen to find and add a new class. Is that done all in the pop-up class info? If so, please think about how to help users enter classes effectively. By the arrow down icon in the sketch, I assume first 3 fields are drop-down list right? Is drop-down list better or textbox better? There can be many classes in a departments so a drop-down list might be hard to navigate. Also why title is a drop-down list? If you can enter class name first, we can also populate department and title and description automatically.
    • I guess for this project, you assume users will use MIT official site to browse and learn about classes, and just use this interface to arrange classes in the most logical way right? That's totally fine and we should make the arranging class features better than existing solution. I really like the ideas that you can suggest users to take 7.012 instead of 7.013. Maybe you also can do highlight on semesters' slots a class can be dragged into. If user drags into a not appropriate semester (either not offered or missing prerequisites in previous semesters) you can show a (!) alert 'icon' at the corner of that class bubble,then user can click on it to learn why. I suggest this alert icon instead of an alert popup because popup is normally intrusive and negative. What if users only want to put class bubbles around temporarily? an alert every time can be annoying right?
    • Finally, is there anyway a user can know if the classes he chooses for a semester don't conflict in class time?

    (all these are just suggestions to make a more awesome projects, you should make decisions by yourself and you don't have to implement everything for GR4)