35
Views
0
CrossRef citations to date
0
Altmetric
Case Report

Creating a Homemade Mobile Augmented Reality Game in a Community College Library: An Open Source Approach

ORCID Icon & ORCID Icon

Abstract

Librarians at Kingsborough Community College created a mobile augmented reality activity for new students, to orient them to the library space and to provide a fun, welcoming experience. Rather than use a commercial app, the librarians built the activity using open source tools and resources already at-hand, specifically AR.js and A-Frame (both JavaScript ­libraries), and LibGuides. Based on student feedback, librarians found that participants enjoyed the activity and that it helped familiarize them with library locations and services. This project demonstrates that librarians have the capacity to build their own open source augmented reality activities in-house.

In the summer of 2023, librarians at Kingsborough Community College (KCC) took on the challenge of creating an Augmented Reality (AR) activity. AR, an interactive technology in which users experience digital content overlaid on their physical environment (Azuma, Citation1997; Craig, Citation2013; Tang, Citation2021), is a popular tool for learning. The idea for this project came about when KCC librarians decided to create a new library outreach activity and began exploring gamification, or “the use of game design elements in non-game contexts” (Deterding et al., Citation2011). Gamified activities include game elements like solving problems, scoring points, or earning rewards, and they are popular on many digital platforms. Gamification is believed to increase learning, by motivating students with the prospect of earning prizes and by providing opportunities for social interaction (Deliyannis et al., Citation2023; Deterding et al., Citation2011). A digital gamified activity was appealing because many KCC students are digital natives: they are highly skilled at using digital technology, which they began using at an early age (Bennett, Citation2012; Prensky, Citation2001). While researching potential activities, the librarians became intrigued by the growing trend of using AR as a tool to engage students in academic libraries. It was in this spirit of exploration that KCC librarians decided to create a self-guided library tour using AR for the start of the Fall 2023 semester.

As this case study will describe, KCC library decided to create a home-built, open source solution, rather than use a commercial application. An open source solution fit nicely within the library’s budget and values. From a technical perspective, an open source approach offered a different path forward than the commercial AR solutions most commonly described in the literature. Although there is a notable learning curve to this approach, this paper will suggest that such a solution is a viable alternative for librarians with at least modest JavaScript programming skills.

During this process, KCC librarians faced certain limitations. While there was enthusiasm for engaging with AR, the medium was brand new to the library. As a public community college library, there was no budget for the activity, nor were there a large number of technically-skilled librarians or programmers with time to devote to the project. Creating the activity required the librarians to use resources they already had at hand, as well as those that were freely available. Additionally, the project was under time constraints, as the librarians intended to debut the activity in under two months’ time. Despite the constraints, the librarians eagerly took up the challenge of working in a new medium as a learning opportunity.

Using the fiscal and technical resources available, the programming skills of the Web Librarian, and some time dedicated to planning and experimentation, KCC library successfully created an AR activity that launched in the Fall 2023 semester. This case study will describe the process by which the KCC librarians created a homemade AR application; the game-play “flow” that the librarians used to run the game and welcome students to the library; and what was learned during application development. To the authors’ knowledge, the approach described below—building an AR game in-house using open source JavaScript libraries—is a novel contribution to the literature of librarianship. This paper will trace the development of the KCC library AR project and will describe its largely positive reception by the student community.

Literature review

At the outset of the AR game’s development, the librarians wanted to create an outreach activity that provided a fun experience and gave students a positive early impression of the KCC library. The librarians are aware that students often feel uncomfortable using the library. Students’ anxiety about academic libraries is a topic that has received sustained attention in the scholarly literature for decades. In 1986, Constance Mellon’s seminal paper on “library anxiety” found that 75–85% of surveyed students described their first reactions to the library in terms of anxiety and fear (Mellon, Citation1986, p. 163). Following this influential publication, many further studies have been published on library anxiety in college students and on their perceptions of using the library (Carlile, Citation2007; Halpern, Citation2016; Jiao et al., Citation1996; Lee, Citation2012). Brinkman et al. (Citation2013) note library anxiety among first-generation college students, a group to which many KCC students belong. The literature on library anxiety motivated the KCC librarians to create an activity that introduced the library as a friendly, welcoming space.

Outreach programming is an important means by which librarians attempt to make students feel welcome (Buehler, Citation2020). In this context, digital gamified activities offer interesting new ways to engage students (Kang, Citation2015; Tang, Citation2021). Moreover, KCC librarians have anecdotally found that Gen Z and Millennial students are often adept at learning new applications, and that they often take to such initiatives enthusiastically. There appears to be a natural fit between many students’ interest in digital games and librarians’ desire to orient students to the library.

