Course Registration System: Final Report

Course Registration System: Final Report CPSC 671 CHI 1 May 2011 Problem Statement

Recently, most major universities have moved from phone-based registration systems to web-based systems that allow students to search and register for courses. As more universities follow this trend and begin to only offer online registration, it will become increasingly important for these systems to be considered usable by all students. In addition to the system being usable, it must also provide the student with convenient access to information that will ease the course scheduling process.

The idea for the project was mostly motivated by the online registration system offered by Texas A&M. It seems unacceptable that such a large school would have a system that offers such a low level of flexibility and lacks functionality to make the process easier for the students. Combining our knowledge of other course registration systems, we came up with a list of features that are important to an online course registration system.

Between the two of us we had experiences with a number of course registration systems, each of them had their strengths, but none of them encompassed all the necessary functionality in a reasonable way. The following examples a demonstrate some of the most common weaknesses. Most of the systems did not include enough information about the courses. For example, Texas A&M’s system did not allow the user to see the course description, the user would have to navigate another area of the school’s website to access this information. When registering, it would be helpful to have all of this information in the same place. Some systems did not allow for flexible searches. This includes the systems that only allowed searches based on one field, such as department. With some systems it was inconvenient to view the classes a student was already registered for. With Georgia Tech’s system, the student was not able to view their classes from the search page. They had to navigate back to another area of the webpage to view this information. The system for University of San Diego did not provide any way for visualizing the courses the student had registered; it only showed a list of the courses ordered by department.

Using the weaknesses from existing systems, we decided a useful system would have the following characteristics. Searching for a course should be as flexible as possible to allow the student to either find a specific course or a group of possible courses to consider. All information about the courses should be available from the search results page. The student should be able to view their registered courses from anywhere in the course registration system, and the courses should be displayed in a way that provides the student with all useful information.

Design of Initial Prototype

Prior to developing a functional prototype, we mocked our system using a static html representation of our ideas. To guide the design of this first prototype we conducted a brief informal user study. This was done by asking a few people we know about the registration systems they had used. The systems evaluated for this user study were limited to the systems from Texas A&M, Georgia Tech, and the University of San Diego. We asked questions about what they thought were the good and bad things about their current registration systems, if they thought any tasks were particularly difficult with their system, and if there was anything they would like to be able to do that they can’t. The participants were also asked to assess various aspects of the systems using Likert scales. Based on their responses, the most liked system was the USD’s. However, the system still only had an average of 3.5 on a scale of 1-5. The lowest rated system was TAMU’s, but it wasn’t too far below the 2.5 average of all the systems.

One participant complained that their system did not allow them to see a conflict between courses until after they tried to add it to their schedule. Another complained they did not want to see classes that were full, or otherwise restricted, listed on a search results page if they couldn’t register for them. Most of the complaints were about the search capabilities of the systems. One person thought their system did not allow them to enter enough information, and felt overwhelmed by the number of courses their searches returned. Another thought they should be able to search based on any of the course information.

After asking the participants to evaluate their current systems, we asked them to evaluate one of our ideas for adding functionality to the system. The idea was to allow the user to click on a course they were thinking about registering for and show them whether or not the course would fit in their schedule. To present this idea we drew up a paper prototype of how this information would be displayed to the user. The idea was the user would see a list of the classes they were registered for, and the class that caused the conflict would be highlighted in red to show this. The feedback we received on this feature showed that the users felt it would be helpful to see this information, but the textual indication was not enough of a visual cue.

Initial Prototype

Using the information gathered in the informal user study, we designed the static prototype to attempt to solve the problems brought up by the participants. We changed the representation of a course conflict from a list of classes with one highlighted to a graphical representation of a student’s schedule that used colors to represent registered classes, the class to check, and whether or not there was a conflict. We felt this visualization should be available to the student in several places, so the students are provided with a link to their schedule from any page, and they can click on a class from the search results page to see it drawn into their schedule. This solves the problem of not being able to see conflicts soon enough.

The search page for the static prototype was basically a compilation of every search field that had been available across the three systems evaluated. It seemed like each person we talked to about their system liked something about the way they could search for courses, so we felt the best way to achieve a flexible search mechanism would be to allow them to search on all fields of the course’s information.

Evaluation of Initial Prototype To evaluate the initial prototype, we used a group of five participants and asked them to carry out various tasks using the static system. We wanted to use a diverse group of participants to evaluate whether the system would be accessible to various types of students. Our group included a student above the average college age group, graduate students, and undergraduate students.

The user study was structured as a task-oriented evaluation of our system. We asked the participants to go through the actions of searching for a specific course they wanted to register, searching for a group of courses that matched a certain criteria where they weren’t sure which course to register, checking a course for conflicts, adding a course, deleting a course, and viewing their schedule.

The participants felt most of the tasks were trivial and could be easily completed using our system. However, several of the participants did mention they were confused by the search function because there were so many available fields and they weren’t sure which ones they should use. One of them mentioned they felt obligated to fill in each field when searching for a course since there was an area to enter the information. The feedback for the schedule visualization was positive. One participant said it was helpful to be able to see the classes in a view that showed what their week would look like with all the classes in place. They also mentioned that this feature might help them think more about how they schedule blocks of classes and this might help them avoid scheduling too many classes on one day.

