Mobile that Works for Your Library

Talk by Jeff Wisniewski (University of Pittsburgh)

Yay! Time for talking about mobile technologies for the library! (We also have a virtual component for this session–very cool.) Oh, and don’t forget about the QR Code scavenger hunt.

Lots of ways to go mobile: we’ll be discussing different paths.

Why go mobile?
Estimated that within the next 5 years, that mobile internet usage will surpass desktop internet usage= “fundamental change in the landscape.” Smartphone sales are increasing and will outsell PCs by 2011, Need to be where are users are when they access the internet.

Major players in the United States
Android and iOs (iPhone). Android traffic has increased a lot–great growth. RIM= Blackberry, WebOS= smaller players in the mobile landscape.

Mobile browsers: vast majority on the most used platform are based on WebKit= share basically the same underlying structure which means developing is easier. (yay!)


  1. Figure out user needs first!
  2. Functional and content specs
  3. Interaction design/information architecture (IA)
  4. Testing
  5. Visual design
  6. Testing
  7. Done!

Options to becoming mobile:
Native app: live on the device, not a website, downloaded to the device, built specifically for that device or platform, built using some programming language (Java or Objective C). “Companies must have an iPhone app or they don’t exist”

Mobile web: lives on a webserver, accessed by a device, brower as software interface, design via HTML, JavaScript usually.

Hybrid: generally use languages familiar to web developers, installed like a native app (application wrapper), many companies offer this hybrid approach (phonegap, rhomobile, MotherApp, boopsie).

Ease of Development
Native apps require coding in non-web languages, mobile web uses HTML, etc.

Usability and User Experience (UX)
Subjective, apps rated more favorably than mobile web (right now): apps are one-click access, usability highly influenced by browser, apps are faster. Right now native apps are king, but this may be changing–especially with the rise of HTML5.

Ease of Testing
No real difference or winner in ease of testing. Do a lot of testing! Can use paper prototypes.

Ease of Deployment
Native apps are deployed via a mediated process (i.e. Android Market or App Store); hybrid either via direct download or via an app store. App store deployment= can take time. Mobile web is instantly deployed. Very little functionally that native apps bring to the table that is more than the mobile web.

Ease of measurement
Apps require special analytics tools; mobile web can leverage existing web metric tools (i.e. you can use Google Analytics on your mobile website). Use for tracking apps on Android platform, have to code it in the development of the app:

Ease of updating
Native app= cyclical, hyprid app= depends, can update some automatically via the web, mobile web= instantaneous.

Native apps
The good: responsive to user input; persistent on device; built-in marketing via app stores; instant one-click access; cool factor (people love apps); level of commitment to apps are more like ‘casual dating’ than ‘to death do us part.’ No guarantee that people will be big users of your app–lots of people download apps and never use them.

The bad: fragmentation of types of device platforms (what’s most popular today is not what may be most popular tomorrow); walled gardens–often don’t play with other services; the best tend to be single function-are we single function?

Hybrid apps
The good: easier to develop than native app.

The bad: the wrapper makes them platform dependent.

Mobile web
The good: “no child left behind”= any platform can access the mobile site; findability via mobile search (can submit it to Google); no approval process; familiar technologies (coding via HTML5, CSS, JavaScript); integration between desktop and mobile web (ex. Fennec for Firefox).

The bad: no app=don’t exist; many flavors of WebKit (differences in platforms); how many clicks to use; not permanent

Other issues
Tablets: lots of them coming out and need to design apps/mobile web that will look good on the tablets.

Tools for creating mobile apps
Hidden peanuts MSG
Widgetbox mobile

If you want your library to have a mobile presence, you need to weigh the pro and cons of creating native apps, mobile websites, or hybrids. Apps have the market in people’s minds, but they are more difficult to code (libraries may not have the code monkeys who can do it) and you need one for each platform/device. Libraries may want to look into optimizing their website for mobile devices or creating simple, functionally (beautifully designed) mobile web apps. Again, checking out HTML5 should be high on your list of priorities. Thanks for the whirlwind comparison tour, Jeff!

One thought on “Mobile that Works for Your Library

Comments are closed.