Mobile Devices Task Force Report Submitted by the Mobile Devices Task Force: Joe Abraham, Katie Anderson (co-chair), Anne Butman, John Gibson, Priscilla Lee, Choong Hoong Liew (no longer at Rutgers), Mei Ling Lo, Sam McDonald, Chris Singh, Gene Springs (co-chair), Myoung Wilson.

1. Introduction o Background o Benefits and Rational o General Recommendations o Further Reading 2. Subgroups o Reference Services o User Services o Buildings/Hours o Databases 3. Additional Information and Recommendations Appendix 1: Task Force Charge Appendix 2: ARL Institutions with mobile presence.

Introduction Background The Mobile Devices Task Force was charged with examining the implications of mobile devices on the Libraries existing and emerging services, on current and future collections and on the website. The general definition of a mobile device can encompass a variety of technologies that include mp3 players, laptops, netbooks, pda’s and cell phones. It was determined by the task force that examination would be focused on handheld mobile devices that have a web browser. These devices can access the internet via wireless, have a screen for display that is small (less than 800 pixels wide), have input (keyboard or touch-screen), and are handheld or “pocket-sized”. This includes pda’s, Tablet PC’s, Ultra-Mobile PC’s, smartbooks, pda’s, cell phones, hybrid pda/cell phones and Smartphones (cell phones with advanced capabilities). Larger screen devices like tablets and netbooks are not to be ignored, but the group’s focus is on the smaller screen devices, most notably the Apple iPhone and phones using the Google Android operating system, two top market shareholders in the industry. While many of these mobile devices have e-reader capability, the task force recommends that e-readers and e-books be addressed by a separate group. Benefits and Rational for an RUL Mobile Presence Recent reports reveal that the use of mobile devices to access the Internet is steadily increasing. March 2010 comScore data shows that 30% of mobile subscribers use the browsers on their mobile devices. This is up 2.6 % from the December data (comScore, 2010) A February 2010 Pew Internet report reveals that over 25% of teenagers use their cell phones to access the internet and over 60% use their phones for texting (Pew Internet, 2010). Google, in recognition of growing mobile use recently announced a “Mobile First” rule, where it has pledged to release mobile equivalents of all of its new desktop services (Google, 2010). Current literature reveals the thought that mobile devices are “now ubiquitous amongst student populations” (Herrington, 2008). This increased use of mobile devices is not just being reported on paper, members of the task force have observed students using these mobile devices. It is possible to determine what devices are being used and how often they are being used to access our websites using sites such as Google Analytics. Libraries and librarians have taken notice of this increased use of mobile devices. Presentations and discussions addressing the creation, use and practicality of mobile devices and mobile sites are appearing at different conferences from ALA to Computers in Libraries. There is even a conference dedicated to the topic, The Handheld Librarian Online Conference. Examples of libraries with a mobile presence can be found on the Mobile Libraries section of the Library Success Wiki ( In order to serve our users who have embraced the use of mobile devices, it is recommended that RUL begin to establish a mobile presence for access to library services. Recommendations The Mobile Devices Task Force examined current literature, presentations, and examples of library mobile sites in order to present the following recommendations and

plan of action for RUL. The report will present different phases for establishing a mobile presence. General  The existence of a University-wide Mobile Site is essential to the success of a Library Site. Most examples of successful library sites are via a University-wide mobile portal. ACTION: Work with University to establish creation of University mobile site.  A mobile friendly login to the proxy and network would ease access to any mobile sites offered by the library. Currently, logging into the wireless security on campus via Bluesocket is not mobile friendly. ACTION: Work with OIT in order to establish mobile friendly login page for logging into Rutgers wireless.  Creation of a mobile website is not simply a minimization of current sites for mobile viewing. A successful mobile site provides the core services most likely to be used by a patron using a mobile device. A successful mobile site does not just reproduce the library website; it provides what patrons would actually use in a mobile context in order to save the time of the user. Services determined by the task force are: Reference Services, User Services, Buildings/Hours and Databases. ACTION: see sections for each core service.  Along with creation of a mobile website, the creation of specific RUL Applications should also be considered on a different, but parallel development path. ACTION: determine which applications are to be created, explore licensing issues with available platforms and assign programmers.  Current and future library services should include a mobile specification as part of the standard evaluation, taking mobile access into consideration of future purchases and developments. Examples of such services include databases, ebook platforms, and future open source systems. ACTION: depending on the service, incorporate mobile evaluation into the overall evaluation.  As implementation occurs, pages need to undergo thorough testing before release. Testing should occur on as many devices as possible. It is recommended that library faculty and staff with mobile devices be solicited for testing. ACTION: solicit volunteers and keep a record of who will be testing and on what device.  The main mobile pages should appear to be available from: and and and and and to cover common default locations (few people actually use .mobi domains e.g.  General recommended phases for transition to a mobile accessible site (more specific phases are included in the core services descriptions): Phase #1 - Basic Web pages May be just part of our initial rapid prototype. Can use different style sheets to make the basic content work in different templates (primarily differentiated by screen size).

Phase #2a - Basic Web pages, auto-redirect from plain html front-page (w/embedded JavaScript) Phase #2b - Basic Web pages, auto-redirect from plain html front-page (w/embedded PHP) Detect the user's device type (by capability, e.g. screen size, script-capable,...not by vendor) and serve up appropriate content with the best templates and scripts(for that device). Allows the use of more scripting etc. for some devices. Phase #3 - Web pages, auto-redirect from Drupal-delivered front page Phase #4 - Redirection into a mobile Drupal-delivered site (with a mix of static and Drupal-dynamic content) Phase #5 - Content and interfaces changes depending upon capabilities of device (perhaps using time/date, location(GPS), cookies(for remembering preferences) etc.) and the kind of dynamic content available.   The Mobile Devices Task Force recommends that RUL begin moving towards a mobile presence in phases. The first phase should provide the minimum core content for Reference (mobile friendly site with hours, phone #, contact), Building/Hours (mobile friendly hours, directions), User Services (mobile friendly IRIS) and Databases (links to currently available mobile databases). The following phases will enhance the mobile services in each of these categories and are detailed in this report under in the subgroups.     Sources comScore, 2010. "comScore Reports March 2010 U.S. Mobile Subscriber Market Share". Available: re_Reports_March_2010_U.S._Mobile_Subscriber_Market_Share (accessed 5/17/2010). Google Mobile Blog, 2010. "Barcelona: Mobile First". Available: (accessed 5/17/2010). Herrington, J., Mantei, J., Herrington, A,. Olney I., and Ferry, B. (2008). New technologies, new pedagogies: Mobile technologies and new ways of teaching and learning. In Hello! Where are you in the landscape of educational technology? Proceedings ascilite Melbourne 2008. Pew Internet, 2010. "Social Media and Young Adults, Part 2: Gadget Ownership and wireless connectivity". Available (accessed 5/17/2010).

Further Reading on General Mobile Devices and Design: Mobile Web Best Practices:‐bp/#requirements  Four Key Principles of Mobile User Experience Design:   Tips on Designing and Developing Mobile Web Sites:  Sierra, T. (2009). "Mobile Library Projects at North Carolina State University", Coalition for Networked Information Fall 2009 Task Force Meeting, Washington, DC, December 15, 2009. Educause 7 Things: 7 The Use of Handheld Mobile Devices: Their Impact and Implications for Library  Services: http://mobile‐‐of‐handheld‐mobile‐ devices‐their.html

Reference Services Providing and promoting reference services in a mobile format, accessible on handheld devices, create both unique challenges and opportunities. Taking into consideration the current reference services offered at RUL, which include both traditional services (reference desk, research consultations, phone) and modern services (email, chat reference via Meebo), and a best practices scan of RUL peer and aspirant institutions, the task force recommends additional reference services be provided that are accessible by users with handheld devices: text (SMS) reference, along with mobile-friendly chat reference. Current research indicates that RUL constituents, including students, faculty, and staff will be increasingly technologically capable (Johnson, Levine, Smith, Stone, 2010). For many of the youngest users, communicating via text message is the preferred medium of conversation (Radford & Lankes, 2010). In order to meet the potential reference needs of this ever-growing demographic of users, the task force recommends that a section of the mobile library site be dedicated to reference services, with a single point of contact, a phone number, for reference questions that both traditional phone users and text users can use to access reference services. There are two main challenges in implementing the recommendations outlines above. Providing a single phone number for system-wide reference may not reach the needs of local users and issues. Undertaking additional reference services, with expanding chat reference for mobile devices and adding text reference, would necessitate a formal audit and evaluation of the RUL chat reference services, currently met by using Meebo, as reference librarians have noted the often overwhelming volume of chat reference questions which are answered by a single librarian for a scheduled block of time. In order to address this challenge, there are several software options, either subscriptionbased or open source, which combine chat and text reference queries into a single queue, and allow for multiple librarians to answer questions at the same time; these will be outlined below. The options and descriptions below were researched by and presented to the User Services Council by Katie Anderson, Melissa Gasparotto, and Martin Kesselman on March 3, 2010 with additional information provided by the Mobile Devices Task Force Reference Subgroup. Software for SMS Reference  

Mosio Text a Librarian Text a Librarian, Powered by Mosio - Text Message (SMS) Reference Services. Accessible on over 260 million US mobile phones using a mobile, cell phone carrier approved technologies. Used by single branch libraries or multi-library cooperatives. Pros: Web-based interface Can create customized answer templates for frequently asked questions Auto-responder when no one is available

Patron privacy (librarian does not see patron phone number) Statistics collection and built-in report generator Patron exchanges are recorded and saved Tech support included Cons: Cost, fee-based service How it works: Patron sends text message to number assigned to library Must preface question with a customizable "keyword," example: "ASKRUL whr is bathrm in alex? thx" Librarian is alerted that a text has been received (through email, IM, or inside the Mosio interface), and can respond to the question from inside the web-based interface, or micro board Libraries Currently Using Mosio: Peer/Aspirant ARL: None Other ARL: Boston College, Cornell University, Dartmouth College, Kent State University, University of Pennsylvania (Main, Lippincott, Biomedical), Yale University, Yale University Harvey Cushing/John Hay Whitney Medical Library) New Jersey Libraries: Newark Public Library, Princeton Public Library, Atlantic Cape Community College, William Paterson University Mosio's Partial List of Clients: SMS Options AIM Hack: (allows libraries using AIM to receive texts as chats) Users Can: o Send a message to 246246 (AIMAIM) o Enter the text "send [library's AIM address] [question]" (without quotations or brackets)  For example:  send anytownlibrarychat what are yr hours? o From that point on, send and receive messages as you normally would. (Your patron doesn't need to use the account prefix, etc. for each message during the session) o Standard messaging rates will apply Pros: Free Web-based No need to learn new interface Cons: Only available when chat is available, comes in via chat service

