D-Lib Magazine

Carmen Mitchell
California State University San Marcos
cmitchell@csusm.edu

Daniel Suchy
University of California, San Diego
dsuchy@ucsd.edu

doi:10.1045/january2012-mitchell

Abstract

One of the recent dominant topics in library technology has been the development of library mobile websites and services tailored to mobile users. While much has been written and discussed on the subject, very little of the conversation has focused on mobile access to digital collections. Libraries and museums spend significant resources in an effort to identify, digitize, ingest, describe, store, and display items in their digital asset management systems (DAMs). Creating user interfaces that provide online access is just one component of building a digital collection, and represents a continual challenge to stay abreast of evolving technology and user expectations. The latest challenge for libraries and museums is to adapt and grow our digital collections to meet the needs of an increasingly mobile user. We present the findings from in-depth case studies of four selected institutions and university libraries. These institutions were chosen because they already offer mobile services built around their digital collections, and are thus leading the effort to present them in uniquely mobile-centric ways.

Keywords: digital asset management, mobile website, case studies, mobile development

Background

The seed for these in-depth case studies came from a more general July 2010 survey (developed with Cristela Garcia-Spitz from UC San Diego) in which a wide library community was asked for input about their efforts—or lack thereof—in building a mobile access layer to their organization's existing digital collections. Unlike mobile websites in general, this is an area which hasn't received a lot of research attention. Many organizations are just now starting to add mobile access. The survey went out to broad technology-minded groups such as LITA, and also to smaller more focused communities (DLF, Code4Lib, etc.). The original survey questions may be seen here: http://goo.gl/1ujA.

The survey received 25 responses, which were summarized and presented at CurateCamp in Berkeley in August 2010. This presentation (also with Garcia-Spitz) ended with a lively discussion, and several more questions from participants.

The CurateCamp response illustrated that other practitioners were curious about the process and what other organizations were doing. As a result, it was decided to delve deeper into the specifics of developing mobile access to digital collections. The original survey questions were revised and expanded to create a more focused interview-style format, and then the group approached organizations that already had some success with mobile applications. Interviews were conducted via email, phone, and video chat from November 2010 to January 2011. The results of the interviews identified valuable "lessons learned" and useful advice for any person or organization looking to expand their mobile offerings

Case Study Questions

Participants

Duke University Libraries / Sean Aery, Digital Projects Developer, Digital Experience Services Department

Montana State University Libraries / Jason Clark, Head of Digital Access and Web Services

North Carolina State University Libraries / Tito Sierra, Associate Head, Digital Library Development

Smithsonian Institution / Nancy Proctor, Head of Mobile Strategy and Initiatives

Findings & Interview Highlights

1. What is the appropriate approach for development of mobile access to digital collections?

Each respondent indicated the need to first identify the intended audience and their needs, and let those results shape the development approach. Creating concrete mobile use cases and comparing the differences to desktop use cases is one valuable way to prioritize efforts. Use cases guide which mobile views and tools should be developed first, which are of secondary importance, and which provide no tangible benefit on a mobile platform and therefore should not be pursued.

Along with defining users' needs, respondents indicated that it is also important to conduct an internal assessment of available resources and limitations. In the case of Library IT, this means identifying in-house expertise and determining how well it can be leveraged for mobile development. This is particularly the case for native applications (such as Apple's iOS or Android), where the programming skills required can be very different than for building web sites. Long term sustainability was cited as an important consideration as well.

Jason Clark: "I think you have to look at your user population and analytics first. Is there a mobile itch to scratch? Second, you need to do an assessment of local programming and design skills. In our case, we tried to utilize our in-house skills and expertise with Javascript, PHP, CSS, and HTML. You are also dealing with a limited attention span when it comes to types of users. The mobile browsing/searching environment needs to focus on essential content, simple data views, and quick actions."

Tito Sierra: "One challenge is defining the use case for mobile access to library digital collections. Just because you can create a mobile application or mobile optimized version of your digital collections website does not mean that your users will find value in these new access tools. Libraries should consider how mobile access adds value to the user experience with digital collections. This may require some creative reuse of digital collections content. Also, some kinds of collections may work better than others in a mobile context."