Design of Functional Prototype

The user studies indicated a few main issues that we wanted to address. We felt that these issues were the key ones and tried to use our previous prototype and evaluation to inform the design of our functional prototype. The main issues implicated from the users were schedule visualization, search flexibility, search complexity, and early visibility of information.

The schedule visualization was appreciated by users as soon as we even asked questions about the idea. Some systems, such as Georgia Tech, have HTML-based visualizations but they aren’t closely tied to the registration system and do not give previews of how new classes make the schedule look. We put the visualizations into the registration process and tried to make appreciating information about the schedule you were putting together as simple as possible. The visualizations were put into two places. First, we added them to the schedule view page along with text descriptions, where you were forwarded after adding or dropping a class. They were also added to the course details page where you could preview a course in your schedule.

Search flexibility was something that we initially thought was missing from A&M’s current system. This was confirmed by our users but conflicted in our second user study with interest in the search complexity being lower. We decided not to go with a basic search and an advanced one because the search domain was so constrained and well known. Instead, we opted to cut down on fields that may not be commonly used, give good default behaviors when a particular search feature is not used, and still have several fields that advanced users could use effectively.

The concept of early visibility of information is something that a few users mentioned and we had though of initially. Essentially, why should the system not tell you as soon as it can that a particular class is full, closed, or will not fit inside your schedule? Another possibility was that you did not have the necessary prerequisites but that was outside the scope of our project. Several existing systems have this type of flaw and we attempted to eliminate it from our system by presenting this type of information as soon as the user saw any information about a particular class.

Functional Prototype

We chose to use the space and tools that CSG provides students in the department with to create the functional prototype. This meant we were limited in selecting our tools, but had easy and free access to them. We chose to use the MySQL RDBMS and PHP5 to implement things with since we both had some experience with them. After designing a simple database schema for the objects that would require persistence in the system, we created a PHP5 class that did object-relational mapping in the style of Martin Fowler’s ActiveRecord design pattern from his book, Patterns of Enterprise Application Architecture. The only available library to use for the graphics was PHP’s GD library. We used this to generate JPEG images for the schedule visualization from the database on the fly. Each page was created roughly in the style of Martin Fowler’s PageController design pattern. The users simply see web pages of HTML and CSS.

Evaluation of Functional Prototype

We did not have ample time at this stage of the project to perform a stringent qualitative or quantitative user study. We did present the URL for the project to some of our past subjects and ask for feedback on the proposed improvements. The feedback we did receive was positive overall, but suggested that we had more work to do. Mainly, the users wanted a more full fledged prototype that was robust and had all the data for their school’s scheduling. Again, that was something that we did not feel warranted the time necessary to put it in the project but is something that would need further examination if the project were to go forward.

Lessons Learned

In the course of designing and building a replacement to the course registration system at Texas A&M, we discovered that it was not as easy a task as we might have thought. There are tradeoffs in many of the design decisions that we did not think worked well in the current system. We do feel that we presented a prototype that had real improvements over the current system, however. We also discovered in our final evaluation, that our system could stand its own set of improvements. Finally, we learned a few things about how to go about such a project in the future. Feedback

Feedback is a very elegant principle that Norman made famous in his book, Design of Everyday Things. We got overwhelming and constant interest in more feedback from users. Current systems simply do not give the users the kind of feedback that is really important to them. They are interested in their schedule and how all the pieces fit together. A visualization of this information was our solution to giving users more feedback, but we may not have gone far enough. On the search results page for courses, we indicate the courses that are schedule conflicts or full, but do not give a visualization of the schedule with that course unless you click on it. Some of our feedback indicates that a thumbnail version of the information or an AJAX/details-on-demand visualization would have been beneficial.

Simplicity & Flexibility

These lessons are paired because they conflicted with each other. The design should be simple and guide the users without instruction. The system should allow for advanced users to have more options and extra features. These essentially represent the biggest tradeoff that we dealt with in designing the system. None of the users wanted to scroll through forty courses to find the one that they could have searched for faster. However, none of the users appreciated a complex search system that overwhelmed them with options and confused them with what they did and did not have to fill in to search. Many sites deal with this by having a separate page for advanced users where they can use the many options without the confusion. We felt that the search problem was limited enough in scope that we should be able to create a middle ground that was acceptable. Our prototypes seesawed between these options and settled somewhere near the middle. The user feedback for our final functional prototype was positive, but this area of the design is subtle and complex and should probably receive more attention.

Start Early

This seems blindingly obvious and was something we talked about several times. It was just hard to execute on the principle. We did get several early meetings and talks in, but had a drought in between that and really getting the project rolling. If we could start over, we would have made a much bigger push early on. More things could have been tried and worked on. We might have had another iteration of design and we could shorten the list of things we had to leave out due to time constraints.

Scheduling

Scheduling is related to starting early, but not the same thing. We never set strong deadlines or milestones and so some tasks kept getting pushed back. This cost us some functionality in the end. We definitely learned that setting realistic schedule deadlines and holding everyone in the group responsible is an important element in managing a project with so many aspects that depend on each other.