Usability testing of faculty as well as historical support requests show that faculty do not understand the distinction that Atlas Systems has created between "Adding a new class" and "Cloning a class." Often, faculty choose to Add a new class rather than clone a class, and then find themselves too late with an empty class. This results either in faculty manually adding all of the items they meant to copy over to the new class, creating yet another new class through cloning, or calling Course Reserves staff to intervene and move the items over.
Testing and prototyping show that inserting a little friction into the course adding process can help direct faculty to the best way to get their new course created. This code adds a modal window to the "Add a new class" action that pulls up to the most recent 3 courses the instructor has created in course reserves (if they have used the service before) and offers to opportunity to create a new class "from scratch" or clone one of the three selected courses.
- Introduce the technical difference between cloning a course and adding a new course without making the faculty understand the database structures or staff workflow of Ares.
- Reduce support calls from faculty, as well as ghost courses
- Does not include a handler function to remap the "Add New Course" button to the modal window. Based on the current architecture, it may need two such functions, one for if past courses are added, one for if only current courses are added.
- Replace the technical term "cloning" with a more appropriate term. User research would need to talk to many faculty to get a better understanding of how they understand this action. Ares has baked in the concept of "cloning" so thoroughly as a staff concept yet it has leaked through to the public user interface.
- Test microcopy to improve the ability to communicate the difference between these two actions. For instance, non-native English speakers may not understand "from scratch."