Cardiff Uni - International M-Libraries Conference 2012
•Download as PPT, PDF•
1 like•557 views
Presentation at International M-Libraries Conference 2012 from Cardiff University. Cover some different approaches to presenting services on a mobile - in the context of a recent project at the uni. http://www.m-libraries.org/
More Related Content
Viewers also liked
Viewers also liked (10)
Similar to Cardiff Uni - International M-Libraries Conference 2012
Similar to Cardiff Uni - International M-Libraries Conference 2012 (20)
Recently uploaded
Recently uploaded (20)
Cardiff Uni - International M-Libraries Conference 2012
- 2. Cardiff! 30,000 students 6,000 staff 17 libraries
- 4. Library Llyfrgell Ask a Librarian Gofynnwch i Lyfrgellydd
- 8. Search Renewals Contacts & Locations Ask a Librarian Find a Pc Printer/Photocopier Balance Twitter & Blogs Video Guides
- 9. Mockups
- 11. Implementing Four main ways of making a service mobile
- 12. Existing API Support Responsive Screen Design Scraping
- 13. Easy Pickings Existing mobile versions - Twitter, Youtube, Ask a Librarian
- 15. Ask a Librarian (uses LibraryH3lp)
- 16. API Printer and photocopier balance - MyPrint
- 18. Find a PC (uses own API)
- 19. Responsive Design Adapting search & accounts
- 22. <link href="phone.css" rel="stylesheet" media="only screen and (max-width:500px)">
- 25. Screen Scraping The dirty truth - blogs
- 27. In App Features Contacts & Locations
- 29. Existing API Support Responsive Screen Design Scraping
- 32. 1. Accounts 2. Search 3. Find a PC Most Used Library 4. Ask a Librarian Mobile Features 5. Locations
- 33. 1. Email 2.Library 3. Maps Most Used Overall Mobile Features 4. Calendar 5. News
- 34. Questions? John Greenaway Cardiff University Mobile Libraries
Editor's Notes
- I’m John, from Cardiff University. I’m not from the libraries area, I’m the web development manager. But one of our most recent projects was adding library features to our mobile site. I’m going to run through the different techniques we used to get existing services on there in a relatively short space of time.
- Quick background for those that don’t know Cardiff. We’re the capital of Wales and the largest university in Wales. Around 30,000 students, 6,000 staff, and we have 17 university libraries. Have some web history - IMDB started there.
- We’re also unusual in the UK as we’re bilingual – observant people might have noticed the logo.
- If you learn nothing else from this talk – here’s some Welsh. Library is Llyfrgell, Ask a Librarian is… that.
- Anyway, we also have a mobile site. It’s a site rather than a native app. And written in house rather than bought in. Launched this time last year.
- Also available in Welsh. We went web as we wanted to reach as many users as possible. And like most universities – not a huge development team. We know the web. We can add features instantly. We can do it bilingually – very few 3 rd party apps handle multilingual well. 250,000 visits in the year since launched.
- Around Christmas, we decided to add some library features. Met with the subject librarians to brainstorm. We wanted a short project, so picked features achievable in a few weeks. Something learnt on original mobile project - release quickly and early. Even more on mobile. Avoid one year projects. Landscape moves too fast. Be pragmatic and get something out there – get feedback, then iterate.
- Ended up with this prioritised list. Then broke the work into 1 week iterations, with a couple of features in each. The idea being after each iteration the project could in theory be released or ended. Keep quality, time and cost - just vary scope.
- The first thing we did were some quick mockups.
- We do paper mockups, but also a tool called Balsamiq Mockups. Deliberately lofi and handdrawn. People focus on interaction & features. Not fonts or colour. Lot of people liked this. Also makes explaining features easier than just written descriptions.
- So at this point we know what we ’re doing, the order, and some guidelines user interfaces. To actually get the stuff work, there are 4 main techniques (more really), we used a bit of each of these.
- Existing support or way to link to a mobile theme. Might be an API to talk directly, or other low level integration like direct to DB. Newer technique called responsive design. Then old fallback screen scraping. We did a bit of all of these on this project.
- For some things, there’s already a mobile friendly version.
- Twitter and Youtube, both have decent mobile versions already, no point reinventing. Writing your own normally has less functionality - seen some terrible twitter feed implementations, can ’t interact, follow, anything.
- Ask a Librarian is our librarian chat service - students can ask questions and get instant answers. Very popular. 3rd party widget, company called libraryh3lp. Has a mobile theme, just a parameter. Sadly comes with that green button. Some concern that this may get some dodgy usage - drunk students, mobiles etc. Seems to have been fine though.
- If a system doesn’t have mobile support, then it might have a API. Probably the next choice. This means your application can talk to theirs behind the scenes. As developers we love this – it’s become the main criteria for evaluating systems. Good API = we like it. Library systems vary hugely.
- Luckily libraries chose a system called PaperCut for managing printer and photocopying accounts in the libraries. And it’s got a really good, clean API. That means we can just display the credit balance right in the app. Sadly they don’t provide a way to top up. So we’ve include maps of the nearest pay station locations.
- Our Find a PC section uses the phone’s GPS to work out nearest free PCs. Then a map and directions. We call it an API – it’s just a text file that gets updated on a server each minute. We use that same API in plasma screens in libraries and on mobile. Washing machines.
- Third approach is called responsive design. Been around for last year or two, bit of a buzzword. Here you use stylesheets to adjust the page based on the size of the screen. Only newer browsers support, typical IE is the one lagging (IE9) – importantly includes all the mobile browsers though.
- Here’s a full website example – it’s our library & IT handbook. That’s it on a desktop.
- And this is it on a narrower mobile. Exactly same page, just CSS styles it differently.
- Close your eyes if you don’t like code. But that’s the bit of html needed at it’s simplest. Just says pull in a different css stylesheet if the window is less than 500 pixels wide. Adding that to a page is the only change needed to a 3 rd party system. Rest of your code is in that css file.
- If you’ve a system with no mobile friendly version and can’t use an API, but have access to the HTML templates, you can do some basic responsive work. Here we’ve got library search. Goes to a system called Voyager from Ex Libris. Quite old, pre mobile system. On the right is a results page from Voyager. Normally it would have headers, footers, navigation bars. We’ve used responsive design to strip it right back to just the content.
- Same with library accounts, stripped right back. Has one big advantage over APIs – you don’t need as much testing – not writing a new application or user interface. It’s exactly the same pages being served. Very good to crowbar mobile support into older systems.
- This is bad. Dirty. Horrible. Should never be used. But it’s used quite often, and does work. If there’s no mobile version, no API, no access to templates, then you’re pretty much down to this.
- For news and blogs we use this, also uni-wide contact search in the main section of the app. On the server side we pull back the web page, parse HTML, extract the content bit in the middle. Works – obviously brittle, HTML changes could break. But – no change at all to external system, don’ t need any access.
- There is a fifth way of course, actually writing the feature in the app itself. Downside is harder to reuse, but on other hand, can do anything.
- For locations and contacts, these are just in the app itself. You can do nice things on a mobile, so in maps if you tap directions will use the GPS to give step by step walking directions from current location. Email or call will trigger the email client or start a phone call. All that’s just HMTL.
- So those were different techniques used. The project had a bit of everything. Benefit of in house development, don’t need to wait for supplier to give mobile support.
- Those are the finished features in the app. Some tweaks from the original wireframes – search built in on first page. And grouping of features, helps quickly scanning.
- In terms of metrics. Some qualitative in terms of feedback, so far very positive, or more importantly little negative. But for quantative metrics.
- Accounts is the most used feature – students can renew loans with a couple of clicks. More than search, which surprised us. Find a PC also popular. Twitter & videos less so, but they’re more pointers – once you know twitter feed exists, can subscribe then tend to browse in twitter client.
- Across the whole of the mobile app, email still most used feature – by a long way. But the library features are consistently the second most popular area, so seems to have been investment well spent. Seems to be what students want.
- And that’s it, our first batch of mobile library features. Any questions?