Augmented Reality (AR) is an exciting way to structure digital games. AR is a medium in which digital information is superimposed on the physical world (Azuma, Citation1997; Craig, Citation2013; Tang, Citation2021). AR is different from virtual reality, which is a fully simulated, immersive three-dimensional virtual environment, or “the computer-created counterpart to actual reality” (Varnum, Citation2019, p. x). By contrast, AR “is enhanced reality, usually in a limited way. The user is perceiving the real world, but the computer is adding objects, information or details that are not physically present” (Varnum, Citation2019, p. ix). AR is interactive; for example, a user can activate the technology by scanning objects in their physical space (Craig, Citation2013; Herskovitz et al., Citation2020).

Mobile augmented reality (MAR) is a growing subset of AR (Adhani & Rambli, Citation2012). MAR is AR technology that is activated by mobile devices, such as smartphones or smart tablets (Craig, Citation2013). One of the key advantages of MAR is that users can use their own mobile devices to initiate the technology, so MAR is considerably more affordable to deploy than more permanent AR technologies that require costly equipment. Another advantage is that MAR can be employed in a wide variety of settings which allows for greater numbers of learning opportunities. Some have related MAR to “ubiquitous learning,” in which learning can occur in any environment, at any time, through the aid of mobile technologies and wireless networks (Cao et al., Citation2023; Craig, Citation2013; Kinshuk & Graf, Citation2012; Vallejo-Correa et al., Citation2021). For over a decade, MAR has been used in educational games and applications for groups ranging from elementary school to higher education students, as well as informal learners (Laine, Citation2018; Nincarean et al., Citation2013; Schmalstieg & Wagner, Citation2007).

Perhaps unsurprisingly, academic libraries have been using AR (frequently, MAR) to enhance their services for years. MAR has commonly been used in outreach activities, such as library tours, scavenger hunts, or wayfinding maps. MAR outreach activities can be fun ways to engage new students (or those unfamiliar with the library), while also implicitly encouraging them to use the library going forward. Some goals for MAR activities—as described by other academic libraries in the literature—include: integrating AR technology into orientations; familiarizing students with the locations in the library; increasing awareness of library services; making students feel welcome; building feelings of self-efficacy and confidence in using the library; and demonstrating how to retrieve books and other resources (Hornick & Wade, Citation2018; Kannegiser, Citation2021a; Citation2021b; LaBrake & Deptula, Citation2018; LeMire et al., Citation2018; Santos & Esposo-Betan, Citation2017; Smith & Hottinger, Citation2018; Tang, Citation2021). KCC librarians adopted some of these goals for their project, as discussed below. In most of the aforementioned studies, students responded positively to using MAR. For example, at Berkeley College Library, LaBrake and Deptula (Citation2018) report that students enjoyed the new experience of trying out AR technology and also appreciated using their smartphones in school activities.

Few articles have assessed the impact of MAR on students’ library anxiety and their level of comfort using academic libraries. In one such study, librarians at Rutgers University-Camden Library conducted different library orientations—a traditional scavenger hunt and a MAR scavenger hunt—with two groups of first year undergraduate students. Students’ perceptions of the library were captured in pre- and post-evaluation surveys. The surveys found that both orientations led to an increase in positive feelings about using the library. However, the MAR orientation led to a greater increase in students’ perceptions that library workers wanted to help them (Kannegiser, Citation2021a; Citation2021b). Hopefully, future studies will continue to assess the effectiveness of MAR as a tool for reducing library anxiety.

Libraries also face many cultural and organizational limitations with their new technology projects. For example, Al-Fadhli et al. (Citation2016) clearly point to the cultural situatedness of library technology initiatives. One important take-away from their study is that the ultimate success of a library technology project is very culturally dependent. Clark and Lischer-Katz (Citation2023) go a step further to point out the specific structural limitations of contemporary academic institutions that hinder the deployment of effective library technology projects. They question the utility of many popular software adoption and development strategies in the library context. In contrast, Costello (Citation2018) emphasizes the value of some of these very same methods. Ultimately, Costello pragmatically adapts techniques for the specific needs of libraries, suggesting a situational compromise that stands in contrast to Clark and Lischer-Katz’s critical perspectives. The KCC librarians’ approach to building an AR game tended to cleave more closely to Costello’s framework, as they sought pragmatic ways to adopt development strategies to their specific library situation. Ultimately, cognizance of the institutional limitations and of the specific cultural situatedness of the AR project played an important part in the project’s success.

