Chapter 5. Building a Mobile Device Testing and Development Lab @ the UNT Libraries

William Hicks

Introduction

In the fall of 2013, the User Interfaces Unit of the University of North Texas (UNT) Libraries was awarded funding from the Texas State Library and Archival Commission (TSLAC) with a primary goal to “ensure that Texas libraries had a mobile presence useful to, and used by, their customers.”1 TSLAC identified the purchase, subscription, or updating of mobile websites and library catalogs as potential projects and noted a number of vendors and third parties that could provide these services to institutions with limited resources. As with other university libraries, UNT Libraries has a development team managing our website, catalog, and digital collections, and we felt that we would be capable of crafting solutions that met these goals in-house and that this funding could be used creatively for both internal development and patron enrichment. What we lacked, as do many others, was a robust testing framework for mobile design and development.

Testing web interfaces has always been a constantly moving but imperative target, but more so in recent years as its focus has expanded beyond the desktop to a mobile context where the problems of scale become readily apparent. At least as far back as 2010, developers had noted that “it’s impossible to test your designs on every mobile phone out there. . . . Mobile devices are expensive, and not every web developer can afford to buy five to ten of them. Testing ‘on all mobile phones’ is impossible for most web developers.”2 The same article goes on to outline the browser and device landscape of the day and to posit a strategy that, five years later, remains sound. Today, many developers subscribe to a hosted service that takes “snapshots” of, or virtualizes, mobile devices, uses browser-based web developer tools to emulate the mobile experience, and uses tablets, smartphones, and other related hardware as actual testing and development devices. Even Google recommends this practice as part of its own Web Fundamentals guidelines.3

In this chapter I hope to demonstrate that both our institutional developers and the patrons we support who are (or aspire to be) developers need access to devices and hardware to build new systems and services. While desktop-based tools are essential for rapid software development, certain aspects of mobile design and development can be accounted for only by touching a physical surface or being in a physical space in the real world. This chapter discusses the development of a mobile device lab, a set of tools that provides the library and its patrons physical access to an array of devices that might otherwise be impossible to access. We will cover the rationale for setting up a lab, some of its possible configurations and integrations with other services like library makerspaces, and finally note some of the issues we faced in setting up a lab in the UNT Libraries.

Why a Mobile Device Lab?

Many institutions believe that the population they serve increasingly accesses web content from mobile devices—primarily phones and tablets. A 2013 survey of “Web 2.0” adoption among 100 US academic libraries found that 76 percent of the libraries had some type of mobile presence.4 And while many early adopters build dedicated apps or mobile sites, the clear growing trend both in wider developer circles and in libraries is the adoption of responsive design techniques.5 But most important for this study, having access to a representative sample of the devices that users employ in the real world affords the library and its developers freedom to consider mobile usability, design, and performance that one simply cannot get while sitting at a desk or relying on a vendor’s word. Real-life experiences such as walking through book stacks and looking for a call number can be quite different when you have a pile of books in one arm and a slip of paper and a smartphone, “phablet,” or tablet in the other. Thus, when devices are available to library developers, the developers are able to empathize with the lived experiences of the user who might be looking for a branch’s hours while running out the door, fumbling with complicated search options, or cursing the rendering speed of the page. None of this is particularly easy to emulate while sitting at a workstation with a high-speed connection and a widescreen monitor.

But looking beyond the library’s own needs, as the definition of what a library makes available to the public expands into emerging areas like makerspaces and technology-lending programs, it becomes important to consider how mobile devices and related items fit into this equation for a community’s developers, students, and freelancers. When we consider the overall market penetration of mobile devices, we find increasing household use of both smartphones and tablets, with reports showing national adoption rates of the two devices at two-thirds and one-third of the population, respectively.6 But less clear is the distribution of devices in a household where phones and tablets come from competing manufacturers or have incompatible software ecosystems. And this is of critical importance for any developer with aspirations to penetrate into multiple markets since it is often a personal device that is used for app or website development. If an individual wants to learn how to develop for only a single platform, there may be no problem, but when there is a desire to work in multiple operating systems, across device generations or form factors, or to experiment with new categories of devices, the personal costs become prohibitively expensive rather quickly.

