NB: This is the third post in a series on what we learned in our Fall 2017 Blueprint Course pilot. The previous posts provide an overview of our experience (Lessons Learned about Blueprint Courses: Introduction) and address how we got buy-in from teaching teams and administrative stakeholders for our target courses (Lessons Learned about Blueprint Courses: Getting Buy-In), and a later post discusses replacing a course copy workflow with Blueprint (Lessons Learned about Blueprint Courses: Replacing Course Copy Workflows).
Perhaps not surprisingly, Blueprint Courses (Canvas Release: Blueprint Courses) turn out not to be the right solution for every large-enrollment, multi-section course. In this blog post, I'll talk about the "failed" Blueprint pilot course, where the teaching and admin teams decided not to continue using Blueprint.
In the first post in this series, I described one of our pilot Blueprint courses like this:
MGEC 611 -- a half-term core MBA course with four faculty members each teaching three sections, a small army of TAs, and several support staff. Previously, this course had a single Canvas site (with all 12 sections!) in order to maintain consistency. Some of the faculty, however, wanted to customize the content for their assignments and course materials. We selected Blueprint to provide the teaching team with a common starting point, the ability to keep content in sync (if they chose not to modify their Canvas sites), and the ability to customize content if they chose. This Blueprint course has four associated Canvas courses, each with three sections (more than 800 students in total).
The second half of this course (MGEC 612) is offered in Q2, again with 12 sections taught by a slightly different set of faculty, and with basically the entire MBA class (about 850 or so students).
The teaching and admin teams agreed to use Blueprint during the Q1 course, and we all had the expectation that we'd also use it for the Q2 course (MGEC 612). All the upfront planning and communications included faculty who would be teaching in Q1 and Q2. (Again, I can't stress strongly enough how helpful Ken Black's post on Tips for Designing and Maintaining Blueprint Courses is for this kind of planning, especially his sections "Plan, Plan, Plan" and on deciding whether to lock items.) But in the end, they chose NOT to use Blueprint in Q2 -- and this says a lot more about their evolving understanding of their course needs then it does about the tool.
These course were challenging for our Courseware Team to set up. (Our team creates Canvas site and populates them with assignments for our teaching teams as part of our standard site setup process.):
See the (C3) after what appears to be a duplicate assignment? One faculty member (responsible for "Cluster 3") wanted to be able to modify assignments for the sections he teaches. So each assignment has multiple sections assigned to it with multiple due dates. This makes it hard at a glance to see if we got everything right.
So this level of complexity across all the assignments, twice each fall for these quarter-term courses.
When we approached the admin coordinator about trying Blueprint for this course, we used many of the reasons discussed in Lessons Learned about Blueprint Courses: Getting Buy-In -- so please check out that post for discussions of each of these benefits. The key selling points for this course were:
The combination of these features provided the central functionality that the course required -- the ability to have a common starting point for everyone (with the ability to update that content in a single place, just one), combined with the ability for faculty members to change that content if they chose. And not have those changes overridden. The way that Blueprint handles synced changes for unlocked content fit the bill. (See How do I sync course content in a blueprint course as an instructor? )
We created a Blueprint template site, along with four associated Canvas sites -- one for each "cluster" of three sections taught by one of four faculty members.
Configuring the Blueprint site was remarkably straight-forward: We left everything unlocked (How do I lock course objects in a blueprint course as an instructor? - this, we didn't do any of this), which provided faculty with control over what they wanted students to see and what content should be in the assignments, files, and other content. So, they could use the content from the Blueprint as a starting point, but were not required to use it.
Setting up section-differentiated assignments was faster and easier with only three sections (instead of 12!), and there was much less concern about accidental errors.
Our Courseware Team created the template from the shared syllabus and worked with the teaching team to determine who should have access to the Blueprint site and each of the associated cluster sites. In the end, they decided everyone should have access to everything: all five faculty members (teaching in either Q1 or Q2) and eight TAs (two assigned to each cluster) were enrolled in all five sites (the Blueprint template, plus four associated "cluster" sites).
We spent a while talking through the logistics of how the Files areas should be set up and what (if any) files should be uploaded to the Blueprint template. And ultimately, the faculty members realized that they wanted to upload their own versions of the slide decks for each class meeting, so the template provided a file folder structure but only minimal shared files.
By moving to four Canvas sites (one for each faculty member's section) instead of one, the primary functionality that they lost was giving students access to a shared discussion board. After investigating options, we installed Piazza as a course-level LTI tool, and then paired each Canvas site to the same shared Piazza board. This gave all 800+ students a centralized place to discuss course content, problem sets, ask and answer questions, etc.
Most of the Blueprint worked as expected:
Though we haven't (yet) surveyed the teaching teams using Blueprint this semester, we have a pretty good idea of what didn't work.
In the end, the teaching team realized that what they needed was simply an initial shared starting point, and that they didn't really need the ability to keep content, assignments, files, etc. in sync. Faculty members appreciated the ability to make changes and updates, as well as having complete control over the files and class recordings. So for the Q2 course, they dropped Blueprint and we simply copied the course content from one site to the next -- and this eliminated the extra administrative overhead that comes with Blueprint.
We still count this as a win, though: This teaching team would not have arrived at their current configuration without first trying Blueprint. Blueprint ended up being a way to ease them into having separate Canvas sites.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Linda is a the Director of Instructional Design on the Courseware Team at Wharton Computing. She holds advanced degrees in Folklore from the University of California, Berkeley, and the University of Pennsylvania. In addition to helping faculty use Canvas and related technologies, she teaches on-campus and online folklore courses at Penn.