One significant, common technological failure in AR, identified by Clark and Lischer-Katz (Citation2023) and Herskovitz et al. (Citation2020), is the lack of accessibility for users. Many popular AR applications lack accessibility features, such as those that could assist users with visual, auditory, or cognitive disabilities. AR is chiefly a visual medium; it adds virtual images to the real world. For users with visual disabilities, using the technology can present significant challenges (Herskovitz et al., Citation2020). To accommodate diverse learning styles, some libraries have created accessibility workarounds (Kannegiser, Citation2021a; Citation2021b; LeMire et al., Citation2018), but unfortunately, accessible versions of activities are not often fully equivalent to the AR games they seek to replicate. Hopefully, progress will be made in making AR more accessible. This remains an underexplored topic in the scholarship; there is certainly an opportunity for further scholarly consideration of accessibility in AR.

Materials and methodology

KCC librarians began preparations for the AR activity by convening a planning committee. (The Web Librarian served as the game developer; other committee members collaborated on creating the game flow, testing the game, and other tasks.) The committee’s first task was to create objectives for developing the activity. The objectives were to create an AR game that oriented students to key locations in the library, and that could be completed successfully using a mobile device. The librarians conceived of creating a self-guided tour that new students could participate in at their convenience, either during the college’s New Student Orientation or when visiting the library between classes.

Once objectives were established, the discussion pivoted to the means of creating the activity. As described in the literature, many libraries use proprietary AR apps in library outreach activities (Hornick & Wade, Citation2018; Kannegiser, Citation2021a; Citation2021b; LaBrake & Deptula, Citation2018; LeMire et al., Citation2018; Santos & Esposo-Betan, Citation2017; Smith & Hottinger, Citation2018; Tang, Citation2021). Apps cited in the literature include Aurasma (later named HP Reveal,) (Citation2024), Zappar (Citation2024), Gamar (Citation2024), and Metaverse (Citation2024). One advantage of apps is that they give librarians the ability to create an AR activity even if they do not possess programming skills. Some allow embedding of content such as videos or audio. While some apps are free, others are subscription-based. There are also disadvantages to using apps, most notably that their rules of service may change (Santos & Esposo-Betan, Citation2017), or that they may eventually be discontinued, essentially leaving their customers without a platform (for example, HP Reveal was discontinued in 2020; Metaverse was discontinued in Citation2024). Another downside is that participation in the AR activity is contingent on users downloading a new app on their mobile devices. Tang (Citation2021) describes that some students declined to download an app on their phones due to limited storage. Also, Smith and Hottinger (Citation2018) report that some students were unable to download an app due to the library’s poor wifi signal. These issues were significant concerns for the KCC librarians.

As an alternative to commercial apps, it is also possible to build an AR activity using free, open source tools. This open source approach was a compelling choice for this activity for several reasons:

  1. Building the activity with open source tools provided an opportunity for the librarians to grow their skill sets. While building this game pushed the JavaScript knowledge of the Web Librarian, who programmed the game, it also brought new technologies into conversations around reference, outreach, and teaching in the department. This was a net benefit to the library.

  2. Secondly, building the game in-house had important technical advantages. Specifically, wifi in the Kingsborough library is notoriously slow and unreliable, and students likely would have had difficulty using a commercial app that requires a consistent wifi connection. By not relying on a third-party app, it was possible to build a browser-based activity that would be minimally dependent on wifi. A browser-based approach, frequently called “Web AR,” allowed for development to take place exclusively in standard web technologies (HTML, CSS, and JavaScript). As Hussein et al. explain, “web augmented reality is inherently considered platform independent, no pre-installation is required, easy to apply, easy to access, and easy to develop” (Hussein et al., Citation2023). Qiao et al. (Citation2019) detail some of the bandwidth advantages of Web AR. A Web AR approach allows the programmer to decide for themselves how much they want to rely on wifi. In the end, the Kingsborough library game only required wifi briefly during the initial page load and not at all during game play. Once loaded, the game runs on the client side, in the browser and does not make any network calls. The entire game is loaded in memory at the outset, meaning that there is no need for a wifi connection to load additional assets – or to provide geo-location – during game play. This is largely possible because of the affordances of JavaScript-based Web AR technologies, which are intended to run in the browser. This meant that students could roam around the library while playing the game without having to worry about their wifi connections. They also did not have to worry about downloading an app.

  3. Lastly, an open source solution proved to be more customizable than many apps. While there are limits to what one can do with many commercial AR applications, a homemade application is (in theory) a blank slate. There are certainly upsides and downsides to this. These will be considered in the following section.