No tech support No patron anonymity Libraries Currently Using SMS by AIM Hack Peer/Aspirant ARL: University of Illinois, University of Minnesota-Duluth, University of Minnesota-Morris, University of Maryland-University College, University of Maryland Engineering Library, University of Maryland-Baltimore County, University of Pittsburgh, University of Texas-San Antonio, University of Kansas (2 accounts), Penn State (listed on wiki but appears to no longer be active) Other ARL: SUNY Albany, University of Delaware, University of Georgia, University of Iowa, Oklahoma State University, University of Southern California, University of Michigan New Jersey: New Providence Memorial Library Other SMS Google Voice LibraryH3lp Google Voice Gateway - Library obtains a Google Voice account and phone number. Patrons text a phone number, not a short code. Librarians respond via IM as with other LibraryH3lp questions. Free, dedicated number for the library Can be used on a cell or as an SMS component of another service (Google Chat, Library H3lp, etc.) No anonymity for patrons Upside Wireless is an SMS gateway company used by UCLA Libraries Dedicated number for the library Texts converted to email or routed to library's chat client Can be used with company's web-based interface, which allows for templates and offhour responses Cost not published Anonymity issue unclear LibraryH3lp Android SMS Gateway - Library provides the Google Android phone and creates a gateway using LibraryH3lp. Patrons text a phone number, not a short code. Text messages can be flexibly routed and transferred among librarians. How it Works: Allows texts and IM to come in through same interface (widget) SMS portion works through Google Voice: Patrons text a question to number provided by Google Voice, which is translated by Library H3lp into chats Small cost for Library H3lp, but no additional charge to add texts to account** Cons: Delays in message delivery, texts from patrons sent when librarian is offline do not generate alert for librarian via email or IM (would only see a message sent offline when logging in next day) Libraries Currently Using Other SMS (Google Voice, Upside Wireless, Library H3lp)