And here, it is important to note that developing for mobile increasingly means thinking about devices and issues other than tablets and smartphones. As we enter into a time where everyday objects are increasingly connected, we need to realize that few individuals or small businesses are able to invest in first-generation products and experimental categories because it is simply too much of a gamble to buy into these platforms. But there are now so many personal data trackers, environmental sensors, remote controlled vehicles, and numerous other “mobile accessories” that are capable of creating and consuming data, or simply letting one learn how to program, that the category is hard to ignore. Most relevant to this study, many of these new classes of devices and services interact with touchscreen devices. Without access to them, many students and low-income individuals have holes in their technical skills as they enter the workforce, and many freelancers lack the tools to allow them to be first-to-market with the next big thing. The same is true of researchers, artists, and other creative individuals—that is, non-programmers—who might find novel uses for these devices but don’t have the tools to build or discover when they can’t afford to be an “explorer.” Libraries, I would submit, are better able than many institutions to level this field and address this very need.

Determining Geographical Need

Having demonstrated the philosophical reasons for providing devices to patrons, it may be helpful to look to other publicly available services for precedence and to judge if there is a need within the community. There is, in fact, a loose-knit group of developers that has created a network of Open Device Labs (ODLs) across the world that seeks to meet this challenge, mostly in western Europe and on the US coasts. Sometimes operating as nonprofits, these labs have grown out of larger tech firms, startups, and a handful of universities, and as of October 2014, according to data obtained through the ODL website’s freely available JSON-based API, there are 133 labs in 31 countries, with 25 located in the United States.7 A more detailed analysis finds that US labs are predominantly located in urban centers and, when correlated to US Census data, it appears that over half are located in areas with populations greater than 250,000, some significantly so (see table 5.1).

Reviewing a sample of ODL websites finds that many labs are open by appointment and that access to their materials are usually reserved through online forms, e-mail, or social media contact. Considering the ubiquity of mobile devices in the consumer market, it seems somewhat surprising then that public access to this type of service is relatively sparse. Libraries around the country, but particularly those in the Central and southern United States, would be well positioned to offer their community’s developers access to mobile devices based purely on geography. Similarly, the regularity of open hours common to most public and academic libraries would provide a greater degree of scheduling flexibility for patrons of all types than many existing ODLs offer, even if only a small number of devices are offered.

Getting Started

At the heart of the device lab, whether offered as a public service, internal development resource, or both, is the selection of devices and services offered. Looking once more at data provided by the ODL website’s API, we find that labs are making over 3,700 devices available from more than sixty manufacturers and that the median number of devices at existing labs is fifteen with only five labs having more than 100 devices.8

A survey of ODL websites finds that most labs appear to focus on providing patrons with smartphones and tablets, with some also offering access to Chromebooks, televisions and gaming equipment, e-readers, and other media players. Several note the availability of Google Glass and Oculus Rift, but no information about other related items, such as documentation, prototyping tools, usability-testing resources, or spaces, could be found. At UNT, we were able to acquire twelve smartphones and tablets in addition to several other related electronic devices for several thousand dollars, a tiny fraction of what our parent institution spends on journals, books, and other more traditional items in the collections.

When deciding how to outfit a lab, a number of variables will go into the decision-making and acquisition process, and as we found at UNT, there may be more than a few unexpected issues that pop up along the way. We found that documenting the project in Microsoft Word, Outlook, and Excel was adequate for most of our needs, but suggest tools that allow for brainstorming, something that can account for estimated and real costs, log communications with both vendors and buyers in the organization, and allow regular review of websites that evaluate, compare, or discuss devices and other relevant technology news.

Financing and Accessorizing the Lab

