Your SlideShare is downloading. ×
Asist mit 2012
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Asist mit 2012

213
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
213
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Lessons Learned: TheEvolving Nature of Mobile WebsitesPresented for The New England Chapter of ASIS&T (NEASIS&T) by Edward Iglesias Systems Librarian, Central Connecticut State University
  • 2. Assumptions• You already have a mobile website• You have developed it in house• This is part of your overall mission/strategic planning
  • 3. After you have a mobile website• Who is your long term team?• Do you have written documentation?• What happens when someone leaves?• Can you sustain the service?• How do you cope with change?
  • 4. Who is your long term team?• This may be different from the group that created the first mobile website.• Will there be an app o iOS o Android o Windows phone?• Who is in charge of evaluation and testing? o Must be retested with users with every new iteration o Must have analytics to show use o Must take in new data constantly (self motivated, autodidacts)• This determines your team
  • 5. Composition of Team• Should be composed of folks who have authority to make changes to the website.• Should focus on technical expertise primarily and marketing of services secondly.• Should have input from but not be dictated to by the rest of the library.• They know better, trust them!
  • 6. Documentation• Who is in charge of writing it? o We hired someone• Where is it kept? o Internal wiki? o Who maintains it?
  • 7. Continuity• Our story o We had a brilliant web developer o Did our mobile site o Wrote an android app o Wrote an iOS app o He got a new job• Hired a new brilliant web developer o She understands his code but changes happen.
  • 8. The wrath of the Kiosks• We decided to use iPads as way finder kiosks Yes, I know it’s crooked.
  • 9. Our existing mobile website
  • 10. But, we hired someone smart• Could be optimized differently for iPad using the same source date.• Wayfinders inherently different.• So …
  • 11. New wayfinder UI Bigger buttonsFocus onMaps
  • 12. Which led to
  • 13. Currently working on• Map overlay issue o Works in iOS o Not in Android• Do we create another site?• How will this affect tracking?
  • 14. It’s Okay• Downtime and new iterations part of the process.• If you don’t plan on bumps in the road you will be thrown off.
  • 15. Going Forward• Keep iterating• Keep learning• Keep changing
  • 16. Remember the rules• From Eric Raymond’s the Cathedral and the Bazar o Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. o Release early. Release often. And listen to your customers. o Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, ``Given enough eyeballs, all bugs are shallow”. • http://www.catb.org/~esr/writings/homesteading/cathedral-bazaar/