Introduction:
Are you an Oxy student? Does course registration send you spiraling? Has the technology that governs it failed you in the past? If so, you’ve come to the right place!
As an Oxy student myself, I’ve witnessed firsthand the prolonged effects that course registration can have on students, from altered sleep quality and unexpected course difficulty to extreme factors such as increased insecurities about being able to graduate in four years. As such, I believe designing a reliable system is paramount to ensuring a high quality of life for every Oxy student.
In this post, I will assess the quality of the current course registration system through interviews conducted with five Oxy students. Because I am taking a class on Human Computer Interaction this semester, I will do so from a technological and cognitive standpoint, examining the extent at which Oxy’s current online tools meet the needs of my interviewees.
Let’s begin.
Users and Goals:
To maximize the diversity in course registration processes, I chose to interview students of different class years, majors, and technological backgrounds (Computer Science and Economics ’23, Computer Science ’22, Philosophy ’22, Theater and Computer Science ’21, and Diplomacy and World Affairs ’22). Some questions I asked included but were not limited to the following:
What online tools did you use from start to finish to register for your courses?
If you could describe the ideal course registration tool, what features would it have?
What information would you want to be readily available across these tools? To what extent does the current system provide this?
Did you encounter any obstacles along the way throughout your registration process?
Did you get the classes you wanted? If not, do you think Oxy’s online tools were at fault?
Was your overall course registration process positive or negative? Please elaborate why.
After examining their responses, I outlined a list of user requirements that a well-designed course registration system should meet. From there, I categorized every requirement into four types: Information displayed, Quickly accessing information, Planning/prepping for course registration, and User Interface (UI).
Next, let’s discuss each of these types and assess where the current system succeeds and fails at meeting these requirements.
Critique and Suggestions:
Information displayed:
Throughout every interview I conducted, it was clear that there is a fundamental need for a course registration system to have information on the professor, time of day, days of the week, and description of the class for every class that the school offers. Without this information, students would not be able to distinguish one class from the next, making course registration impossible. Oxy’s current system provides all this information on the online tool “Course Counts”, and therefore succeeds in this regard.
However, there are many additional informational needs that the current system simply doesn’t provide. For one, there is no way to determine whether a class will fill up fast. In Oxy’s course registration process, students can only register for two classes on their first round of registration. Once everyone has registered for two classes, then students are able to register for the rest of their classes. Because this, students must guess — or infer via the grapevine — which two classes they should prioritize in the first round in order to enroll in all their desired classes. If students were provided with this information, they could prioritize registering for classes that fill up quickly.
In addition, the current system fails to provide information on the textbooks every class will use and their prices. While this piece of information may seem useless for STEM majors, to the philosophy major I interviewed, it was a deciding factor in choosing his classes. According to him, in majors such as these, the authors you read and what works of literature you digest can have a significant impact on your knowledge of various ideologies. Furthermore, if you’ve only been exposed to a handful of authors, your diversity of thought can be hindered significantly, jeopardizing your educational enrichment.
Alternatively, a separate interviewee noted that textbook costs are a deciding factor for them and their family due to financial reasons. (While each course description in Course Counts has a link to a separate website that tells users the textbooks a class uses, it does not work until the beginning of the next semester, therefore is not useful).
Furthermore, nothing within current system provides information on the difficulty of classes offered (including RateMyProfessor!). As it stands now, the only way to gauge the difficulty of a course is to ask other human beings about it on campus — gross right? While this solution is possible for common, entry-level courses, it becomes significantly less reliable the higher the course level becomes — especially in less popular departments — according to the Junior Theater and Computer Science double major I interviewed. This lack of information could cause a student to enroll in a course load more difficult than they prepared for, thus lowering their GPA.
Lastly, the current system’s online tools fail to explicitly state one’s registration time slot and how that compares to the rest of the student body. While registration time slots are provided during adviser meetings on a physical piece of paper (that is often lost), no additional context for this time slot is given, and students are left unsure how their mock schedules will fare on the day of registration.
Quickly accessing class information:
In addition to a need for ample information about courses, the interviewees expressed an immense desire to be able to access such information quickly. Currently, students are able to retrieve most of the information they need from a multitude of online tools (Google sheets for mock schedules, Oxy.edu’s Courses and Requirements page for major and minor course requirements, Course Counts for creating mock schedules, RateMyProfessor to determine professor quality, etc.) However, it is precisely this abundance of online tools that makes the current system less than optimal. By spreading students across multiple online tools, the amount of attention students can devote at a time is split, reducing the speed at which they can access course information and accelerate their registration process. Thus, the current system’s lack of centrality prevents it from ever satisfying the need for quick access.
Nevertheless, let’s examine it further.
Two primary needs brought up by the interviewees were the option to search for courses by core requirement and by subject. In doing so, students could quickly create lists of classes that satisfy graduation or major requirements, helping them piece together which classes they should enroll in. Because Course Counts has both features, it succeeds in this regard.
… and fails in practically every other regard.
For one, it fails to direct users to information about prerequisite courses in course descriptions on Course Counts.
While it seems logical to simply find the course description on Course Counts, often times, they are not even listed on Course Counts, as shown in the picture below.
As a result, students must navigate to Oxy.edu’s Course Catalog at the bottom of the subject’s Courses and Requirements page and sift through every class until the course is found. This constraint hinders the throughput of the student and draws their attention away from the task at hand: preparing for course registration.
Another need brought up was the ability to navigate directly to a course’s information. While Course Counts offers a way to look up a class by its CRN, a four-digit number, searching for information using numbers does not follow conventions of the search engines that students are exposed to (such as Google). Thus, the current system fails to satisfy this need.
Lastly, there was a strong need for students to only be provided with information on courses that make sense to take. With such a design, only pertinent information would always be displayed to the user, allowing for more meaningful feedback between them and the interface. Because the current system displays information for every course offered in a semester, it fails to allow quick access to class information in this regard.
Planning/Preparation for registering for courses:
A helpful course registration system supports the need to prepare for the narrow window of time allotted for students to add the classes they’d like to take for the semester. More specifically, it should support the process of noting classes of interest, drafting backup schedules, and logging in and adding classes.
From what I gathered in my interviews, the most common practice for constructing a list of interesting classes is to record the number of a course rather than its CRN — isn’t it great how they’re two separate entities? Unlike CRN codes, which allow students to navigate directly to the course yet possess no numerical significance, the hundreds digit of a course number indicates course level, thus sacrificing speed for the sake of semantics. This allows students to quickly examine course details with respect to neighboring courses, gathering context about each of them.
The same cannot be done when compared to examining each course in a vacuum (like in the CRN method).
Furthermore, it’s faster to access multiple classes of interest via a drop-down menu rather than type and enter multiple four-digit numbers into a text box. The irony of a tool created to expedite course search actually having the opposite effect perfectly exemplifies how the CRN system fails to aid users in the construction and maintenance of course lists.
When it comes to drafting backup schedules, the interviewees used either Google sheets or simply sketched schedules with pencil on paper. Because they were all able to organize such schedules visually, albeit through third party tools, the current system succeeds (just barely) in this regard!
… However, in terms of preparing students for logging in and adding classes, the current system fails miserably.
For one, it adds unnecessary complexity, forcing users to log in using a six digit PIN located on a piece of paper that is only distributed during adviser meetings rather than their memorized student ID located in myOxy or their Oxy login credentials (the info used to log in and access the tool used to add or drop classes on registration day). This contradicts the conceptual model that students have for Oxy log-in systems, confusing rather than preparing users during this narrow time slot.
Then, after logging in, students must navigate to the bottom of the page and jot down CRN codes into small text boxes. During this event, feedback is not provided to the student as to whether the classes can be added until after they click the small “Submit Changes” button located next to two other equally sized buttons. This lack of instantaneous feedback can disguise itself as positive feedback at times, leading users to believe that the CRN codes they’ve entered went through successfully.
User Interface:
Within the Oxy course registration ecosystem, there are three online tools that Oxy governs: Course Counts, Add or Drop Classes, and the Courses and Requirements pages in Oxy.edu. Because students spend so much of their time in these tools, there is a vital need for their user interfaces to match students’ conceptual models of proper web page conventions. Otherwise, the time that students should be spending preparing for course registration would be wastefully spent learning the layout of signifiers (interactive things that indicate the existence of an affordance, or action) for each online tool. Starting with Oxy.edu’s Courses and Requirements pages, I will consider the characteristics of each user interface and assess whether this need is met.
Oxy.edu’s Courses and Requirements Page:
This tool is used for finding out which classes are needed to complete a major or minor at Oxy. Because all prerequisite requirements must be met before students can enroll in upper level courses, there is a strong need for hierarchies amongst classes to be made clear. While the layout of a Course and Requirements is different for practically every subject, there is a convention that each page follows: list an overview of what the subject is about, the fundamental courses of the major, the courses required for a concentration (if it exists), any additional major requirements, information about the Second-Stage Writing Requirement, information about the Comprehensive Requirement, information about honors credit, the requirements for a minor, transfer credit policies, and a list of all the courses the subject can offer.
Because the majority of the content within the tool is HTML text, there are not many signifiers to interact with. To indicate when text is hyperlinked, the UI styles it orange and modifies the cursor when a user hovers over it. Because the few signifiers found in this UI all follow common web conventions, there aren’t many conflicts with students’ conceptual models of a web page, allowing them to focus on extracting course information.
Moreover, by listing the required courses needed before listing the upper level courses for both majors and minors, users can naturally establish a hierarchy of prerequisites as they scroll down the web page. To distinguish courses from one another and other surrounding text, they are placed in largely sized tables that can be read from without having to zoom in.
Because these design features promote the ability to establish a hierarchy of classes within the tool, this aspect of the current system’s UI succeeds in its goal.
Course Counts:
The interviewee’s primary use of Course Counts is to generate a list of interesting courses and then extrapolate information regarding those courses to create mock schedules used to add classes on registration day. Because of this, students only use it to look at a hand-full of courses at a time.
Despite this, Course Count’s UI displays information for all courses in a subject within a semester. To do so, it uses small font and button sizes to afford users the ability to sift through multiple courses until finding the one they’re interested in. Furthermore, it maintains small row heights to fit as many classes on the screen as possible. While these design solutions more or less accomplish the same goal as reducing the number of courses students are exposed to, they sacrifice students’ accessibility to signifiers since it takes more time to move to smaller objects. In this regard, the UI fails to allow users to browse a hand-full of classes at a time, and takes time away from the preparative process.
In addition, Course Count’s UI does not properly map certain signifiers to their expected affordances. For example, in the “Major Search” section of the site, the drop-down menus “Catalog” and “Majors” do not afford the action of displaying a list of options, but rather the inoperative affordance “ — select — “.
Furthermore, when the user clicks “Go”, a red error message is produced that remains at the bottom of the screen when the user navigates to other areas of Course Counts. Not only does this mapping of such a signifier to an affordance not follow conventions established by the UI — that is, no other “Go” button on course counts afford such an action — but it misguides and distracts the user from their preparative process throughout the entire tool.
Add or Drop Classes:
The primary use of the Add or Drop Classes tool is to add classes on the day of registration. In this process, students typically have around 20 seconds to log in and add the classes they want to take. Because of this, the UI should expect a user base filled with a sense of urgency and a strong need for a tool to promote efficient usage and fast interaction. This means that signifiers that afford the action of adding classes must be large enough to locate and click and should be in areas disproportionally sized compared to areas that afford less used actions (such as dropping classes).
Which Add or Drop Classes fails to do in an epic fashion.
Rather than place the area where users enter their CRNs and click submit to add their classes at the top of the page, more than a third of the screen is allocated for the school logo, a series of tabs that don’t work, a search bar that the user is given no information how to use, and information that the user already knows. Because none of these regions afford the action of adding or dropping courses, their presence provides unnecessary visual stimuli, thus impeding the need to efficiently add or drop classes.
Instead, the space where users add classes sits below this and the list of courses the student is currently enrolled in. This placement does not abide by the web convention of placing important things at the top of the page (where the user is first brought to when the site loads). As a result, it hinders the speed at which students can locate the signifiers necessary to add classes, harming their need to efficiently add do so.
To make matters worse, there are many design choices within this region that slow down the process further.
For one, the sizes of the signifiers do not coincide with the importance of the affordance they yield. In this section, the need of the users is to enter their CRNs into text boxes and click a “Submit Changes” button to register for them. Nevertheless, the two buttons “Class Search” and “Reset” have an equal to, if not greater than, size compared to these important signifiers. This violates the design convention that size denotes importance, thus forces students to navigate to the proper signifier by brute force, reducing the speed at which they can add courses.
Furthermore, the user is given 10 text boxes to enter in their CRNs, yet will only ever enter 5 max a time and will only enter two the vast majority of the time. This excessiveness provides incorrect feedback to the user on how many courses they can take and creates unnecessary clutter that can overwhelm the user during course registration — two problems that violate students’ need for a tool that allows for efficient and fast usage.
The secondary use of the Add or Drop Classes tool, as you can infer from the title, is to drop classes. Despite this, such a feature is hidden in a drop-down menu in the middle of the screen with no explicit instructions to go to it. This lack of description effectively hides the second most important signifier of the tool from the user, preventing them from accomplishing their most fundamental need: completing course registration.
Summary:
That was a lot to digest!
So what did we learn from this interview? Where does Oxy’s course registration system succeed? Where does it fail?
In terms of success, the current system allows for students to extrapolate basic course information, search for courses by core requirement and subject, and use third-party tools to create mock schedules. Furthermore, Oxy.edu’s Course and Requirements page uses a UI that allowing students to naturally establish hierarchies of courses.
That’s where it ends.
In terms of failure, the current system falls short in many ways. Regarding information displayed, it doesn’t provide information on how fast a class will fill up, the textbooks every class will use and their prices, class difficulty, registration time slots and how they compare to the rest of the student body.
With respect to quickly displaying information, it fails to provide a central platform for users to go to, direct users to information about prerequisite courses in course descriptions on Course Counts, allow students to navigate directly to a course’s information, and only provide information on courses that make sense to take.
As for planning/preparing users for course registration, it fails to aid users in the development of course lists, maintain simplicity during the log in process on registration day, and provide feedback to students when adding classes.
Lastly, concerning the user interfaces of the Course Counts, and Add or Drop Classes’ pages, the current system fails to maximize the amount of time students have in the preparative process and allow them to efficiently log in and add courses.
But why is this bad? Why are these needs that a course registration system should adhere to?
While many needs were specified within each of these categories, they all stem from the basic need: to be able to enroll in courses that best fit users’ interests and career goals.
While deciding these courses usually boils down to a series of educated guesses; the more educated the guess, the better the outcome will be. With regard to the categories students’ needs fell into, maximizing the amount of information displayed (Information displayed) coupled with a system that prioritizes information extraction (Quickly accessing information) and use efficiency (UI) allows for students to educate themselves on courses offered. Furthermore, allowing the user to sufficiently prepare for registration day (Planning/preparation for course registration) allows them to maintain a standard for their excitement in future courses.
If you haven’t already inferred from the title, the current system’s inability to satisfy these four categories fails to meet the basic need of the students, making it bad.
