by Mariela Hristova

Introduction

Any content within a course management system (CMS) is generally considered the intellectual space of the faculty member teaching it. Thus, many libraries focus on integrating into the top level of the campus CMSs by creating a library presence in the system and not necessarily in each course. Such an approach has the benefit of serving all students (Lawrence 2006). In fact, a study of faculty and students illustrates that while both groups support a “library tab”, i.e. a generic top level link to the library website, students specifically are more supportive of “librarian-vetted web site lists” (McLure & Munro 2010, p. 38). Students often need help with the use of library tools and resources as those relate to their coursework. Hence, the goal of integrating library tools and resources in campus CMSs is ideally to bring those resources as close to students and course spaces as possible, increasing their ease of use, as well as making their presence immediate and their relevance obvious. Having a search box in the CMS course space to the library’s discovery service, for instance, can offer immediate access to books and articles, rather than expecting students to go to the library website or, more likely, to Google.

At the University of Minnesota – Twin Cities, for instance, librarians have recently developed automatically generated library course pages that are linked in each course within the learning management system (Jeffryes et al. 2011), allowing for consistent access to library tools and resources for students from all classes, with individual guide customization still being an option. They achieve broad relevance of the library course pages by going beyond coverage of research tools and resources to include “other existing structures (reserves catalog, e-reserves) into a new, more holistic, system” (Jeffryes et al. 2011, p. 26). This type of integration combines the pervasiveness of system-level library presence with the immediacy of having course-specific resources embedded within the learning space at the course level. It is, however, made possible by a “robust database-driven system of resources” (Jeffryes et al. 2011, p. 26) – a key factor in their ability to automatically generate guides for all courses that include core resources relevant to each subject or discipline.

At Oakland University, we use an open source application for creating and managing our guides, called SubjectsPlus (www.subjectsplus.com). We see it as a self-hosted alternative to LibGuides that allows us to centrally manage records for our databases and other resources and to create guides at the subject and course level. In adopting SubjectsPlus, we wanted to allow for future integration into the course management system on campus, Moodle. Thus, we decided to create subject guides that correspond to the subject listings in the course catalog and have the URL of each guide explicitly state which course rubrics it corresponds to. For example, we used to have one subject guide for management and marketing, which turned into two separate guides: the Management guide now corresponds to any courses with rubrics of MGT and ORG, while the marketing guide corresponds to courses with a rubric of MKT. The close correspondence of subject-level guides to course rubrics enables course-level integration into Moodle, because all classes that do not have a custom course-level guide can be easily matched with the corresponding subject-level guide. Our new approach to subject guides not only helps with integration into Moodle, but has also helped solve common nomenclature dilemmas, e.g. whether a guide should be called English or Literature was easily solved by deferring to the course catalog that has helped establish student habits and expectations.

In Fall 2011, we recognized that system-level integration into the campus CMS was likely to be a long process. The technical team administering Moodle was spending the academic year preparing for an upgrade to the next version of Moodle; thus, it was out of the question for them to develop custom functionality for a version that was being phased out. We decided to create a library widget for Moodle that can serve as a pilot for the more complete future integration and can help us evaluate the need for, and potential use of, library tools and resources directly from within the CMS course spaces.

Widget Features & Content

We designed the library widget as a PHP-based, self-serve code-generator. Faculty would use the widget interface to select what links to library tools and resources they want to bring into their course space and then paste the resulting HTML code into Moodle. The availability of customizable menu blocks in Moodle provides a convenient place for the HTML code, which does not include any presentational elements and integrates well with any of the available Moodle themes.

By definition, a code-generator would expose users to some code they need to manipulate. One of the main concerns was the ease of use of the interface, because the tool is intended for faculty of any comfort level with technology. The interface builds expectations about the process by having steps listed as tabs and indicating where users are in the process. We also found it important to label each step in a clear and action-oriented manner. As a result the interface includes three sections: Step 1: Select Content, Step 2: Preview & Revise, and Step 3: Paste in Moodle (see Figures 1-3). Additionally, the language on the first page of the interface had to be clear and inviting, so we chose to include brief explanations and to make the multiple choice options as conversational in style as possible. On the last page, we include not just the HTML code for pasting, but also explicit directions on how and where to paste it in Moodle.

