Mobile Libraries - Gregynog

307 views

Published on

*Best viewed with the the annotated notes tab below (slides by themselves don't say much!)*

Talk from Gregynog (all-Wales IT conference), looking at options to integrate existing systems onto a mobile service at low cost - in the context of a mobile library project.

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
307
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • I'll be talking a bit about making existing services mobile friendly. I ’ m going to do it in the context of the last project we did - mobile library features. Sadly not what I thought when mobile library was mentioned. I ’ m also going to cover a bit about the project process we follow, as may be of interest. And lessons learnt. Photo courtesy BBC’s Shameless
  • We have a student portal. Sure everyone has similar. Libraries area asked us to get half a dozen library features on there - previously was all a bit disjointed, lots of different systems.
  • But at the start of the project we said, well, we ’ ve just launched the our mobile app. Lets increase the scope of the project to cover library features in both. And that ’ s probably the first lesson - not thinking of “ mobile projects ” , but rather sets of features and where to expose them - public web, intranet, mobile. That helps with architecture a lot - previously guilty of trying to build a lot inside the portal itself, or inside a mobile app. Focus on data & services instead. The view is just a light layer on top them.
  • So, at the start of the project, we got together with our library sponsor, and brainstormed what services to expose. Prioritised each based on most requested and most used services. We also 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. Noticed unis can move quite slowly. Get stuff delivered!
  • Ended up with this prioritised list. Then broke the work into 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. (use an amalgam of scrum & DSDM, if anyone interested in agile)
  • The first thing we did were some quick mockups.
  • We use 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.
  • Previously used photoshop, too high detail. Interactive prototypes with Axure type tools also good, but wireframes in this case were fine - not a massively complex project.
  • 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. There ’ s an obvious 5th too - just write something completely new in the mobile app/site itself. 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. You drop out of the “app” - but people have back buttons, it’s the web...
  • Ask a Librarian is our librarian chat service - students can ask questions and get instant answers. Really 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. Also generally a good sign of decent architecture. *redacted business system name*, bad API. So bad we write our own that talks to the db instead.
  • 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.
  • Third approach is called responsive design. Been around for last year or two, bit of a buzzword for web types. 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 ok) – importantly includes all the mobile browsers though.
  • He’s an example from dContruct, a web conference in Brighton. As we shrink the window size, notice particularly the photos and the menu navigation at the top. Typically desktop, tablet and mobile sized breakpoints.
  • Here’s Lancaster university, they recently redesigned. Believe Glamorgan are too for main site. Cardiff’s undecided for new main site yet. Arguments for and against. Theirs is a bit wonky in places with images – but it’s early days for this technique. No one’s quite worked out image resizing. While it something you would often do now with new websites, it’s a handy method to have in the toolbox of existing third party systems.
  • 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, with goes to a system called Voyager. 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 a simple media query to strip it right back to just the key 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 layer. It’s the same pages being served.
  • Close your eyes if you don’t like code. But that’s the bit of html 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.
  • 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.
  • 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. The plan is to push them down to a data service so can be shared between public site, mobile and so on. 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.
  • So those were different techniques used. That 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, as that was most used feature. And grouping of features, helps quickly scanning.
  • As an aside, this is the portal version in case interested. We push twitter a bit more there, as the screen space means can notice those when going to a link or checking your account. We’ve learnt a lot about twitter integration and approaches, caching, use of lists etc. But that’s another talk. Catch me sometime if want to know more.
  • In terms of metrics. Some qualitative in terms of feedback, so far positive, or more importantly little negative. But for quantative metrics.
  • Across the whole of the mobile app, email still most used feature – by a long way. But the library features are second most popular area, so seems to have been time well spent.
  • In terms of hard usage of the mobile app overall, here it is split by device. Android by some distance the most popular now. 70k visits, about double iPhone. iPad surprising amount. Blackberry, well, dead, RIM pulling out. Others we’re starting to see Windows Mobile pick up. That shows value of not doing native targeting specific platforms, landscape will keep changing.
  • And that’s it, our first batch of mobile library features. Any questions? Some of us were having a chat at the break, if there are other developers here, we’d like to get together for a developer meet... Photo (awesome) courtesy Shetland Islands Council
  • Mobile Libraries - Gregynog

    1. 1. MobileLibraries
    2. 2. Library Features
    3. 3. • Search• Renewals• Contacts & Locations• Ask a Librarian• Printer/Photocopier Balance• Twitter & Blogs• Video Guides
    4. 4. Mockups
    5. 5. ImplementingFour main ways of making a service mobile
    6. 6. Existing API SupportResponsive Screen Design Scraping
    7. 7. Easy PickingsExisting mobile versions - Twitter, Youtube, Ask a Librarian
    8. 8. APIPrinter and photocopier balance - MyPrint
    9. 9. Responsive Design Adapting search & accounts
    10. 10. <link href="phone.css" rel="stylesheet"media="only screen and (max-width:500px)">
    11. 11. Screen Scraping The dirty truth - blogs
    12. 12. In App Features Contacts & Locations
    13. 13. Existing API SupportResponsive Screen Design Scraping
    14. 14. Measuring Success
    15. 15. • Email• Library3.Find a PC Most Used• Calendar Mobile Features• News6.Maps
    16. 16. Mobile App Usage Since Jan 2012
    17. 17. Questions?@JohnGreenaway Mobile Libraries

    ×