Chapter 2. Tell Us a Story: Canvas Integration Strategy

Amanda Clossen and Linda Klimczyk*

Before the transition from ANGEL to Canvas, there was already a method in place for embedding library content (namely guides) into the LMS. Unfortunately, this method placed library content in a little-used location. Students simply did not see them. The biggest reach of guides in the LMS was when instructors linked the students to guides directly within course content. While this was an excellent way to create instructor/librarian collaboration, there are many instructors who were unaware of the library’s resources and how these resources could be usefully integrated into their course.

While these problems were obvious to the University Libraries LMS team from the start, it was entirely possible that these issues were not the only ones experienced by our four main user groups: students, instructors, instructional designers, and librarians. In this section, we will explore the methods used in order to strategize our next steps. These methods—a student survey and the collection of user studies—were vital elements in our decisions regarding library integrations.

Student Survey

In the spring of 2016, a Penn State Qualtrics Survey was sent out to seventy-three students who had taken the course COMM 190: Gaming and Interactive Media. This course was piloting the Canvas LMS before its university-wide implementation. Students were asked a series of questions, some left open-ended in order to include nuance in our results. In order to gather responses, the instructor gave all the students who completed the survey extra credit.

These institution-specific survey questions were as follows:

1. Do you know what a course guide is?
2. Have you ever used subject guides or course guides for a class project?
3. If so, what class was this for? List all that apply.
4. Have you ever accessed a subject/course guide via Angel or Canvas?
5. How often do you use the course guides?
6. How much does it influence work in the course?
7. How are you interacting with guides when a librarian does not prompt you?
8. Have you used course guides on your own when they are available to you?
9. How have your teachers/classmates been using the library through Angel?
10. How does this influence work in the course?
11. Do you want the course guides to be included in a future Learning Management System (LMS) like Canvas?
12. Where would you expect to see options to access course guides on Angel/Canvas?
13. How do you decide if a source is valid (accurate, current, trustworthy)?
14. How much do you want included on Canvas itself as opposed to through links?
15. How are you finding information for projects right now?

Perhaps the most reassuring and affirming piece of information from this survey was the response to question 11: Do you want the course guides to be included in a future Learning Management System (LMS) like Canvas? Eighty-eight percent of students wanted guides to be included in their future LMS. This response included thirty-five students who had never used guides before, yet recognized their usefulness in the process of taking the survey.

General findings included: 53 percent of students did not know what a course guide was; 41 percent of students had used a guide for a class project; 60 percent accessed a course guide via the LMS; and 37 percent of students used course guides on their own.

When students were asked how their instructors or classmates used library resources, a large percentage said that they were not instructed in guide use by their instructors, or if they had been, it was for a single course and not in others. How they were introduced to library content also varied. Some instructors guided them through the process of locating the guides within ANGEL itself. Others had simply linked to the guide in the lessons area of the course.

Responses to the question of where guides should be accessed revealed mixed results. However, the largest number of students suggested that the guides be located on the sidebar as a navigation item. This was a huge step up from the organization in ANGEL, which had the libraries’ resources in a difficult-to-find location that required two clicks to reach. In the free response section of this question, some version of the statement “it has to be visible” was repeated over and over. Complaints were made about the inaccessibility of the information in ANGEL. Many students said they might use guides if they knew where they were and realized why and how they should use them.

Students preferred including as much content as possible within Canvas itself, as opposed to through links to other resources. In the free responses, students expressed both an unwillingness to leave the LMS and also a great desire for the LMS to remain “uncluttered.” Those who did not want to see guides in Canvas often said that it was because it would be too messy, or too crowded. This affects not only where the guides are integrated, but also what content is put on the guides themselves and how it is included.

Actions

As a result of the student survey, several clear requirements for the Canvas LMS integrations rose to the top. Guides specifically had been seen as useful and should be included in future integrations. It was important that the guides were in a visible place, but not a place that overwhelmed the course content. It was strongly suggested that the guides go into the left-hand navigation. Minor improvements to guide design were suggested. Since students often did not know what a course guide was, obvious titles and descriptive intros were encouraged.

A less technical element was also observed, that being that students were most motivated to interact with the guides if someone directed them to their existence. Responses were split between that someone being an instructor or a librarian; however, in both cases, the student needed a gentle nudge toward the guide. Instructors will introduce students to guides only if they are aware of their existence, as well as if they are convinced that such a tool can be useful. If such an item is implemented automatically (which was the avenue we chose at Penn State), it opens up an excellent avenue for librarians to communicate with instructors on the tools that can be included in their course.

User Stories

Working with several technologies and distinctly different user groups, the University Libraries LMS team needed a method to document requirements and to communicate them across audiences. The libraries have adopted the Agile framework for managing development projects (and more). The Agile framework is a set of values and principles—not processes or tools—intended as an alternative to traditional documentation-driven, linear methods, allowing greater flexibility and responsiveness to user needs.1 We borrowed one technique in particular, user stories, as a method to further define user needs from various points of view.

A user story is a tool in Agile methodology that can work for many types of requirements gathering. They are “short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.”2

User stories follow the format:

As a [role] I want [requirement] so that [end result desired].

For example:

As an instructional designer, I want an easy and reliable way to embed the library into courses so that changes in the library databases don’t break links in my course.

As a student, I want to find everything that I need for my course in one place so that I don’t miss anything.

User stories are used to paint a clear picture of the actual use cases of a product or service for each target audience. They are clear statements, constructed in plain language (without jargon), that bring needs into focus and reveal similarities and differences between user groups to the product owner and team.