Sean Aery: "Another challenge is how to support mobile access initiatives in a sustainable way. For example, to what extent can existing digital library infrastructure be reused to support mobile access? To what extent can the specialized tools used for mobile access be reused for other mobile initiatives? There are real costs both in terms of staff time and money in working in any new emerging technology space, such as mobile access. An appropriate approach would be one that is adaptive to changes in mobile technology and adaptive to evolving user behavior with mobile devices."

Respondents developed projects both in-house and with vendors. Their justifications included:

Nancy Proctor: "A combination of both. Part of the SI strategic planning documentation calls for assessing what can be done in house, and what would be better off contracting out. Each project gets evaluated individually."

Tito Sierra: "Our mobile access interfaces for both library services and digital library collections were developed in-house. In the digital collections space, we do not provide mobile access for all of our managed collections. Instead, we've repurposed some of our existing digital collections assets to create custom mobile apps for specific audiences and use cases."

1b. To what extent did you leverage your existing DAMS? Does it provide any means for mobile access? Did you have to take assets out of it and into a separate system (CMS, etc) to provide mobile access?

None of the respondents used their DAMS solely for this purpose, largely because this was not a supported feature. However, most were able to leverage the data in different ways to supply the mobile version.

Jason Clark: "We didn't use our DAMS in this case. We had local MySQL databases with low-level APIs (read-only access) for the digital collection data. ... This was an essential part of our design process because "write once, deploy everywhere" helps our small team stay productive."

Tito Sierra: "Our digital collections infrastructure consists of several independently configured software components that work together to support multiple methods of digital collection discovery and access. ...To answer the question directly, our digital collections infrastructure does not directly provide a means for mobile access (it is not designed to be "mobile aware"; there is no mobile "plugin"), however it is flexible enough to provide infrastructure for custom mobile access interfaces."

Sean Aery: "It [the DAMS] inherently has no support for mobile interface deployment, but it is a critical piece of the puzzle that makes the iPhone application function. It exposes MediaRSS feeds of any search result and the application accesses those feeds during user search or browse actions. The MediaRSS schema was ideal because it includes essential elements like an object's thumbnail URL, image URL, and permalink."

The mobile framework and corresponding languages varied widely, and were somewhat dependent on the type of application being created and the in-house language expertise.

Jason Clark: "We didn't use a mobile framework with this iteration. We have some prototypes in jQtouch, but built this application using some basic javascript and studying up on mobile best practices for HTML markup and CSS. The full language and markup suite was Javascript, PHP, CSS, and HTML."

Tito Sierra: "Our general mobile library website (http://m.lib.ncsu.edu) uses a modified version of the MIT Mobile Web framework, written in PHP. The current production version of the WolfWalk mobile website uses this as well. The WolfWalk iOS application is written in Objective-C, with a PHP-based backend for data access over the network. The new exhibit mobile website is written in Ruby on Rails using the jQuery Mobile framework. We are likely to continue using jQuery Mobile in the near future for mobile web development. Given the rapid development of mobile frameworks, it is possible that we will be using some new mobile development frameworks a year from now."

Sean Aery: "Since our mobile interface is an iPhone app, it was likely developed in Objective-C language in the Cocoa framework, though since we did not develop it in-house, the exact technologies could only be confirmed by the developer."

Overall, mobile access to digitized collections was designed for casual institutional users and visitors, rather than for scholarly research. There were several reasons cited for this.

Tito Sierra: "WolfWalk is designed for anyone interested in the history of NC State University. This would include alumni, current students, parents, staff, and visitors to campus. It is not designed for scholars. Our goal was to reach the largest possible audience that is interested in our University Archives content."

Sean Aery: "Since we knew the site would be part of an integrated suite of Duke apps, we wanted to make sure it would appeal to the Duke community first and foremost. ... It was designed more with the casual browser in mind than the serious scholar, and that is reflected in the limited options for searching (e.g., no faceted navigation), and reading about (e.g., no essays or research guides) the collections."

One noted exception was The Smithsonian, which, because of the breadth and range of its mobile services, suggested asking the following questions for each new mobile initiative.

"What are the desired outcomes for this audience? What do we want them to know, think and/or feel?
What platforms do they already use? How do they use them elsewhere and what excites them about these tools? (Consider not just mobile technologies, but fixed web and social media platforms as well.)
What questions do they have? What do they want to know? Ask them: they may point out the 'elephant in the room' that an experienced curatorial eye no longer notices.
Who is the most interesting person, or persons, for this audience to learn about this subject from, or for this audience to do this work with? Let them be the guide to the mobile experience."