Budgetary considerations will be one of the first and most obvious areas to address, and two specific points outside the initial investment should be considered early on: what continuing investment the institution is willing to make and whether it is worth seeking outside donations to build the collection. UNT’s lab was largely built with subsidized funding, with new items purchased using a regular budget line. Our review of individual ODL websites revealed that many appeal to their users for support, crediting those sources online, but outside of a single seed-source for most of their acquisitions, it appears many labs meet with limited success. As we were setting up the lab, we appealed to library staff, donors, and patrons through several of the library’s e-mail newsletters. We thought the advantage of a large community and factors common within libraries—sharing culture, tax-advantage giving, and environmentally or socially aware users—would lead to gifts of older devices collecting dust in a drawer. We ultimately didn’t receive a single donation. While the hope is that a more sustained giving campaign in the future might yield better results, realistically, grant-based and internal funding sources will likely fare better.

Once funding sources are in order, purchasing a wide range of devices and accessories can begin. Smartphones and tablets will be readily available from a number of vendors and most can be purchased without data plans, though often at a higher-than-advertised, unsubsidized price. We found that typically the cost of devices was lower for older devices and those that weren’t currently in high demand, though this was not always the case. Beyond devices, we purchased books and other documentation related to mobile development; cases for security, travel, and circulation; and power strips for handling multi-device charging; as well as stencil kits, notepads, and drafting equipment that were designed to paper-prototype mobile interfaces. Because we were concurrently setting up a makerspace and felt that there would be some overlap in scope and use, we invested in other equipment such as a Google Glass, Bluetooth-low-energy Beacons, and littleBits electronics to allow patrons access to the Internet of Things and wearable technologies. Other technology items a library might consider will largely depend on its audience, use, and need. Cameras and eye-tracking devices can be acquired to record usability tests of web interfaces and other library services with users, and can be dual purposed at academic libraries serving programs that study human behavior. Similarly, smartphone-controlled “toys” and robotics can be employed as part of the STEM/STEAM programs of the library or its parent institution. It largely comes down to the size and scope of the lab and its targeted audience. As an existing web development unit, we already had access to relevant software and a subscription to a mobile device virtualization service, but an allowance for new software and apps may be necessary for some labs. Finally, when building a public lab, consideration will also need to be given to the time it takes to develop new circulation policies and procedures, particularly as they relate to fees resulting from lost or damaged items and cataloging items appropriately, as well as devoting some attention to a physical space, verifying adequate Wi-Fi coverage, and providing dedicated workstations or laptops and any other items, devices, or services that fit into the scope of the lab.

Selecting Devices

It is imperative to take time to learn which devices are being used by the library’s patrons and make purchases that are representative of the audience. The easiest and most cost-effective way to do this is to use tracking software like Google Analytics, which offers various reporting features on devices, screen resolutions, operating system, network, and so on. Because the UNT Libraries operates a number of different websites, including several digital collections with global audiences, we found some variability but found the overwhelming amount of our US mobile traffic originating from Apple and Android devices, with smaller numbers from Windows, Blackberry, Nokia, and others. If a review of website analytics isn’t possible, consider consulting wider market trends or survey library users through other means, such as at public service desks or online surveys.

While acquiring popular models of phones and tablets can be a relatively straightforward process, there are a number of factors worth considering that maximize purchasing power and utility. Because many people purchase phones through subsidized carrier plans and upgrade on a multiyear cycle or are locked into a manufacturer’s ecosystem of products, it may be worth considering where in the manufacturer’s generational cycle a device is before making a purchase. As an example, we found significant traffic from both the Samsung Galaxy S3 and S4 smartphones to our websites and opted to buy the latter device based in part on the logic that more people would be upgrading out of the older model. While this approach seems intuitive on its face, we found that it may not always be the right one.

