User Analysis:

Our users are general MIT students which offer the following general demographics:

• Age: 17+ (Will be an MIT student (undergrad or grad))
• Any gender or culture.  Should be proficient in English.
• Any education (will be an MIT student), physical limitation, or computer experience though the user should reasonably be able to navigate a web application.
• Should have knowledge of the MIT system of classes with prerequisites and graduation requirements.

Though our users won't change, when they visit the site they may have different objectives and goals they hope to get done.

Freddy Freshman 

Freddy is an excited freshman who is looking forward to getting to MIT and starting classes.  He has been looking at the course catalog and subject listings for the past few days and wants to take many classes.  Of course he can not fit them all in one semester so he decides to form his four-year plan to include all the classes he is interested in taking.  

Sally Senior 

Sally is a senior entering her spring semester who can not wait until she graduates.  She has finished all of her major requirements, and is excited to be taking electives and "easy A" classes.  She wants to know what classes are easy, those that friends have said are great classes with good professors, and also classes that her friends will be in.  

Ally Advsior

Ally is an upperclassman associate adviser for a group of freshman.  She knows more about the MIT workload and can tell what will be a bad or good semester.  She recommends her students make a temporary schedule and share it with her so we can view it and make suggestions, recommendations, or ask another upperclassman about the workload.

The three above users include three example student populations who have a principal purpose and something different that they would like from a class scheduling tool.  In fact most users will be a combination of the three student populations above: students who want to decide their classes for the semester; want to know the impact their current schedule will have on the following semesters; and someone who wants to know the classes that friends are thinking about taking to decide whether to pick a class for this semester or for next semester. 

Task Analysis:

Four-Year Plan:

The first task involves creating a four-year plan with all of the classes the student is interested in taking and the graduation requirements.  Developing a four-year plan requires coordination and compilation of many different sources of data.  When creating a four-year plan, a user will need a listing of the General Institute Requirements (GIRs), the Major requirements, and his minor/concentration requirements; in addition, they may also want the Subject Listing open in order to decide electives.  All of this information should be included in one location.  After having all of this information, users will want to place classes on their four-year schedule.  They will want to take pre-requisites, co-requisites, and semester availability into consideration as they form their schedules.  A user can form their four-year schedule at any time, through the comfort of their computer; many people may do it along with friends, upperclassmen, or advisers.  There are not really any time constraints to getting the four-year plan, and in fact it will be an on-going process, but a user may expect to be able to make changes or for a simple one within a few hours or days.  The task is generally done by simply trying and doing it; a user may ask for advice from friends as to what classes they should take and when, though the user will fill out and do the schedule on their own.  Lastly, errors which may occur will generally not have deep repercussions; errors may be missing a required class while scheduling, not knowing about conflicts and availability.  Another possible problem is that users may get vested into their four-year plan and as the semester pass by, they may be reluctant to change their four-year plan.    

Semester Schedule:

The second task involves creating a schedule for the upcoming semester.  When creating a schedule, the user takes into consideration the requirements that he must still fulfill, scheduling conflicts, what friends are taking, who is teaching a class, and balancing workload.  This has generally been accomplished by using many different sources for this data; a user would find conflicts and determine the professors by using the Subject Listings website, the requirements by their Major's website, and would have to hunt down friends to find out what friends will be taking.  After getting all of this input, a user will create a schedule that will have classes they want to take with no conflicts, and ideally with friends and good professors.  But ultimately, many of these factors will be up to the user to prioritize.  This task is generally accomplished through the use of their computer, maybe with the help of friends, upperclassmen, and advisers, but otherwise it can be done at anytime and anywhere.  Similarly to the task above, there are not any time constraints, except having a reasonable schedule set-up by registration date; so, a user may take their time and complete their schedule within a few days or do it quickly and figure it out within a few hours, but it will continue to be an ongoing process.  Creating a schedule is generally learned by trying and getting it done and generally does not need to be taught or shown.  Lastly, errors are recoverable: errors may include class-conflicts, and not taking everything to consideration, including recitations and lab hours. 

View Friends' Schedules:

Based on our user research, an important element of deciding a course schedule is the social elements. Taking classes with your friends is seen as preferential to taking classes on your own, especially in a project based major like Course 6. Because of this, a user would like to share their schedule with other users, as well as see the schedules their friends (other users) share with them. This sharing can happen offline or in the same physical location, so it should be frictionless to send and pull up other data. There aren't really time constraints outside of normal use (ie. the constraints for the semester schedule) but if the sharing isn't almost instantaneous, they'll lose interest in this feature/task. Sharing is a common enough paradigm on the internet now that the concept of sharing shouldn't be too difficult. Our system should use on the patterns normally used, to minimize possibility for errors. It's possible a user doesn't know their friends' user name, or don't know how to share the schedule with people who aren't users of the system. We can combat this by making it as easy as possible to register / save your data.