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