Figure 5.1 demonstrates monthly usage patterns of the two devices on one of our digital collections sites as reported by Google Analytics. While the older model enjoys higher usage throughout its life cycle, there is a visible decline at the beginning of 2014 and eventual rebound. The newer model, by comparison, sees continual growth after its appearance, with a higher peak usage than its predecessor. As of the time of this writing, both phones remain widely available on the market as carrier-subsidized devices and can serve as a model for the considerations one must make when choosing among several devices. We could have easily chosen the older model, saved several hundred dollars, and put the difference toward other devices, but other attributes beyond price and access are worth considering.

One way to think about building a device lab, then, is to attempt to have a diverse collection of items and to avoid homogeneity, at least while the lab is small. In the case of the Galaxy smartphones cited above, both devices have nearly identical size screens and were created by the same manufacturer, but the newer model has a higher pixel density, as well as a handful of other incremental improvements to the hardware. Of significant note, it also has a newer version of Android installed by default, and at the time of our purchase, was available in a Play Edition, meaning it would likely be upgradable to a newer version of stock Android in the future. Thus, we prioritized devices from across a range of screen sizes and a spectrum of operating systems. With regard to the former, our analytics data showed visitors with screen sizes between 320×218 and 2560×1440, so we looked for devices that spanned this general range. With regard to the latter, we purchased devices running the most current version of iOS, Windows, Blackberry, and Firefox OS, but Android was one of the most challenging areas to consider.

Figure 5.2 shows the distribution of Android devices visiting one of our digital collections during a one-year period. Nearly every version of Android has some level of representation on this chart, and thus we attempted to account for this by purchasing devices for most versions of Android going back to version 2.2 (Froyo). As a consequence, we simultaneously covered our other criteria as well since older Android devices tended to have smaller, lower-resolution screens, and most cost less than newer devices.

Unanticipated Events

Because the project of setting up our lab grew out of the User Interfaces Unit, a group not accustomed to making purchasing decisions, developing policies, or circulating materials, several unexpected events caused changes in plans, delayed purchases, and caused or resulted in other unforeseen headaches for us and others. Many of these were related to our own particular institutional policies—often related to technology—and we would expect that other libraries that set up similar labs will encounter problems specific to their own circumstances. We strongly encourage including administrators, purchasing agents, circulation employees, and appropriate technologists into the decision-making process as early as possible so that such problems can be identified and mitigated early.

From an institutional purchasing perspective, building a device lab entails the acquisition of consumer-grade hardware, often from a variety of merchants, and for some organizations this may raise any number of red flags. As an example, our university has a policy concerning the purchase of cellular phones that primarily addresses employees who need a single device for work-related communications. We were buying multiple smartphones, off-contract, and without the intention of using the devices as telecommunications devices, but our purchasing agent still needed to communicate our intentions with university officials and navigate through a number institutional procedures that were unexpected at the time. Similarly, in one instance we sought the purchase of a Windows-based tablet and chose a specific device that we were seeing used in our analytics data. However, a technical reviewer denied the request because the tablet had attributes of a laptop, and the university had a purchasing agreement with a competing manufacturer. While this may seem a minor detail, we would have saved considerable time had we been aware of existing purchasing agreements for certain classes of physical hardware.

As to software, while the initial setup of our lab didn’t require us to outfit our devices with apps, discussions with various agents in our organization quickly told us that purchasing apps or setting up user accounts for the devices would be difficult since it was a gray area within institutional policy, having very little precedent for our type of project. We also found that in several instances, sellers were unable to accommodate our institution’s tax-exempt status, or we were met with various problems related to a vendor’s online payment system or processing of purchase orders. Finally, we decided not to attempt to purchase used items on the secondary market. While one might expect that this would provide for an economical method to purchase older devices, it proved too difficult in an institutional setting such as ours.