Technical review

AR.js and A-Frame

The Web Librarian built the game using a JavaScript library called AR.js (Citation2024). AR.js uses a framework called A-Frame under the hood, which powers the visual interactivity of the library tour application. AR.js powers the augmented reality aspects of the game. AR.js is responsible for recognizing markers (i.e., the physical objects that trigger the AR experiences) and displaying the corresponding shapes within the real-world library space. On the other hand, A-Frame is “a web framework for building 3D/AR/VR experiences” (A-Frame, Citation2023). A-Frame creates virtual shapes, styles them, and allows the programmer to work with them in JavaScript. AR.js and A-Frame are both open source. Together, these two technologies make the KCC library’s AR tour game playable. The librarians chose these AR libraries primarily because they were popular and well-supported, which would facilitate development. On top of these technologies, the Web Librarian built a user interface (buttons and menus), as well as the logic that keeps track of the user’s progress through the game, in A-Frame. This user interface is discussed below, in the “Making it Happen” section.

For a bit of context, AR.js was originally built by a developer named Jerome Etienne (https://github.com/jeromeetienne) in 2017. Indeed, the period of initial development in 2017 was the most intensive period of its development, with the project often receiving more than 20 commits (contributions) per week. The project subsequently passed through other hands, namely a programmer named Nicolò Carpignoli (https://github.com/nicolocarpignoli), from 2018–2020 before finally being given its own GitHub group (https://github.com/AR-js-org) to coordinate its development in 2020. Somewhat ironically, this institutionalization of the project as a GitHub group coincided with a dramatic slowdown of development activity, with very few contributions added after April 2023.

A-Frame allows the programmer to define a “scene” in their HTML. The scene is a container for the various markers that define the game. Practically speaking, the scene is an HTML element, where markers are defined as child elements. These HTML markers correspond to physical markers: the physical markers are square 3 × 3 black and white grids, similar to very low-resolution QR codes. KCC librarians printed these physical markers in high contrast on regular 8.5” x 11” paper and posted them to walls, bookshelves, desks (and so on) around the library ().

Figure 1. A 3x3 marker.

Figure 1. A 3x3 marker.

In this way, by defining markers both in the code and in the physical space, KCC librarians established the locations that make up the library tour. Eight markers were used altogether, which correspond to eight different locations. (The librarians selected this particular number largely due to the fact that eight markers were included in the default 3 × 3 marker set; however, they also felt this was a good number of locations to ask students to find in the game.) When players scan the physical markers, this triggers the virtual shapes to appear on their smartphones.

When creating the game, the Web Librarian defined the virtual shapes by further customizing the A-Frame elements in the HTML. The shapes are child elements of the markers. One can modify the shapes by picking different colors and geometry; defining the rotational speed and direction of the object; choosing its size; and so on. Some JavaScript triggers the three-dimensional shape to appear when a physical marker is found. In this way, the game’s players interact with these shapes as they walk around the space. Custom markers, sprites, or more complex shapes are in theory possible, but the librarians struggled to make them work in practice because of limitations of LibGuides, where they hosted this project.

The A-Frame scene is associated with a corresponding component. Components are a popular JavaScript paradigm, whereby related code is grouped together by its functionality.Footnote1 Because of this component-based design, A-Frame could be used in much the same way that one might use a reactive JavaScript framework (such as Vue.js, React, or others) to build a simple website. Indeed, the Web Librarian’s previous experiences building websites with Vue.js were very pertinent for understanding the mechanics of A-Frame. Programmers with knowledge of modern JavaScript frameworks will find this to be familiar territory.

The result is that this AR activity’s game logic was written with A-Frame, but also with fairly standard JavaScript concepts such as components, event listeners, methods, and functions. This JavaScript logic makes the game “playable,” so that as the player finds shapes in the library space, they get checked off as complete. The code, which is structured within the A-Frame framework, keeps a tally of which markers the player has found. When they find all of them, they “win” the game.

LibGuides

As previously mentioned, the AR activity was run on LibGuides, on what is known as a “group homepage.” This feature is available with a LibGuides Content Management System (CMS) subscription. To the KCC librarians’ knowledge, Augmented Reality is not a typical or intended use of LibGuides. Nonetheless, it is the content management system for KCC library, and it made sense to work with the resources on hand. The insight that prompted this strategy was that the template for a LibGuides group homepage can be emptied of all boilerplate content (JavaScript, CSS, and HTML), and that it can then be used as a blank slate to build a Web AR project. This worked effectively for the game, despite being a somewhat improvised solution. Indeed, because the AR game is entirely front-end code and consists only of static files, it does not need a more sophisticated setup to run. Essentially, the librarians are using LibGuides CMS group like a web server. This approach means that the infrastructure and related dependencies that keep the game online are managed by Springshare, the company that runs LibGuides CMS, which helpfully freed up the librarians’ time and attention to focus on the building of the game. In this respect, the librarians found that LibGuides was an adequate, if unlikely, platform for building an AR game. While they did occasionally chafe at some of the limitations of the platform, such as limits on file sizes and file types, they nonetheless found its affordances to be mostly suitable for developing the game. The code for KCC Library’s AR game is available on GitHub (Eaton, Citation2024).

An assortment of technical problems

Quite unsurprisingly, the librarians encountered a number of problems in their initial testing phase that they needed to overcome to make the game functional:

  1. The librarians found that the markers did not work very well unless they were printed with very high contrast. The black/white contrast produced by their typical office inkjet printer was not adequate for use in the game. For a time, one colleague printed the markers with his photo-quality home printer, which was a passable solution but a bit of an imposition on his time and printer ink budget. The librarians later found that copying the markers on the library’s photocopier with the maximum possible contrast also produced suitably good results.

  2. The librarians also had issues with the resolution of the markers. Players’ phones would sometimes misinterpret random shapes around the library as being 3x3 markers, as these are rather simple, common patterns. These false positives would allow the player to skip ahead in the game without actually finding the marker in question. As a solution, the librarians instead tried using 4x4 markers, which were much more unique and which produced no false positives. Unfortunately, they produced some false negatives. This was in fact worse, because a false negative would mean that the player could get stuck at a marker that they could not scan. The librarians felt this could prove very frustrating to students, so they decided that it was unworkable. False positives were a preferable option, so they ultimately decided to continue with the 3x3 markers.

  3. Lastly, the librarians found that AR.js would not always identify the correct camera when loading the game. Most modern phones have multiple cameras; indeed, most of them have more than one outward-facing camera. If AR.js picked the wrong one, the participant would experience (for example) a hyper zoomed-in visual field, which was totally unsuitable for finding markers. Fortunately, this was not a common problem; it occurred on ∼5% of phones. When a participant’s phone proved unusable for this (or other) reasons, the librarians had them team up with a classmate and share a phone, or use a library-provided tablet, to play the game. As one might expect, the multiple-cameras problem has received a lot of attention in the GitHub issues for the AR.js project, but to the best of the authors’ knowledge, a workable solution has not been found. The librarians decided to accept and mitigate this problem as best they could in order to make the game playable.

Takeaways from this technical review

Colonna (Citation2023) helpfully does a further systematic technical analysis on some of the shortcomings and strengths of AR.js that will be of interest to more technical readers of this paper. Despite the recent lack of development activity, KCC librarians feel that AR.js remains a feasible platform for library AR projects. It is helpfully free and open source, has a manageable learning curve for someone with JavaScript programming skills, and for the most part is usable both for game players and developers. While next-generation, improved open-source libraries could make this space better, AR.js is a good library for this purpose today.

Making it happen: development and workflow

The development process

The development of the code for this project was set in motion when the Web Librarian showed his colleagues an example of a virtual red cube floating in the library’s physical space, made with a very simple AR.js setup. This generated some excitement among the librarians about the possibilities of AR, and they spent some time learning about various competing Web AR projects. AR.js was ultimately selected for its robustness, popularity, open source license, and depth of help in online communities such as GitHub and StackOverflow. A-Frame was selected as a consequence of using AR.js, as they are meant to be used together. Using these tools, the Web Librarian created markers and shapes and then set up JavaScript event listeners to capture when the virtual shapes were found with a smartphone. He brought this progress back to the planning committee for feedback. Virtual shapes were set up around the library, while the Web Librarian created a user interface in JavaScript so that participants could play the game. This interface was entirely written in the A-Frame framework. With this in place, the game was playable, and testing could begin. The librarians first recruited their colleagues to try out the AR game and iterated on the feedback they provided. Once the game was working fairly well, the testing was expanded to students, and the activity was underway.

Workflows for running the game

To more carefully define how the activity would be run, the librarians developed a projected “flow” that guided us in deploying the game. In the proposed flow, two librarians are on hand at the Reference Desk to invite students to participate and help them start the AR activity. An incentive is offered: students will earn a rice krispy treat and/or candy for completing the activity. The game proceeds as follows:

  • To start the game, students scan a QR code with their camera phone which brings them to the LibGuides site, and a “Welcome” screen appears. Their phone will likely prompt them to enable their phone’s camera. Once they do so, they can start playing the game ().

Figure 2. The welcome screen for the game.

Figure 2. The welcome screen for the game.
  • Students then walk around the library and find the markers hung at different locations, triggering the virtual shapes. The first marker is helpfully located close at hand at the Reference Desk, so students can easily find it and start the game ().

Figure 3. An example of a virtual shape found by locating one of the markers.

Figure 3. An example of a virtual shape found by locating one of the markers.
  • Throughout the activity, students can click on a “Check Your Progress” button, and a drop-down list of library locations will appear. As each marker is scanned, another location is automatically checked off the list ().

Figure 4. A view of the game with the “Check Your Progress” menu open.

Figure 4. A view of the game with the “Check Your Progress” menu open.
  • Upon finding all of the markers, a “Congratulations!” screen appears. Then, students can claim their reward (and receive much praise) from the librarians ().

Figure 5. The “Congratulations” screen.

Figure 5. The “Congratulations” screen.

The librarians decided to limit the marker locations to the second floor, where almost all service points and student-centered amenities—including the Reference Desk, Circulation, computers and printers, leisure book collection, and private study rooms—are located. This limited the physical scope of the game and made it more playable. The Reference Desk was selected as the natural starting point for the tour, as it’s staffed by faculty librarians who could assist with the activity.

When creating the activity, the librarians worked under the assumption that the majority of students would use their own smartphones. However, concerns were raised about the possibility that some students might not have phones, or that a student could have a phone that was incompatible with the activity. As a solution, a librarian who served on the planning committee kindly donated a tablet that could be kept at the reference desk for any students who needed a device.

The librarians also created a supplementary paper checklist of the library locations featured in the game. This was intended as an accessibility aid for any students who might have difficulties playing the game. Some librarians were concerned that students could have challenges using the dropdown checklist in the browser-based activity. The supplementary checklist could then serve as a support tool to assist with playing the game, or students could simply take the tour using the paper checklist and receive the same incentive for their efforts. The paper checklist also provided some brief information on each library location, a potentially useful addition. However, librarians observed that in the actual running of the game, students quickly adapted to the phone-based activity without difficulty and mostly ignored the paper checklist.

Data collection

Due to the short turn-around time for the game’s development and the small team of librarians involved, it was not feasible to develop formal methods for capturing data on the activity’s objectives within the intended timeframes. Instead, the librarians used a convenience sample. This approach involved more informal methods of data collection, such as observing students playing the game and gathering brief, qualitative feedback from students about their experiences. This information was recorded in a Google document. While this data collection is very limited, using informal data collection methods allowed the librarians to prioritize their time on developing and testing the game to ensure it would be ready for the start of the semester. The librarians also decided that informal methods of data collection would be sufficient for determining whether the fairly simple objectives for the game were met, which will be further described below.

Results

Initial beta-testing for the AR activity took place in the first week of the fall semester, during two afternoon reference shifts when the library had steady foot traffic. To promote the activity, the librarians hung flyers in the library and shared them on social media. Two librarians at the Reference Desk actively promoted the activity to students in the vicinity. However, students often appeared busy, and librarians sometimes found it difficult to convince them to play the game. Over the course of two shifts, 12 students successfully completed the activity. Additionally, a similar number of students started the game but didn’t finish it. Nearly all of the students who did not complete the activity were from a class that serendipitously passed by the activity roll-out. At the instructor’s suggestion, the librarians helped the students start the activity; however, the class did not have time to complete the tour.

During the roll-out, librarians found that the game ran smoothly with very few technical difficulties. Slow wifi sometimes led to delays in initially loading the activity on students’ phones. (This caused one student to abandon the activity.) Once the game loaded, it did not need wifi, and there were no problems with the running of the game. Ten of the 12 students used their own phones for the activity; the game worked on all phones. Two students, who didn’t have phones, successfully used the library’s tablet.

Once students started the activity, they were generally able to complete it independently, with little assistance. In keeping with the planned activity “flow,” librarians provided a brief explanation to help students start the game and guided them in finding the first visual marker. Following the introduction, the students quickly acclimated to the activity, and they found and scanned the remaining markers on their own. Librarians observed that the students appeared comfortable using mobile technology. Librarians offered students the supplementary paper checklists; however, they did not observe any students using them. When finished, the students showed the librarians the “Congratulations” screen on their device in order to claim their reward, which allowed the librarians to confirm that they’d successfully completed the game.

Although the participation numbers were low, the students who completed the activity responded positively to it. Librarians solicited students’ verbal feedback, using a convenience sample, asking them about their experience playing the game. The students’ comments were nearly all positive and included that the activity was “fun,” “cool,” “pretty clear,” and “pretty entertaining.” One student reported that the activity had helped him “get to know the library” and that he hadn’t previously realized that there were study rooms available. One student shared constructive feedback, suggesting that the markers be printed on colored paper instead of white so they would be easier to see. Several students articulated that the sweets that the librarians provided were a motivating factor for their participation, which highlighted the need for librarians to incentivize the activity.

While the librarians were pleased with these initial results, the low participation numbers raised the question of whether the game was best-suited as a standalone activity. In the next phase of beta-testing, librarians changed course and facilitated the activity during several introductory-level library instruction sessions. The AR activity was very successful as a class-based activity. The librarians discovered that the students were more engaged with the activity and had higher completion rates. All 34 students, from three library sessions, completed the activity. Student feedback, as recorded by the librarians, was similarly positive. Comments from one class included that: “[the activity] was engaging”; “it was fun - more like a scavenger hunt”; “[the activity] was a good starter for new people”; and “I’ve been a student here for years, and I didn’t know everything in the library.” One student suggested that the game would benefit by including more information about library services. Several faculty instructors also shared positive feedback, expressing appreciation that the library was engaging students with new technology.

Similarly to the first group of beta testers, most students in the second group used their personal smartphones for the activity. In one classroom session, two students were unable to load the game on their phones. Due to the volume of students, the librarian did not have time to provide individualized tech support, so both students completed the activity together using the library’s tablet.

Ultimately, the librarians found that the AR activity worked best as an in-class exercise. Although the AR activity was initially envisioned as an elective, standalone game, it was sometimes difficult to convince busy students to participate. As a class-based activity, the game had very high participation rates. This echoes the findings of other academic libraries. LeMire et al. (Citation2018) found that students had lower participation rates when they were given the AR tour to complete outside of their coursework. Instead, it was more successful when incorporated with a classroom orientation. Likewise, Smith and Hottinger (Citation2018) tested their AR activity in a classroom setting and as a standalone activity, and found that more students dropped out during the standalone activity. Noting the students’ preferences, KCC librarians pivoted to running the AR game as a classroom activity.

Discussion

Meeting the game’s objectives

As described above, at the beginning of the project, the librarians established objectives for the AR activity: to create an AR game that oriented students to key library locations, and that students would be able to successfully complete it using their mobile devices. Although data collection was limited, the librarians felt it was sufficient for assessing these fairly simple objectives. Following the completion of beta-testing, the librarians concluded that the activity was successful in meeting the stated objectives. In accordance with the first objective, the librarians created a game to orient students to important library locations. With little assistance, participating students were able to check off all eight library locations on their drop-down checklist in order to “win” the game. Several students specifically commented that the game made them aware of library locations that were previously unfamiliar to them. Additionally, as per the second objective, the game could be played independently, after a brief introduction, on the students’ mobile devices. The game worked well on nearly all smartphones and tablets. The only real issue was that slow wifi occasionally delayed the initial loading of the game. In addition to meeting these outcomes, students’ reactions to the activity were very largely positive and their comments indicated that they had enjoyed the AR activity. For future iterations of the game, it may be worth considering more formal assessment of the game’s outcomes, such as by having students respond to survey questions.

Software maintainability

The KCC librarians have some hesitations with the software that they chose to build the game. Specifically, JavaScript projects (such as AR.js) tend to become outdated quickly (Ask HN, Citation2022). This compressed lifecycle, which is unfortunately typical of JavaScript, poses problems for academic librarians, who often build with longer time frames in mind. While librarians of course often like the latest and greatest technologies, they are also likely to value long-term maintainability. AR.js has had remarkable longevity in this context. Nonetheless, with the rapid pace of change, librarians need to decide how much they are willing to invest into a particular moment in the fast-changing landscape and decide whether they will maintain that commitment going forward. This chosen level of engagement with the technologies will have a direct impact on the maintainability of a project. The (ultimately very positive) upshot is that the decision to maintain and develop an open source JavaScript project rests mostly in the librarians’ hands, rather than in the hands of a largely unaccountable app maker, who could discontinue their service for any reason.

Future directions

There are a number of possible ways that this project could grow going forward. For example, adding functionality like dialog boxes that ask quiz questions or display interesting facts about the library could make the game more engaging. This is possible thanks to the A-Frame framework, which is certainly powerful enough to accommodate such additions. Nonetheless, adding functionality would require additional planning and coding. Given the data collected, the game in its current form appears to work well as a tool for orienting students who have limited knowledge about using the library. Adding more features could provide a more enriching learning experience. These may be options to explore further in the future.

It would also be useful to capture more metrics about how students are using the game. LibGuides offers limited analytics in general, and at the time of writing, does not capture any pageview data for group homepages. Nonetheless, there is probably more than one way to capture analytics. Google Analytics (GA) could perhaps be used, even in an immersive AR environment. GA could be useful for counting gameplay events, such as participants’ finding markers. However, this is still speculative, as using Google Analytics in this way is still untested by the KCC librarians. Alternately, running the game on a platform where server-side scripting is available could allow the librarians to capture usage data in a meaningful way. Unfortunately, this is not currently available, as LibGuides does not offer this.

Lastly, the AR game is a good stepping stone toward future AR or VR projects. While AR.js might not have a long-term viable future, A-Frame seems very promising. New JavaScript libraries will continue to be developed and will offer new opportunities. These possibilities suggest a bright future for open source AR in JavaScript, so it will be interesting to see what comes next. The KCC librarians look forward to having the opportunity to build with the next generation of browser-based AR tools soon.

Conclusion

KCC librarians initially set out to make an outreach activity that would help orient students to the library. While the AR game was originally conceived as a standalone activity that could be initiated at the reference desk, it ultimately had better adoption—and was more successful—when integrated into library instruction sessions. Nonetheless, in either setting, students responded positively to the game. Based on students’ feedback and their observed success in completing the game, the activity clearly achieved its initial intended outcomes.

Moreover, by using open technologies, the librarians were able to make a project that was in line with the library’s values. Specifically, using openly licensed tools allows this work to be freely shareable and replicable by others in the field. Making the code for this project openly available was important because it could give other librarians the opportunity to adapt, build upon, and improve this project. It is the authors’ sincere hope that other academic libraries take up the challenge of building with open AR, and we look forward to seeing their work.

Lastly, homemade Web AR is an underexplored approach in academic libraries, where most AR initiatives are based on commercial apps. To the authors’ knowledge, this is the first instance in the literature of an academic library building an AR game with AR.js and A-Frame, which makes this case study a unique contribution. Building this game in JavaScript was a useful, constructive exercise for the Kingsborough librarians. Everyone involved in the making of the game learned a lot about game design, about AR specifically, and also some of the excitement and tribulations of building with JavaScript. Building an AR game from scratch is very much possible with a small team of technologically-curious librarians. While having a librarian who is at least somewhat familiar with JavaScript is likely a prerequisite for building an AR game with AR.js, this project demonstrates that a library or library department doesn’t need a professional developer to take on such an initiative. This is a project that can be built by librarians for their libraries. In this respect, the authors believe this is an interesting contribution to the profession.

Supplemental material

Blinded revised manuscript with tracked changes 10_31_24.docx

Download MS Word (73.1 KB)Blinded revised manuscript with tracked changes 10_31_24.docx

Responses_to_comments_10_31_24.docx

Download MS Word (10.2 KB)Responses_to_comments_10_31_24.docx

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

The authors have no funding information to report.

Notes on contributors

Caroline M. Jedlicka

Caroline M. Jedlicka is a Reader Services Librarian and Assistant Professor at Kingsborough Community College, CUNY. She enjoys supporting the Kingsborough community through library outreach, assessment, and instruction.

Mark E. Eaton

Mark E. Eaton is a Reader Services Librarian and Professor at Kingsborough Community College, CUNY. He is responsible for web services and circulation at his college library. He enjoys writing code to support his colleagues and students.

Notes

1 For example, components are common in JavaScript frameworks such as Vue (https://vuejs.org/guide/essentials/component-basics), and React (https://react.dev/learn/your-first-component).

References

Reprints and Corporate Permissions

Please note: Selecting permissions does not provide access to the full text of the article, please see our help page How do I view content?

To request a reprint or corporate permissions for this article, please click on the relevant link below:

Academic Permissions

Please note: Selecting permissions does not provide access to the full text of the article, please see our help page How do I view content?

Obtain permissions instantly via Rightslink by clicking on the button below:

If you are unable to obtain permissions via Rightslink, please complete and submit this Permissions form. For more information, please visit our Permissions help page.