The product owner, another role borrowed from Agile, serves as the primary stakeholder who prioritizes work and has the final say in requirements and acceptance criteria of the deliverables.3 Another responsibility of the product owner is to group user stories into groups, often called epics. These are sets of features and functions that interrelate together as the deliverable.4

In an Agile development environment, the development team designs software to meet the objective and requirements of the user story. Developers are not constrained by any particular development method as long as the deliverable meets the objective laid out in the user story. Stakeholders do not have to understand the technology in order to set requirements. This division of labor between what to do and how to do it brings the team to a middle ground of communication and understanding around the product, allowing each person to capitalize on their own type of expertise.

In Penn State’s example, the library team was made up of both technical and nontechnical personnel who also interacted closely with the Penn State Canvas technical team and the Springshare technical team. Additionally, the library team worked closely with stakeholders and consumers of library services.

These groups had very different levels of knowledge on what the library does and can provide. Whether the difference was technical/nontechnical or library/non-library, common understanding was limited between groups, but user stories proved to be a successful bridge to communicate needs and requirements across everyone involved.5 They also provided a way to keep the project focused and on track. The organization of user stories into epics provided a nice visual of where we were going and where we were at any given time.

Our goal of user stories was to figure out how we could leverage the opportunities of the changing technologies to maximize value to students and instructors.

• Could a new LMS enable assignment-level links to reserve reading assignments?
• Could the new LMS enable embedded content from LibGuides?
• Could we use new technologies to automatically provide topical links between library resources and courses?
• Could we resolve the philosophical difference of bringing users to the library tools and website versus bringing library resources to the users? What experience did users really want?
• Could the LibGuides content and references in Canvas/LMS be customized to help pull students in and encourage use?

We leveraged the energy of the team members, the opportunity to work with a cross-functional team, as well as the possibilities that new technologies bring to define our problem statements: What do students care about? What do instructional designers and faculty want? And what do librarians want to share?

We began by focusing on the gap between what librarians think users want and what users state that they want. We embarked on parallel studies: a student survey, as mentioned in the first section of this chapter, interviews with ID shops, and user story development with stakeholder groups.

Execution

Several user story meetings were held with the following constituent groups: library employees, instructional designers from the college of Information Science and Technology, and the project team.

These meetings were conducted with a facilitator who encouraged participation and recorded user stories in a table in Microsoft Word. This was done on a large screen display of a three-column table with the following headers:

As a . . .

I want . . .

So that I can . . .

The facilitator recorded user stories in real time throughout the session. Participants built on each other’s ideas to further define stories or to write new ones. The facilitator had the opportunity to clarify in the moment if anything was ambiguous. The participants were vocal, and pain points were quickly pointed out as well as wish lists.

Often the pain points were not directly related to the project. We recorded them regardless. Later, we were able to use these to inform other projects. One example was the need for a URL generator for linking to licensed database resources using our proxy prefix. This was a small project that fulfilled a large need that might not have been discovered had we not been gathering stakeholder input.

It became clear that even our instructional designers and instructors weren’t always aware of what the library can and does provide. For instance, some didn’t know about guides at all. We utilized the opportunity of our user story meetings to provide some “what if’s” to seed discussion. An outgrowth of this work was an opportunity for librarians to penetrate the Learning Design network and to provide deeper information sessions on what libraries provide and points of collaboration. This resulted in additional user stories.

Results and Analysis

The analysis of user stories along with survey results shaped requirements of the project. The major requirements were to provide seamless access to library resources within the course for everyone involved in the course, including the instructor, designer, TA, learner, and librarian. The resources had to be easy to find and require little work on the part of course designers to implement. The bulk of the integration and content provision had to fall on the libraries. We couldn’t overlook what librarians wanted, either, which was ease of use, automation, and a presence in Penn State courses.

Unlike guides, course reserves were familiar to almost all of our constituent groups. There was a common and strong need conveyed that reserves have to be easier to request for a course, to create in a course, and to use from within a course. Our WorldCampus team had developed code to pull a list of reserves from our Symphony reserves system. Instructional designers and instructors, frustrated with the complexity of creating reserve reading lists and incorporating them into the LMS, increasingly provided their own direct links or took a chance on copyright by scanning articles and embedding the PDFs in their courses. These issues created an additional line of focus for our team.

Decisions

With the timely release of its LTI, Springshare provided us with a solution for the integration of our guides, which included easy access, little work on the part of the instructor, and simple integrations for librarians. We were also able to make improvements to reserves based on these user stories by implementing Springshare E-Reserves and Document Management. The implementation of this LTI will be covered in the following chapter, and the integration of both guides and reserves will be addressed in chapters of their own.

Notes

1. Agile Development (blog), Agileinsights website, accessed March 23, 2018, https://agileinsights.word
   press.com/tag/agile-development/.
2. Margaret Rouse, “What Is User Story?—Definition from WhatIs.com,” SearchSoftwareQuality, TechTarget, accessed March 23, 2018, http://searchsoft
   warequality.techtarget.com/definition/user-story.
3. Mike Cohn, “Scrum Product Owner: The Agile Product Owner’s Role,” Mountain Goat Software, accessed March 23, 2018, https://www.mountaingoatsoftware
   .com/agile/scrum/roles/product-owner.
4. Jeremy Jarrell, “Stories versus Themes versus Epics: Navigating the Waters,” Scrum Alliance, March
   13, 2014, https://www.scrumalliance.org/community/articles/2014/march/stories-versus-themes-versus-epics.
5. Theresa Torres, “User Stories Are Better Than PRDs,” Product Talk, April 24, 2012, https://www.producttalk.org/2012/04/user-stories-are-better-than-prds/.

---