Considering the intended audience, the largest emphasis was on providing a simple and streamlined feature set.

Jason Clark: "We tried to keep things simple. If you look closely at the actions and views that are part of our mobile apps, it's very basic stuff: learn about the collection, search, explore, and download. The design was driven by the principle that a patron would need quick access, not extended research access."

Sean Aery: "The feature set was intentionally basic to 1) keep the project on a quick timeline and reasonable budget, and 2) to keep the interface simple enough to be used easily on an iPhone. Users can: search across all collections, search within a collection, browse a list of all collections, browse the items in the collections, view an object, swipe through objects in search/browse results, zoom with pinch action, save as wallpaper, view item information."

4. Did you think a mobile version of digital collections needs to be managed differently than a regular mobile site? If so, how?

Respondents stated that the requirements for file formats and bandwidth issues with file sizes should be kept in mind. Mobile users do not want to wait while a large file downloads to their device.

Tito Sierra: "Care should be taken to deliver media that is somewhat optimized for the access method. For media objects this means making available smaller file size derivatives of the digital objects. Mobile access also tends to mean smaller screen size access, so the length of textual descriptions may also be an issue."

Making sure to accommodate bookmarking so that users can find and save information for later reference is important. Mobile devices are great for initial discovery, but not ideal for in-depth research.

Jason Clark: "I keep coming back to the idea that our mobile digital collections need to allow for bookmarking or citations so that a user can find and save objects for using later once they are ready to research or have better connections. This "read later" mentality changes interface design and what you get are simple, "scannable" lists of items, minimal metadata, and direct links to files or citations."

5. How did you gain institutional support? Was it different for mobile vs. other initiatives?

Respondents urged exploiting small successes. If there is buzz around a pilot project, be ready to move quickly and utilize that momentum.

Jason Clark: "We have a research and development component to our team. We brought up the idea in our digital content group meeting about prototyping some mobile digital collections and it was well-received. (Our Dean and Associate Dean are part of that group.) Right now, mobile development has a momentum of its own which made the process easier. There is real, palpable excitement around the idea of this whole new platform for library content. We rode that enthusiasm wave. Our digital collections are also more independent, peripheral tools for the library so the vetting of designs and ideas wasn't subject to all teams within the library.