Finally, making the tablets and phones in our lab available to the public has been slow to start. Since we took final delivery of our devices at the end of the summer 2014, we immediately began developing a responsive design for our primary and several secondary websites, using the devices for internal development. While we have space available for interested developers to use the items in-house, the unit’s offices and work hours are not well suited to allowing patrons unrestricted access, nor have we advertised the device lab in a robust enough way. These are both structural and circumstantial problems that are specific to our institution and the timing of our lab’s creation. As stated elsewhere, the ultimate design of a mobile device lab can be quite variable, depending on intended use, audience, and need. Since the UNT Libraries offers a makerspace that lends technology items, we have slowly begun making many items in the lab reservable through that service since (for us) it provides the greatest visibility to patrons seeking access to cutting-edge electronics and development resources.

Conclusion

This chapter has sought to demonstrate that building a collection of mobile devices and related technology for developers within a library is a novel approach to working with touchscreen and other mobile electronic devices. Building such a lab is not without its challenges, but it ultimately brings about a number of positive outcomes for the library. When incorporated into the library’s regular stack of development hardware, technical staff have access to the tools needed to build websites and services that simply work for their users. When lab items are provided to the public, patrons with hopes of becoming technically proficient as developers or who want to use mobile technology to make something new can do so without bearing the full financial burden of the tools that make their dreams possible. While having tablets and smartphones available within the library is an important first step, they are a single component within a larger set of tools that libraries should increasingly consider making available to their patrons. In the near future, a well-conceived mobile device lab might consist of a few tablets and a suite of eye-tracking and biometric sensors for institutions with programs in psychology, information science, or business. It could entail a future iteration of smart glasses and health and activity trackers at a library serving a medical school, or a handful of smartphones, 3-D printers, and circuit boards at a college with a strong engineering program. For the school library, it might include tablets paired with littleBits, Mindstorms, a rooftop weather station, and a range of plug-and-play environmental sensors. The list goes on and on. Libraries have historically aggregated books, journals, and other media to the community, and increasing numbers provide access to photography equipment, calculators, laptops, and other types of nontraditional materials. Mobile-related technology should increasingly be included in the mix.

Notes

1. Mobile Solutions web page, Texas State Library and Archives Commission, accessed May 21, 2014, https://www.tsl.texas.gov/texshare/mobilesolutions.
2. Peter-Paul Koch, “Smartphone Browser Landscape,” A List Apart, no. 320, December 14, 2010, http://alistapart.com/article/smartphone-browser-landscape.
3. Meggin Kearny and Matt Gaunt, “Developing on Devices,” Web Fundamentals, Google Developers website, accessed June 1, 2015, https://developers.google.com/web/fundamentals/tools/devices.
4. Frank Boateng and Yan Quan Liu, “Web 2.0 Applications’ Usage and Trends in Top US Academic Libraries,” Library Hi Tech 32, no. 1 (2014): 126, doi:10.1108/LHT-07-2013-0093.
5. Catharine Bomhold and Callie Wiygul, “Academic Libraries Are Moving to the Mobile Web—Or Are They?” Texas Library Journal, 89, no. 1 (Spring 2013): 16–19, EBSCOhost Connection (89447516); Bohyun Kim, “Responsive Web Design, Discoverability, and Mobile Challenge,” chapter 4 of “The Library Mobile Experience: Practices and User Expectations,” Library Technology Reports 49, no. 6 (August–September 2013): 29–30, EBSCOhost Connection (90405356).
6. Nielsen, Local Watch: Where You Live and Its Impact on Your Choices (New York: Nielsen, January 2014), 11–12, www.nielsen.com/us/en/insights/reports/2014/local-watch-where-you-live-and-its-impact-on-your-choices.html.
7. Anselm Hannerman, Andre Jay Meissner, and Christian Schaefer, OpenDeviceLab.com website, accessed June 1, 2015, http://opendevicelab.com.
8. Ibid.

About the Author

William Hicks is the head of the User Interfaces Unit at the University of North Texas in Denton, Texas. He oversees client-side development of the UNT Libraries’ websites and holds a master of music in musicology and a master of science in information science from UNT.

Refbacks

• There are currently no refbacks.

Published by ALA TechSource, an imprint of the American Library Association.
Copyright Statement | ALA Privacy Policy