This is a case where we needed to develop a solution to a complex interaction and information challenge that had kept us from landing several high-profile customers and supporting some of our most prolific users. This is how we came to understand the problem, both from a sales and user experience perspective, and how we designed a solution that we believe makes a complex activity as transparent and straightforward as possible.
Background: Teachers and the Reuse of Content
One of the many things we didn’t fully understand when designing the earliest versions of Eli Review was the degree to which teachers reuse content. While everyone on our team has an extensive background in teaching, none of us had anticipated the need of teachers to reuse content in the same course or across courses.
Our earliest attempt to support teachers reusing content was to create a “repository” feature that made it possible for them to browse tasks they’d created in previous courses and “load” them into the current course, with the opportunity to edit and revise that task as needed before assigning it to students.
Teachers responded positively to the ability to load previous tasks from their repository, but the feature didn’t go far enough for many users. Instructors who had invested significant time developing tasks and wanted to reuse all of those tasks in a new course still had to load them into the new course a task at a time for each new course, which proved especially problematic when that instructors had multiple sections of the same course. Likewise, writing program administrators responsible for overseeing dozens of teachers teaching the same course were faced with the dilemma of creating each of those sections and populating each one with tasks one at a time. While individual instructors were frustrated most stuck with us, but we lost many administrators (and their thousands of students) because managing content was too difficult.
Obviously, we could do more to support teachers and administrators who needed to reuse content on a large scale. We set about designing a solution for them in June 2018.
User Stories and Project Scope
Before jumping into UI and requirements, I worked with our team and our users to develop stories for this new feature:
- As an instructor, I wants to make an exact copy of a course I’ve taught before. I don’t want to spend the time it would take to create a new shell course and load each of my old tasks into it individually. With a “clone course” feature, I want to create a new course and have it contain copies of all of the tasks from the previous course ready to use.
- As an administrator, I want to make multiple copies of the same course for each instructor in my program. The courses must all have the same set of tasks copied from the original course, but I need to be able to customize each clone (i.e. title, dates, co-instructors) for the individual instructors the copies are made for and be able to do that quickly.
Having a firm grasp of the user stories allowed me to begin assembling detailed requirements for the course cloning project (pdf). The requirements outlined all of the changes to the system needed to support cloning, from new fields needed in the database to specific changes to the user interface to a detailed workflow for the cloning process.
While the process for creating a copy of a course was straightforward (courses are just a single record in the module) table, creating clones of the individual tasks is quite complex, which is the main reason we hadn’t built the feature sooner. Tasks can be individual records themselves but there can also be substantial interdependency between them, not to mention mundane but still complicated work of calculating new due dates for each cloned task.
The requirements document ended up being a source of dialogue between myself, our director of professional development, and our developer. It was here where we were able to hash out the complex process of recreating each task, its dependencies on other tasks, and preparing all of the new metadata it would need to fit into a clone properly.
The complicated work of course cloning was primarily behind the scenes as we figured out the logic for creating cloned tasks. From the user’s perspective, there was almost no change to the app’s user interface.
- Database updates: we added cloned_parent_id fields to the module table as well as each individual task to make it easy to identify parent objects when necessary
- Course homepage: we added a “Clone This Course” link added to eligible courses
- Single clone: when creating a single clone, the cloning screen consists of only four fields, making it quick and easy to create a clone
- Customize multiple clones: this feature makes it relatively easy for instructors and administrators to create clones in batches while being able to tweak the metadata for each course as needed (titles, start/end dates, instructors, etc)
- Multiple clone report: once an instructor or an admin has created a batch of clones, Eli will prepare a downloadable report with each course name, instructor, and access code, making it much easier to share and distribute access info to students as needed.
Note also that the “load from repository” feature for reusing one-off tasks still exists alongside the option to clone an entire course. This is still helpful when instructors only need to reuse a single task; they can do that using “load from repository” with just a couple of clicks.
Before and After
The only notable change this project required for the existing user interface was the addition of the “Clone This Course” option to the instructor course homepage. This option only appears for eligible courses. There are a few disqualifiers for rare use cases.
Cloning a course comes in two flavors. The first, and the one assumed by default, is creating a single clone. When clicking “Clone This Course”, the instructor is first given the option to create a single clone.
From here, the instructor or administrator can customize the metadata for the new course (title, dates, institution, etc) and they can add co-instructors as needed. However, if they choose any number but one from the “Number of clones” dropdown, they’ll have the option to customize that many clones.
When creating multiple clones, the instructor or administrator can still customize the name, section, start dates, and co-instructors of each clone, making them as distinct as necessary while all having the same tasks as the parent course.
Outcomes / Takeaways
The final feature, once put through testing and QA, came out relatively seamlessly. It behaved as users expected and they took to it quickly, particularly folks who’d been waiting for years for the ability to replicate an entire course and its content with a single click.
After several weeks of using the final cloning feature, we’ve already heard new ideas from users about how they’d like to see the feature grow:
- Cloned courses have a lot of content; find a better way to differentiate between draft tasks and tasks assigned to students
- Develop a new UI that will allow instructors to adjust due dates in bulk
- Add an option to remove the person creating the clone from the course (instead of being added as an instructor by default)
We also have long-term ambitions for adding Creative Commons style licenses to courses so that instructors could find courses created by other instructors, all pre-loaded with usable content, and create clones of their own. This would make essentially Open Educational Resources available inside Eli for instructors to discover and use as they see fit.