Getting "buy-in" from the patrons is important, but support from colleagues and upper-level administration is important as well. For the Smithsonian, getting support from the general public (through portals like Smithsonian Commons, http://www.si.edu/commons/prototype/) helped move projects forward. A mix of buy-in from patrons and also from colleagues was considered the best possible combination.

Tito Sierra: "We have high-level administrative support for mobile initiatives. In the case of WolfWalk, the project was conceived of and implemented as a cross-departmental pilot project, with small focused team of library staff. We are fortunate to have all the necessary skills for this project within the library organization."

It is easier to gain support for low (or no additional) cost projects that utilize current staffing models and skills. This is a low risk for the organization, with potentially high benefits:

Sean Aery: "Institutional support was not hard to gain because the project seemed so clearly to be a low-risk, potentially high-reward situation for both Duke and the Libraries. ... The library directors were supportive because 1) the project did not require any library developer time nor funding, and 2) they are always interested in new ways to incorporate the library's digital resources in campus-wide projects.

6. How will you measure the level of acceptance, satisfaction, and usage of the site?

Each organization handles the sticky issue of assessment in a different manner. Google analytics provides some information regarding unique visitors and traffic sources for mobile web sites, but does not convey if users like the site or find it useful. For mobile applications that are downloaded through an App Store, download counts and product ratings may be available, but they might not. If the digital collections portion is just a smaller sub-section of a larger application, tracking use is nearly impossible.

Sean Aery: "Though one significant challenge in having a vendor-developed tool offered through a proprietary system (iTunes) is that we have little to no useful data on how often the module is accessed. It is also merely one module in the DukeMobile app, so, even with figures on how often the app is downloaded, we can't distinguish the folks who use it for campus maps versus those using it for library resources."

North Carolina State University embedded the ability to send feedback via email directly into their WolfWalk application, but have not received many messages from users. Instead, they have gotten more information from the ratings and statistics that come from the Apple App Store:

Tito Sierra: "The WolfWalk iOS app has a built-in ratings and reviews component as an App Store app. So far the ratings and reviews have been very favorable. Apple also provides a site to track download statistics by day, week and month. We embedded an email-based feedback feature in the app, but we have received very little traffic through this channel. We also collect some basic ongoing usage analytics across both the mobile web and iOS versions of WolfWalk. We have found that the iOS version of WolfWalk is used much more than the mobile web version of WolfWalk."

Focus groups and mobile usability studies were two other ways that organizations measured satisfaction, with two respondents having completed at least one, and a third respondent noting that a focus group was being planned.

Each of the four respondents had very different lessons learned, and words of advice that could be applied to almost any size organization looking to implement a new service.

At the Smithsonian, when a very high-level funder offered to pay for a mobile application to accompany an interactive exhibit, the Smithsonian had only 72 hours to decide if this was do-able. When the decision was made to create the application, they only had 6 weeks to develop it and push it into the market. This application was supposed to help direct patrons to the exhibit web site ... but they were not designed together. The web site was not optimized for mobile. This was not a strategic project, and didn't deliver the expected results.

It was suggested to think more about access. Why not think about mobile access as a way to reach out to disabled patrons and users? Additionally, when you are developing a mobile site or an application, can it be used by everyone? Is it ADA compliant?

Nancy Proctor: "We should 'foreground access' by creating apps that help to increase access for disabled patrons and users. Products developed for access always revolutionize everything else that we do."

It is necessary to be ready to move quickly, but there are certain timelines that are out of an implementer's control. When developing an application that will be downloaded through a third party (like the Apple App Store), there may be requirements and processes that require specific timing and steps to be taken. If an organization is not used to working within this kind of structure, it may take some adjustment. With adjustment comes the risk that deadlines and benchmarks may not be met in a timely manner:

Tito Sierra: We have learned that deploying iOS apps (getting a license, setting up devices for testing, and publishing to the App Store) is more complicated that we thought it would be (or should be). This took some adjustment as our team experience is primarily focused on developing web applications that do not have these encumbrances.

Sean Aery: Notable timely innovation is good PR for the library: we got lots of attention in the blogosphere & at national conferences.

Collaborating was mentioned as key. Working across departments and organizations leads to cost savings while also building up support.

Sean Aery: The approach of attaching a library interface onto an existing campus-wide application (rather than building our own thing and hoping people find it) has been generally seen as beneficial. Latching our content onto an existing campus project with its own development budget made this virtually a zero cost initiative for the library.

Respondents suggested focusing more on "in house" mobile web site development and less on vendor created device specific applications. This allows for more control with the look and feel of the site, and more flexibility when needing to make changes.

Tito Sierra: It's not worth investing too much time in any specific mobile development framework or architecture, as it is likely to become outdated in 6-12 months time. Nimbleness is a virtue in the mobile space.

Sean Aery: "...We will likely focus more on in-house mobile web interface development and much less—or perhaps not at all—on vendor-developed platform-specific apps. That will give us more control of our display, mitigate some of the problems working within the app framework, and will also help us reach many more users."

Another suggestion was to "start simple"; add complexity as needed. Is that last widget really needed? Consider how systems intersect—is there a way to repurpose data?

Jason Clark: "Working within mobile development requirements makes you ask tough questions about needed features and forces you to streamline and optimize your code in a good way. By the end of this project, we had reworked and improved the performance of our search page code and ended up bringing that code forward into our desktop app search routine. Going forward, I would also look to use some of the full features of advanced JavaScript mobile frameworks like SproutCore or jQuery mobile. In the time since we built our app, these frameworks have emerged which provide the look and feel of native mobile applications in the browser."

Conclusion

As the interview highlights suggest, offering mobile access to digital collections is still a relatively new endeavor for libraries and museums, and can be approached and developed in a variety of ways. The shift from desktop to mobile computing represents a challenge in providing service to our users, but through relating our experiences, distributing knowledge, and sharing both successes and failures alike, we gain a significant head start.

Acknowledgements

The authors would like to acknowledge the assistance of Cristela Garcia-Spitz of UC San Diego in the preliminary survey, the CurateCamp presentation, and crafting the case study questions. The authors would also like to thank Sean Aery, Jason Clark, Nancy Proctor, and Tito Sierra, for their time and for sharing their experiences.