Mobile that works for your library

1,494 views

Published on

An overview of the various options for "going mobile"

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,494
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Mobile that works for your library

  1. 1. Mobile that works for your library Jeff Wisniewski Web Services Librarian University of Pittsburgh facebook.com/wisniewski.jeff
  2. 2. Why go mobile?
  3. 3. State of the union
  4. 4. Development • User needs • Functional and content specs • Interaction design/IA • Testing • Visual design • Development • Testing • Done
  5. 5. Dimensions • Ease of development • Usability and UX • Ease of testing • Ease of deployment • Ease of measurement • Ease of updating
  6. 6. Options 1. Native app 2. Mobile web 3. Hybrids
  7. 7. Native app • Lives on the device • Downloaded to the device • Built specifically for that device/platform • Built using some programming language and SDK
  8. 8. Native app Companies Must Have An iPhone App or They “Don’t Exist” -Walker Fenton, GM of NewsGator’s Media & Consumer Products
  9. 9. Native app programming languages Java Objective C
  10. 10. Mobile web • Lives on a webserver • Accessed by a device • Browser as software interface
  11. 11. Mobile web languages • HTML, HTML5 • CSS • JavaScript
  12. 12. Hybrids  Generally use languages familiar to web developers – HTML – CSS – JavaScript  Installed like a native app
  13. 13. Hybrids phonegap Appcelerator Titanium rhomobile MotherApp boopsie netbiscuits
  14. 14. Ease of development • Native apps require coding in non-web languages • Mobile web uses HTML, CSS, JavaScript • Hybrids often use web languages
  15. 15. Usability and ux Subjective Apps rated more favorably than mobile web speed/latency click investment usability highly influenced by browser
  16. 16. Usability and ux Objective: “App users…suffered much less misery than users in our mobile website tests (Nielsen)” – platform optimized – strong guidelines and conventions
  17. 17. http://www.readwriteweb.com/archives/consumers_find_m obile_web_disappointing_slow_to_load.php#more (2009)
  18. 18. Ease of testing • Test paper prototypes • Mobile web site easiest to test – Accessible everywhere – Desktop, simulators, emulators • Native apps – Tested in SDK – Install to test, refine, reinstall, repeat • Hybrids..test in cloud
  19. 19. Ease of deployment • Native apps deployed via mediated process • Hybrid either via direct download or via app store • Mobile web instantly deployed
  20. 20. • June 2009 Google Voice app submitted to Apple • July 2009 app rejected • January 2010 Google Voice via mobile web launched The curious case of Google Voice
  21. 21. Ease of measurement • Apps require special analytics tools • Mobile web can leverage existing web metric tools
  22. 22. Track activity in your mobile apps(Android and iOS only) http://code.google.com/mobile/analyti cs/
  23. 23. Ease of updating • Native app: cyclical • Hybrid app: depends • Mobile web: instantaneous
  24. 24. Native apps: the good • Responsive • Persistent • Automatically “bookmarked” • Built-in marketing via app stores (caveats apply) • Instant one-click access COOL
  25. 25. Native apps Level of commitment ….but more “casual dating” than “till death do us part”
  26. 26. 35% of adults have cell phones with apps, but only two-thirds of those who have apps actually use them -http://pewinternet.org/Reports/2010/The-Rise-of-Apps- Culture/Overview.aspx
  27. 27. Native apps: the bad • Fragmentation • Walled gardens…often don’t play with other services • The best tend to be single function…are we single function? – Gmail app, Maps app, Google Navigation app
  28. 28. My dad got a Sprint EVO 4G last weekend and texted me asking why Pandora, which he was excited about downloading, needed access to his contact information (when you download an Android app you get a nice little list of things the application has access to on the phone). I told him I didn’t know, and he subsequently decided he didn’t want to download it. -Stacey Higginbotham, GigaOM
  29. 29. Native app got game • Performance • Offline use • Deep integration required…GPS, camera, etc. • Monetization
  30. 30. Why mobile web? • No child left behind • Findability via mobile search (can submit to google) • No approval process • Familiar technologies…HTML5, CSS, JavaScript • Integration between desktop and mobile – Fennec
  31. 31. Why not mobile web? • “If you don’t have an app you don’t exist” • 19 flavors +- of WebKit • How many clicks? • Not persistent
  32. 32. Why a hybrid? • Develop with familiar technologies • Persistence of a native app • Al Gore told me to
  33. 33. Why not a hybrid? • Still platform dependent
  34. 34. Platform proliferation • Today: iPhone, Android, Blackberry, iPad? • Tomorrow: WebOS, Windows Phone 7, Android tablets, Blackberry tablet(s), Windows tablets…..??
  35. 35. Cool tools…code free • Hidden peanuts MSG http://www.hiddenpeanuts.com/ msg • Widgetbox mobile http://www.widgetbox.com/mobil e/
  36. 36. Questions & discussion? Kthxbai 

×