Peer/Aspirant ARL: North Carolina State University, University of Virginia, University of California-Irvine, UCLA, Indiana University Other ARL: Brigham Young University, Duke University Business Library, Duke University Divinity Library, University of Manitoba Implementation Phases: 1. Provide reference contact information (AAL email, all reference desk phone numbers) in a section titled “Reference Services.” 2. While developing mobile site, it is recommended that USC evaluates and selects one of the chat/SMS reference clients discussed above in order to provide mobile-friendly reference services, beginning with texting and moving towards live chat. 3. Once new chat/SMS client is selected, new contact number/widget will replace or be prioritized over reference desk phone numbers.

References: Johnson, L., Levine, A. Smith, R. & Stone, S. (2010). The 2010 Horizon Report. Austin, Texas: The New Media Consortium. Radford, M. & Lankes, R. (2010). Reference Renaissance: Current and Future Trends. New York, New York: Neal-Schuman Publishers, Inc. 

User Services IRIS In order for users to access and search IRIS on their mobile devices, there are a few options: 1. Quick Search screen that leads to Full IRIS screens: Currently, at our libraries web site, there is an IRIS quick search screen. ( John Gibson from our Camden Library has created a similar quick search interface which works with the mobile device. The quick search box allows the queries to be passed on to IRIS. The results display screens, however, are larger than the screens of mobile devices as they are meant for desktop or laptop monitors. Users will need to enlarge the text and then scroll up and down to see the entire screen. This approach can be implemented for initial rollout. Yet, it may not be entirely "Mobile Devices Friendly", as most users may find it difficult to navigate on the pages.                                          Quick Search screen for IRIS            Results screen which requires    enlarging and scrolling 

    2. Quick Search screen that leads to small IRIS screens: In addition to the Quick Search Screen, there is the idea of using CSS style language to hide certain fields on the display screen so that users can efficiently view the essential information for each record. Such idea will require some investigation to find out if it is actually feasible. This approach is worth investigating, provided that it is not too time consuming.                                           Quick Search screen for IRIS    Small Results screen which only displays    the essentials fields.  *Note:  This image    is a markup.  It is not from a screen    capture.*   3. Symphony Web Services 3.0 API: SIRSI is aware of the need for Mobile interface for searching library catalogs. Sometime in 2010, SIRSI will launch software called Symphony 3.0 API which maybe an answer for providing a mobile device friendly interface. The exact time frame for the implementation of Symphony 3.0 API, however, has to be determined. First, Rutgers has to test Symphony to make sure that such software will not interfere with our underlying support system called Tomcat. Then, we can try using such software to support mobile devices.

While such approach sounds promising, little information has been released by SIRSI about its main features. In addition, adopting such approach will also mean that there is a long waiting period for implementing IRIS on mobile devices.     Implementation Phases: 1. Roll out option 1 while doing a feasibility study for option 2.  2. When Symphony 3.0 API becomes officially available, we can then test out the implementation of Symphony at Rutgers.    Access Services Holds/Renewals/My Account Currently, SirsiDynix provides an iPhone application called “BookMyne” ( Patrons with iPhones can download this application and will have the ability to: search the catalog, renew items, place holds, access My Account and access the library homepage. Systems would need to install and configure a program on the unicorn server in order for our patrons to utilize this application. This application is not customizable and only available for the iPhone. However, Web Services 3.0 will hopefully provide more development and applications for other devices. Implementation Phases: 1. Install Web Services 2.0 and promote BookMyne to patrons with iPhones. 2. Investigate improvements/changes that occur with Web Services 3.0when it is available and determine usage of the application as well as its pros/cons 3. Consider in house application if the provided one does not meet library and patron needs. Text Messaging The ability to receive library notifications via SMS texting would benefit patrons who have mobile devices that are limited in capabilities ie; just cell phones.Currently, SirsiDynix does not provide a specific service for sending text messages. It does appear that there are third party vendors who provide this service as well as services available for InterLibrary loan and Article and Delivery notifications. In looking at examples of libraries that do provide this service, the task force found that there are some options that can be explored.  E-mail Gateway: It is possible to add a cell phone number as an e-mail gateway (every provider has this- it is basically your cell phone number with carrier identification in the address which allows your carrier to forward the email as a text message see into an additional email field which would result in the user receiving both an email and a text message.

Third Party: Public libraries are using a service called Shoutbomb to provide SMS notifications Separate Text Notification: Possibly use current notification system to send to another address, ie the cell phone number (address 3?). Possibility of creating shorter messages? Any text messaging service would need to include:  Notice about cost (free from our side- but carrier may charge)  Notice to patrons that the message may be truncated/not formatted, especially if they are just emails forwarded on  Specific instructions on how to opt in/opt out Questions:  How to keep information updated.  How to determine which notices to be sent: all? Just holds and recalls? Could we give patron the ability to opt in/out of certain notices?  Can we format text messages to be shorter than emails?  The mobile devices we are exploring give the user instant access to email, so is text messaging a priority? Examples:‐notices‐library/notices.htm  Implementation Phase: 1. Use e-mail gateway to send current notices via text message to patrons who prefer this method of communication. This will require creation of a form where patrons would enter their cellphone and carrier and the email gateway would be loaded into Workflows. 2. Explore other methods where duplication will not exist and messages are more text message friendly.

Buildings/Hours and Directions Mobile delivery of building hours, directions, locations and other building information will provide convenient access to our patrons with mobile devices. Directions and locations can be enhanced by utilizing the GPS capability available on many mobile devices. Hours Discussion "When are you open," "is the library open now," and "how long will the library be open after I get out of my early evening class" are likely to be common questions that a student or faculty member might ask in a "I would like to know right now" fashion. Delivering building hours in a "nice" format to their mobile device to serve this need is--how else to say it--basic. In consideration of this need, we imagined how this information would be served up. "Building Hours" (or "Hours") would likely be a top menu item for a RUL mobile device site. When a user selects this, the question is, "what is easiest and fastest for them to fulfill their information need?" We considered: - providing a list of different sessions of a semester, as is done on the main libraries web site (which leads to a table including all libraries) - listing all the libraries/buildings (which would lead to session hours or a whole semester's hours (by building)) ...both of these require extra clicks (and perhaps more bandwidth--if more clicks are needed to click back to choose another library or session, then bandwidth--and time-would be greater). We concluded that when a user selects "Building Hours" (or "Hours") that an alphabetical list of buildings/libraries is listed that shows the current sessions hours AND its next set of exceptions. e.g. mid-September, show fall semester hours and Thanksgiving hours. After Thanksgiving, show Fall hours and Exams. When Exams start show Exams, Last day of exams, and the Winter Holiday Schedule. This fulfills a user's need for "now" (and "soon"), without making an extremely long listing that is hard to parse. The long alpha list is easy to use on a mobile device as it is easier to scroll up and down (especially since the "information blocks" are very regular and consistent), than it is to click back and choose a different session or library. This approach does require that hours be updated a couple of times a semester, but the files will be pre-made before the semester starts and will be easy to change.

When we reviewed other Libraries to see how they displayed hours, we discovered that most do not have as many buildings/libraries...or sessions (and their exceptions) as we do. Our scale and environment require us to approach things slightly differently. Some libraries only show today, or "this weeks" hours. This may or not be something that we would wish to do, but to do so would require us to, given our larger complexity, put the data into a database so we could serve it up at this fine-grained level. Implementation Phases: Assuming the proposal above is suitable. 1. Basic html listing. Good for all devices. Data is in hand and this can be deployed easily. 2. Seek to abstract the data into a database (Drupal?) so that the data can be displayed for the basic web pages and for mobile devices (and perhaps other purposes!). (The PDF's for printing would be an extra challenge.) 3. Consider if serving data by the day or week is desirable. 4. Re-evaluate the above expandability, re-design References Demos we made for ourselves to visualize the issues. The demo includes a phone number. It could have also included a link to directions. Miami University Libraries

Directions Discussion For the purpose of this section, "Directions" refers to providing instructions to a user to arrive at a given building/library and not where in the stacks a book may be located. The art of providing directional instructions is start from "here" and provide instructions from the macro to the micro. That is, in our case, provide instructions of how to get to the right city and campus, then to the area surrounding the building, where upon one seeks a street address (or prominent landmark if available). Instructions could be all textual, but most people probably would prefer a visual map. We would also want to provide a phone number to be able to ask for directions (especially when the ones provided/available to you are unusable due to construction or accidents). Of our peers, nearly every library, that provides a map, links to Google maps. Some may

provide a small static image of the area around a library. Leveraging off of Google maps mobile means that very accurate data is available from anywhere to us, as well as the many sophisticated services that Google provides with maps and directions. Our recommendation for providing directional information is to: - have either one page for each building/library, or a long listing like with hours and display - library/building name - phone number (generally the access services desk) - street address - link to Google maps (with proper directional data passed to Google) - link to (textual) campus directions e.g. - link to parking help (at least handicap parking help) - cross-link to hours (so one can check to see if it will be open when you get there!) The above perhaps, when designed, might be re-ordered. Implementation Phases: 1. The proposal above is feasible for deployment after some parking help has been written. We may want to collect GPS coordinates to make use of some Google services. 2. Re-evaluate the above expandability, especially in light of new Google (or campus) services re-design.

References Google Maps for mobile                                 

    Databases The mobile task force recommends that a RUL mobile site include easy access to mobile friendly databases. Vendors that are currently providing mobile friendly sites were identified, as well as free sites and applications that may be of use to our patrons. Current Vendors Vendors are beginning to provide mobile friendly sites, the cost of which is already included in many of our licensing agreements. Notable examples include: EBSCOHost Mobile RefMobile (RefWorks) PubMed for Handhelds (open access) It is important for us to market these no additional cost services, due to the value they may add to the research of our faculty and students. There are some mobile database services (such as Naxos Music Library) that may require additional cost in administrative labor or licensing. We recommend that these decisions be left to the appropriate selector. We feel that the best approach toward making these databases available to users is to have a mobile friendly site that lists all of the known working mobile databases. A link should also be provided to the full A to Z list in case the user needs to use a database that is not mobile friendly. This mobile database page should be incorporated within a Rutgers Libraries mobile site (which, ideally, is itself a part of a university-wide mobile site). Examples of peer/aspirant institutions that have a database listing similar to what we envision: UNC Libraries (click on "Mobile E-Research Tools") U of Wisconsin, Ebling Library (Health Sciences Library) U of Illinois Library Arroyo-Vázquez (2009) wrote that patrons may turn to external resources, such as Skweezer ( and Google Mobilizer (, to access our resources (p. 132). Unfortunately, these sites simple transcode our current pages and aren't very mobile friendly. Some examples: Main page: Databases: Users will access our services with their mobile devices, and while services like the ones above may make it easier for them to access certain services, it is not ideal.

Proxy Support One of the current obstacles of mobile access to premium databases is the lack of proxy support. While it is possible to connect to the Rutgers network using the built-in wireless features of many mobile devices, it is much simpler for users to connect through their carrier. In order to do this, appropriate additions and adjustments need to be made to the proxy. These include (but are not limited to): additional host names, mobile friendly log-in page, official support for mobile devices by IIS.

Implementation phases: Phase 1: Static site with list of currently known mobile-friendly databases. Mobile-friendly proxy login page. Addition of mobile-friendly sties to proxy (when necessary) Phase 2: Drupal records for databases include mobile-friendly status and URL. Static mobile database list replaced with dynamic one, pulled from these records. Process established to discover and evaluate the currently available mobilefriendly databases included in our licensing. Phase 3: Mobile-friendly database status included in selector and collection services evaluation of databases, including a button added to the Networked Resources Central Funds Request web form Utilization evaluation of the mobile devices (ideally along with an evaluation of the library mobile services as a whole) Specifically concentrating on whether the extra costs associated with some mobile-friendly sites are justified. Further Reading Arroyo-Vázquez, N. (2009). Web móvil y bibliotecas. (Spanish). El Profesional de la Información, 18(2), 129-136. Fox, M. (Last Update April 14, 2010). Mobile Technologies in Libraries. Available at Murphy, J. (2010). Using Mobile Devices for Research. Online, 34(3), 14-18.

Additional Information and Recommendations

Eyes-Free Use of Mobile Devices Mobile device developers have been proactive in creating functional applications for visually challenged users. Google Android, via their open source Project Eyes-Free, has fostered the development of a variety of applications that aid with eyes-free use of the mobile devices that run the Android operating system, known as the eyes-free shell. Using the shell, users can launch talking applications with simple click navigation which can give them information ranging from knowing your location (GPS) to the state of the device (battery power, WIFI). Apple’s iPhone 3GS features the VoiceOver application, a gesture-based screen reader which allows users to hear a description of what is under their finger. While developing a mobile library site, it is recommended that standard best practices for ADA compliance be met. Further Reading: Helft, M. (2009, January 3). For the blind, technology does what a guide dog can’t. The New York Times. Retrieved from usiness

Appendix 1 Task Force Charge To: Invited Members of the Mobile Devices Task Force From: Karen Hartman, Sara Harrington, and Natalie Borisovets Re: Invitation and Mobile Devices Task Force Charge Date: December 16, 2009 The User Services Council (USC) and the Library Resources Council (LRC) are forming a Joint Task Force on Mobile Devices. The work of this Task Force will contribute directly to both Councils’ goals for the 2009-2010 year. The Task Force will be asked to examine and report on the implications of mobile devices on the Libraries existing and emerging services, on current and future collections, and on the website. We also request that the Task Force consider issues relating to accessibility and security. As a part of its work, the Task Force is asked to consider relevant scholarly literature. The work of Professor Katz , Founder and Director of the Center for Mobile Communication Studies at the Rutgers School of Communication and Information (SCI), the recent ARL Bimonthly Report entitled “Mobile Technologies, Mobile Users: Implications for Academic Libraries,” and the recently published title New Technologies, New Pedagogies: Mobile learning In Higher Education (University of Wollongong, 2009) may provide useful points of departure. The Task Force may also wish to consult widely with Rutgers University Libraries faculty and staff in order to benefit from the experience and expertise of those who are not directly serving on the Task Force. The Task Force is also asked to examine the work of other institutions, including peer and aspirant institutions, and the work of leading institutions in the use of mobile devices. It may prove useful to look at actual devices and define the range of devices covered by the work of the Task Force. The Task Force will limit its examination to handheld mobile devices that have a web browser. (changed: 2/9/2010).

The Councils would like to request that the work of the Task Force conclude with a written report with recommendations and an action plan. We would like to ask that the Task Force submit its report on or before May 30, 2010. This is a draft charge. As the Task Force’s work evolves, members may see fit to revise the charge as necessary. Kindly share the timeline and other feedback with the LRC and

USC chairs as the Task Force proceeds through its work. Kindly prepare meeting minutes that can be shared through the RUL everyone listserv. After the final report is completed, the Task Force will be asked to present the report to LRC and USC and perhaps to a gathering of RUL faculty and staff. We are writing to you at this time to invite you to serve as a member of the Task Force on Mobile Devices. After the full membership is constituted, the task force will be asked to choose a chair.

Appendix 2 ARL Institutions with a Mobile Presence The following is a list of the 19 ARL institutions that have developed a mobile library site. RUL peer/aspirant institutions are in bold. University of Alberta Libraries Auburn University Libraries Boston College Libraries Brigham Young University Library University of British Columbia Library Duke University Libraries University of Illinois at UrbanaChampaign Library University of Iowa Libraries McGill University Library Massachusetts Institute of Technology Libraries University of Minnesota Libraries

University of Missouri– Columbia Libraries  

New York Public Library

University of North Carolina at Chapel Hill Libraries North Carolina State University Libraries University of Pennsylvania Libraries Rice University Library University of Rochester Libraries University of Virginia Library