Code4lib Day 2: Mobile Breakout Notes

Just a few notes if anyone is interested:

  • digital collections tool: wolf walk, digital images
    • geolocation using JavaScript to make it availble in HTML5
    • find it easier in app store, means more people use app
  • HTML5 more clunky with jQuery mobile
  • native app smoother, especially Google Maps
  • mobile site: only force on homepage and opt out using query string
  • mobile app/site needs to be interoperable
  • designing: mobile framework better at bringing out ideas vs. developing web version of a website
  • how do you build up services? concentrate on what is needed on mobile devices
  • should have just what you need and do it well while taking advantage of mobile aspects e.g. bluetooth, GPS
  • how best to build?: REST layer on top of what’s available
  • time resource: if know objective C, then just adding functions
  • voice use: comfort level? accurate enough? difficulty with quiet/study areas/floors?
  • phone tap to reserve seats/room, other application?
  • staff use in stacks? Shelflister: barcode scanner inserts into web form for shelf reading or collection development, including circulation data
  • mobile hours: just give today’s hours or closed (give tomorrow’s hours)

Code4lib Day 2 Afternoon: Notes and Takeaways

An afternoon of more presentations, which were a bit more technical in terms of data indexing, storage, and use. As a result, there are no detailed posts, but here are a few notes and takeaways.

  • Be careful when you try to parse a bunch of files you download from the web. Parse and store, distribute up front, and build a test index first.
  • Making Software Work – read it
  • The results of one study is not the truth.
  • It’s hard to make a study repeatable.
  • Does agile work? That’s the wrong questions. Really, when does bug fixing has the highest cost?
  • High-risk bugs should be done as early as possible, instead of the easy bugs.
  • What language? Depends on the problem.
  • Make developer happiness hours. (block off time with no meetings)
  • Give people open sight lines instead of high cubicle walls.
  • Be as transparent as possible (e.g. JIRA) including progress.
  • Put projects into short iteration cycles.
  • No code without passing tests!
  • Slides (PDF) for the last talk: Practical Agile: What’s Working for Stanford, Blacklight, and Hydra by Naomi Dushay

In-browser Data Storage and Me

by Jason Casden, North Carolina State University

  • Suma: data collection application using in-browser storage.
  • Indexed database API (aka IndexedDB, WebSimple DB) is where things seem to be going, but limited browser support.
  • Web (DOM) Storage is basically universally supported.
  • Web SQ DB still viable option.
  • lawnchair: object storer, but have adapters for a long list of DBs/APIs.
  • persistence.js: asynchronous JavaScript object-relational mapper and adapters are being built out. Can be used with node.js and MySQL.

Slides

Code4lib Day 2 Morning: Notes & TakeAways

I didn’t take full notes on all the presentations. I like to just sit back and listen to some of the presentations, especially if there are a lot of visuals, but I do have a few notes.

Full Notes for the following sessions:

Building Research Applications with Mendeley

by William Gunn, Mendeley

  • Number of tweets a PLoS article gets is a better predictor of number of citations than impact factor.
  • Mendeley makes science more collaborative and transparent. Great to organize papers and then extract and aggregate research data in the cloud.
  • Can use impact factor as a relevance ranking tool.
  • Linked Data right now by citation, but now have tag co-occurrences, etc.
  • Link to slides.

NoSQL Bibliographic Records: Implementing a Native FRBR Datasotre with Redis

No notes. Instead, have the link to the presentation complete with what looks like speaker notes.

Ask Anything!

  • Things not taught in library school: all the important things, social skills, go talk to the professor directly if you want to get into CS classes.
  • Momento project and UK Archives inserting content for their 404s.
  • In response to librarians lamenting loss of physical books, talk to faculty in digital humanities to present data mining etc., look at ‘train based’ circulations, look at ebook stats.
  • Take a look at libcatcode.org for library cataloguers learning to code as well as codeyear hosted by codeacademy.

Code4ib Day 2: Stack View: A Library Browsing Tool

by Annie Cain, Harvard Library Innovation Lab

What’s the point?

Why recreate the physical stack? Why not just use a list? There are advantages to display books like books.

Advantages

  • If you have multiple branches, you can put all the materials into one shelf.
  • More visual, such as using page numbers to create thinner or wider images.
  • Add more information – color can represent such as frequency of checkouts.

How to Get Started

  • build HTML objects and draw using CSS
  • works as jQuery plugin
  • Start with book data – wrestle data out of your catalog, extract pieces you want and feed it into Solr, or use API, such as WorldCat
  • pump out stack view using JSON

Code available on github.

Q&A Comments

  • Usability testing gives mixed reviews. Librarians and those used to browsing the library are happy with it, but others don’t seem to care.
  • Experimentation with items other than books is to come.
  • No plans yet for catalogue integration as not much use case, but working on it.
  • Also take  a look at Chrome WebGL bookcase.

More information on available on the Harvard Innovative Lab website, and below is a demo.

Code4lib Day 2: How People Search the Library from a Single Search Box

by Cory Lown, North Carolina State University

While there is only one search box, typically there are multiple tabs, which is especially true of academic libraries.

  • 73% of searches from the home page start from the default tab
  • which was actually opposite of usability tests

Home grown federated search includes:

  • catalog
  • articles
  • journals
  • databases
  • best bets (60 hand crafted links based on most frequent queries e.g. Web of Science)
  • spelling suggestions
  • loaded links
  • FAQs
  • smart subjects

Show top 3-4 results with link to full interface.

Search Stats

From Fall 2010 and Spring 2011, ~739k searches 655k click-throughs

By section:

  • 7.8% best bets (sounds very little, but actually a lot for 60 links)
  • 41.5% articles, 35.2% books and media, 5.5% journals, ~10% everything else
  • 23% looking for other things, e.g. library website
  • for articles: 70% first 3 results, other 30% see all results
  • trends of catalogue use is fairly stable, but articles peaks at the end of term

How to you make use of these results?

Top search terms are fairly stable over time. You can make the top queries work well for people (~37k) by using the best bets.

Single/default search signals that our search tools will just work.

It’s important to consider what the default search box doesn’t do, and doubly important to rescue people when they hit that point.

Dynamic results drive traffic. When putting few actual results, the use of the catalogue for books went up a lot compared to suggesting to use the catalogue.

Collecting Data

Custom log is being used right now by tracking searches (timestamp, action, query, referrer URL) and tracking click-throughs. An alternative might be to use Google Analytics.

For more, see the slides below or read the C&RL Article Preprint.