In selecting what content options to offer for the library widget, we prioritized content that will be relevant across the disciplines. Library OneSearch – our Summon discovery search – had just been introduced widely on campus. We were de facto starting to use Library OneSearch as the main search tool for most undergraduates by incorporating it in our information literacy instruction and in our interactions at the reference desk. Marketing efforts for Library OneSearch on campus had reached the faculty in multiple ways and the search box was also incorporated prominently both on the front page and in every content page of the library website. Thus, Library OneSearch made a logical first choice for the widget interface, but it still needed a description because the label referred to a branding choice and would not have been sufficient if someone was unfamiliar with the tool.

The library research guides both at the course level and at the subject level provided the impetus for the widget in the first place. Our course-level research guides, known on campus as Library Course Pages, were traditionally getting high web traffic because they were used as presentational tools in our information literacy instruction sessions – librarians would prepare a course page for each class they visited, work from it during the class session, and show students how they can get back to it throughout the semester. About a hundred courses, as well as all sections of freshman composition classes (ranging from about 60 to 100 sections each semester), receive information literacy sessions each semester and have corresponding course pages.

The widget searches through the MySQL database of SubjectsPlus for any guide that has the specified course identifier in its URL, even if the course is cross-listed and has more than one identifier in its URL (e.g. a course called Language and Society is cross-listed with three identifiers: http://research.library.oakland.edu/sp/subjects/guide.php?subject=ALS376/ALS576/SOC376). If a course has multiple sections that are sufficiently different and necessitate different course pages, the interface shows the multiple course pages as choices for the faculty member to select from, i.e. these URLs contain not just the course identifier, but additional section-related information as well. This is a rare situation, but happens occasionally with course rubrics that allow for special topics to be covered in different sections. For example, we have two sections of HST 300: Seminar in Historical Research, so the URLs for each course guide contain faculty names in addition to course identifiers as in http://research.library.oakland.edu/sp/subjects/guide.php?subject=HST300miller. If a course page cannot be located, then the letter portion of the course rubric is used to identify the corresponding discipline and offer a subject-level research guide instead, i.e. the widget delivers the marketing subject guide (http://research.library.oakland.edu/sp/subjects/guide.php?subject=MKT) for any MKT course that does not have a custom course guide.

Finally, electronic course reserves constitute some of our most visited content online based on web traffic data. They consistently rank on par with visits to the list of library databases. Moreover, they represent library-based content that is relevant to many courses that otherwise do not involve conducting research for assignments; the inclusion of course reserves as an option extends the potential usefulness of the widget on campus. The course management system has been found as a natural and effective home for disseminating course reserves information by a number of universities (Black 2008, p. 497). At this time, our course reserves link leads to a standard landing page rather than a course-specific link. A course-specific link would be ideal, but is not currently supported by the reserves workflow or systems, i.e. the print reserves are in the library catalog, while the electronic reserves are kept in a password-protected web area. We do recognize the reserves landing page is a more reliable URL that will work even before faculty have actually placed materials on reserve for their course.

Code-Generator vs. Widget

The development of the library widget as a code-generator rather than a traditional widget has largely determined both its strengths and its weaknesses. The choice between a code-generator interface and a traditional widget influences key features of the tool and should be taken into careful consideration. Table 1 below summarizes the main differences.

If we had conceived our tool as a traditional widget, we would have had to offer code for embedding based on JavaScript, for instance, and store the unique content choices for each widget instance to deliver dynamically into Moodle. The biggest benefit of creating a traditional widget would have been the centralization of its content management, i.e. we would retain control over the content and could change the link URLs or the code for the search box globally for all widget instances in use. The downside of that approach for us related to the need to use even more dynamic content and external resources in Moodle, which would have made the loading of pages even slower than it is currently. Moreover, the content options in the library widget are considerably stable, so losing control over them did not represent a huge risk – it replicated the pre-widget status quo of emailing links to faculty who then would place them somewhere in their Moodle courses. We are hoping to eventually have the library widget integrated into Moodle as custom functionality of the system, thus the current one has a somewhat temporary role to play, which further lowers the risk of decentralizing its content management. The choice might be different if one envisions long term use of the library widget.

As a result of these considerations, we created the library widget as a code-generator. The main benefit of that choice consists in the ease of modifying content selections. Selections are saved within the structure of the code-generator URL through the use of the GET method. This approach allows librarians to go through the code-generator interface and make the appropriate content choices for a course they are visiting, for instance. Then they can email the Step 3 URL to faculty of different levels of comfort with technology, who can either proceed to insert the code in Moodle or make modifications in the content selections without the need for user authentication and the risk that they might be affecting a widget instance that is already in use. This added flexibility has allowed librarians to offer the library widget even to faculty who would have been intimidated by the tool or discouraged by the need to go through several steps. It has also allowed faculty to cycle through the code-generator interface multiple times and make revisions that match each of their courses without creating administrative overhead for the library or contacting us for technical support.

Additionally, we have discovered an unanticipated benefit stemming from the treatment of the library widget as course content in Moodle rather than a Moodle feature to be turned on or off. When faculty teach the same course in subsequent semesters, they usually archive the course content and restore it in the new course space for the current semester. We have encountered numerous faculty informing us they do not need to add the library widget in their current courses, because it is already there from the previous semester. Full Moodle integration in the future might require the activation of the library widget every semester and thus necessitate recurring marketing efforts by the library. In any integration efforts, we believe that it will be imperative to work towards a feature that is activated by default, so faculty are aware of it but have the option to deactivate it.

The main drawback of the widget as a code-generator relates to its limited tracking of usage. Currently, we record each instance of someone getting to the final step of the code-generator interface, where they are presented with the HTML code to insert into Moodle. The data we record includes their content selections and the rubric of their course. We cannot, however, capture directly if they actually have the library widget inserted in Moodle and how much it is being used. Alternate sources of that data are available for the web pages that we host: Google Analytics referral traffic sources capture the number of visits to specific pages that come from the Moodle domain. Having the library widget fully integrated into Moodle might ultimately offer the best tracking opportunity.

Marketing Strategies

Creating awareness of the tool on campus has been done through email and through our instruction sessions. Faculty received direct email twice when it was first created and at the beginning of each semester afterwards. Additionally, subject librarians have emailed faculty in their areas offering various library tools and services, including the widget. The most effective method of raising awareness, however, has anecdotally been the direct communication librarians would have with the faculty when visiting their course to conduct an information literacy session. The end of a class session led by a librarian has proven to be a great time to show the faculty member how the widget can bring the course page that was just used for their class into the Moodle course space. That has also been an opportunity for the librarian to actually help the faculty member paste the code into Moodle if necessary.

Apart from the planned efforts by librarians, a campus committee on teaching and learning invited us to conduct a workshop for faculty on library-related technologies for instruction. The librarians offering the workshop decided to devote half of the workshop time to the widget and received positive comments from the attending faculty. The attendees also had an opportunity for hands-on practice and a number of them used that time to add the widget into their courses.

Adoption Rates

During the first full year since the creation of the library widget, October 2011 – October 2012, it has been used 185 times. Based on our data on content selections, all of the widget instances include Library OneSearch. The widgets also contain 137 links to course-level guides and 48 links to discipline-level guides. The widgets linking to course-level guides span the disciplines, representing 36 unique academic programs on campus. Finally, course reserves are included in 47 of the widgets.

Figure 4 illustrates the distribution of new widget creation over the months of this first year of use. The initial high usage correlates temporally with our marketing efforts. The addition of new widgets over time shows continued interest in the widget, since the figure does not capture all the widgets that faculty carry over through the semesters without having to come back to the interface and make new content selections. We see the steady creation of new widgets as data indicating an increase in adoption either by new faculty or for new courses.

Lessons Learned

One of our biggest concerns in launching the library widget as a code-generator rather than waiting until we can have an integrated Moodle feature was the need for faculty action in order to place the widget in their courses. This less automated approach, however, has focused the launch process on raising awareness across campus to encourage faculty action. Furthermore, faculty seem to have a concrete understanding of what tools they are bringing into their course space due to the content selections they have to make. As a result, the library has been able (1) to illustrate to Moodle administrators what type of a feature we are hoping to integrate into Moodle one day; (2) to illustrate to faculty what value the library tools and content can offer directly within their courses; and (3) to gauge faculty interest in the availability of an integrated Moodle feature. The library has not yet surveyed the campus to have a formal assessment of faculty needs and interest in having this tool integrated into Moodle, but when that survey is conducted, we believe more of the faculty will know from personal experience what value the library widget offers for their courses. Inadvertently, we are learning that an approach involving human action might actually be beneficial in the case of a pilot project like our library widget.

Our experience of developing the widget has informed our understanding of what challenges the future integration into Moodle might present. For example, we had originally assumed that an integrated feature will offer pre-determined content selections, i.e. a menu block with the correct links automatically included for each course. Our development experience and the adoption data, however, support the need for configuration options built into the future Moodle feature. The ability to choose content options might increase the relevance of a library feature to each course, i.e. some courses might need a guide, while others might need a link to course reserves. The occasional, but still very real, existence of multiple courses with the same rubric and number, yet very different thematic content, further indicates that explicit choices by the faculty might prove more useful than a link to a guide that cannot be customized.

The lower than expected inclusion of course reserves in library widgets has surprised us, because we saw course reserves as a means to make the tool relevant to more courses. At the same time, our marketing efforts were focused on the research-related widget content more than reserves. This indicates that perhaps marketing efforts specific to course reserves might be useful, since that content is rather different from the rest of the content options in the widget and might be relevant to a different group of faculty. It is also possible to explore ways to raise awareness of the library widget from within the workflow of putting materials on reserve. We have not yet attempted to integrate the library widget within the reserves clerk’s communications with faculty who are using that service. If sharing the widget at the end of instruction sessions is any indication, we can expect that integration in the reserves workflow might increase adoptions in a similar manner. We plan on analyzing long term trends in our use of reserves first, because the high web traffic might indicate intensive use by a small number of courses.

Finally, tracking of widget usage can provide valuable data in the decision-making process for full integration of library tools into Moodle courses. We found that tracking content selection has been useful and informative, but the overall usage of the widget cannot be verified. Thus, it is critical to base observations of campus support for future integration efforts on a survey or another means of gathering input. The existence of the widget, however, is unique and valuable in that process, because it can clearly illustrate what the library is interested in bringing into the campus CMS, rather than relying on respondents’ prior knowledge of library tools and resources.

Next Steps

We plan on continuing to promote the use of the library widget through our ongoing interactions with faculty. The widget, while not completely automated and integrated in Moodle, does allow faculty to make useful content selections and easily bring library tools and resources into their course spaces. The need for action on the part of faculty imposes a burden on librarians to keep raising awareness of the tool, but it also respects the intellectual control that faculty have over their virtual course spaces. As the use of the widget grows, we plan on surveying faculty to determine their needs for library tools and resources in the CMS. We hope to pursue a full integration with Moodle that is implemented in a manner respectful of faculty ownership of their course spaces.

Meanwhile, we are happy to share the library widget PHP code with anyone interested in using it or customizing it for different contexts. The specifics of each context are likely to be so different as to necessitate significant revisions based both on course management systems and on library guide management systems.

[Zipped code files.]

References

Black EL. 2008. Toolkit approach to integrating library resources into the learning management system. The Journal of Academic Librarianship 34(6):496-501. (COinS)

Jeffryes J, Peterson K, Crowe S, Fine E, Carrillo E. 2011. Integration innovation: Launching the library into a course management system. Journal of Library Innovation 2(1):20-34. (COinS)

Lawrence DH. 2006. Blackboard on a shoe string: Tying courses to sources. Journal of Library Administration 45(1/2):245-265. (COinS)

About the Author

Mariela Hristova is an Assistant Professor and Coordinator of Web Services at Oakland University.