Code4lib Day 1: Kill the Search Button II – The Handheld Devices are Coming

by Michael Poltorak Nielsen, Statsbiblioteket/State and University Library, Aarhus, Denmark

Current Mobile Interaction Paradigm

You do a lot with your hands, everyday. Our hands are a really good tool, but currently, the handheld interaction is based on glass. That is you do functions by sliding your fingers, which means there is no feedback on what it does, i.e. it’s not intuitive.

Take a look at Pictures Under Glass: Transitional Paradigm dictated by technology, not human capabilities by Bret Victor.

An Alternative

  • direct manipulation
  • gesture driven
  • palpable
  • tactile

Smartphone Gestures

The near future may mean combining something like the Wiimote and the iPhone.

Mobile Projects

The idea was to build an HTML5 app that searches library data, favourites, view own items, renew, and request. Currently in beta, but to be published soon.

The search app can be augmented with gestures, gestures combined with multi-touch interactions.

Possible interactions with focus on

  • keyboard – typing
  • microphone speech
  • screen – touch, visuals
  • camera – pattern, movement
  • accelerometer – acceleration
  • gyroscope – rotation
  • compass  – direction
  • GPS – movement, position

Gestures

Might include simple ones using accelerometer data, including

  • tilt
  • flip
  • turn
  • rotate
  • shake
  • throw

The problem is that gestures are only really supported by Firefox, and partially supported by Chrome. Thus, it was decided that development would move to the native iPhone app environment with gestures, and HTML5 web app without gestures (but possibly later when supported). Features that are implemented include:

  • Restart search – face down
  • Scroll – tilt up and down
  • Switch views – tilt
  • Request items – touch and tilt left
  • Favourites – touch and tilt right

Check out the demo:

Challenges

  • no standard mobile gestures
  • gesture maybe individual
  • gesture may not be appropriate at all
  • sophisticated gestures are hard to code
  • Objective-C

Code4lib Day 1 Morning: HTML5, Microdata and Schema.org (and other takeaways)

I did not take notes on everything in part because some of it was very technical and it can be hard to do notes, but here are some takeaways from the morning:

  • Versioning Control: Use it, Git or Mercurial. Doesn’t need to be code, can be data too. – Description and Slides
  • Take library data and make it available to users, can’t expect them to search for it.
  • Linked Data doesn’t need to be a huge project. Start small.
  • Why RDF? It’s flexible with easy addition of new attributes or classes, and works cleanly with an iterative approach.

HTML5 Microdata and Schema.org

by Jason Ronallo

Other than getting good ranking, we need to provide rich results, i.e. rich snippets. Some digital collection have been providing rich snippets already, such as NCSU Libraries.

How do we get this?

  • embedded semantic markup
  • HTML5 Semantics include nav, header, article, section, footer
  • HTML5 Microdata is a syntax for annotating content to communicate meaning of data to machines
  • similar to RDFA, other microdata
  • Microdata comes back as tree based JSON and allows for DOM API

For example:

<div itemscope itemtype=”http://schema.org/Organization&#8221; itemref=”logo”>
<a itemprop=”url” href=”http://code4lib.org/”&gt;
<span itemprop=”name”>Code4Lib<\span>
</a>
</div>
where: scope = about something
type = type of item
prop = properties

For the user, there is no difference as display is the same. This provides a complete data model.

Schema.org  is a one-stop shop for vocabulary in describing items on the web.

Apologies, I did not take extensive notes on it, but to read more, check out the slides below or the Code4lib article he wrote.

Code4lib Day 1: Keynote on Code4libcon

Daniel Chudnov from George Washington University was the first Keynote of the conference.

Dan began with a bit of an introduction and then went into a very touching overview of the story of his family and his life. His life lesson was that

things fall apart.

We Blew It

We have turned away too many people: way more than 100 people. That was a terrible mistake. If we don’t address this mistake, this [conference] is not going to last.

Code4lib was inspired by Access, with some key aspects:

  • single track
  • participatory
  • social
  • beer
  • fun

The difference the organizers wanted was a (possibly) geekier version in the USA in Spring (so as not to compete with Access). What might have really pushed this discussion is that

we turned away more people in 2012 than attended in 2007.

Why? The most common answers revolved around the capacity of venue. There were of course, some other concerns about keeping it a small, informal, participatory conference that were expressed, especially in the backchannels (IRC and Twitter).

Nevertheless, Dan asked the key question “Why do you come?” He expressed how he comes to connect with people, and hang out with the attendees, and there are many others that wanted to join, but were turned away.

He went on to talk about how while there is a chasm of techies vs. non-techies, there shouldn’t be. Plenty of people want to learn what coders do, and as a group, we should want to help respond to change constructively. They want to code, and we should connect and work more closely with them. We have one choice to make:

HACK OR DIE

We Must Expand

Dan used PyCon as a possible a good mode to follow. They have:

  • 2 days of pre-conference tutorial days
  • up front training for all levels
  • 4 days post-conference sprint days
  • back-end collaboration for all levels
  • plenary talks, plenary lightning
  • multiple tracks

Dan was against multiple tracks for many years, but not anymore, because

we need to connect or this thing we have will fall out from under us.

His point is that next year people won’t even bother if there is no clear statement to make things work.

Challenges

  • break complacency
  • lack of proposals to host
  • too heavy a burden on local organizers

Possible Solutions

Committees need to be formalized, especially an advisory committee of former hosts to help future hosts. The work needs to be done through the year, and more open like it used to be. Dan also suggested a formal program committee to replace the “diebold-o-tron”, but there was some disagreement because it’s less participatory.

Some other ideas included a multi-core code4lib where each regional group would be 1 hour live streaming on the same day, and the BarCamp approach where there are no pre-planned presentations, which might work for regional code4lib conferences. However, concern was expressed with having too many small conferences organized, burning out possible hosts for the annual code4lib.

The next code4lib conference should aim for 500 people.

Chicago is ready. Are you?

Final Notes & Thoughts @ Access 2011

So I didn’t do a full post for all the sessions, but the live notes that were taken and presumably, video recordings will later be posted on the Access 2011 website.

Data Visualization

Jer Thorp gave a great talk on the data visualization work he’s done and has been working on at the New York Times. I couldn’t really take notes since so much of it was visual, but he blew a lot of minds with his work, so check out his blog.

My Lightning Talk

What really excited me beyond the work itself was the fact that he mentioned he was doing it all through Processing, so I decided to do a lightning talk to introduce everyone to Processing and more importantly Processing.js.

For those who aren’t familiar with it, Processing is an open source programming language primarily used for dynamic and interactive graphing and data visualization. Processing.js is the sister project which brings processing to the web. What’s the greatest part of processing.js is that a developer can start doing the same sort of thing but from the JavaScript side.

Check out the demos to see what kind of things you can possible do. I am particularly interested in the educational applications, such as giving students interactive graphs to see how mathematical functions work (see the Bezier Curves tutorial).

Added value: web accessible, Drupal plug-in, WordPress plug-in, fun games like a remake of Asteroids on the exhibition page.

See Access Live Notes for Lightning Talks and talks about other tools.

Digital Preservation

  • what does digital preservation mean? preserving more than objects and items
  • think on scalability
  • preserve what matters
  • start with policy and practice, not a platform
  • library can’t do it alone, partner with IT, Archives, etc.
  • need to think strategically
  • no one answer
  • some good tools
  • get started
  • think about what we can do with partnership

Fail Panel

The fail panel was great, because there were a lot of great stories by the panelists and others. Here are some of the lessons learned from the fail stories.

  • bleeding edge is not always great
  • good escape clauses to get out of bad situations
  • make sure company is stable
  • don’t make thematic websites – not scalable
  • don’t be working on original records or have a backup
  • never trust a tech
  • if you think it’s a bad idea, speak up
  • don’t have a project driven by one person
  • sometimes there isn’t a tech solution
  • make sure you press the right button
  • need to make sure

Share your own stories at failbrary.org

Thoughts

This was actually my first conference, but I think (and I’m clearly not the only one) it’s been really well put together and the food has especially been awesome, many within great socials. There’s been some tech fail, but that’s expected at every place I think.

I have particularly liked this conference because rather than simply having speakers talk, everyone has been highly encouraged to participate in some way (i.e. hackfest + presentations, lightning talks). I never though I’d be speaker at a conference, especially my first, but with the nature of the talks and encouragement of people got me to do a lightning talk. I think that alone speaks loads to the community.

It’s been an awesome experience, I’ve learnt a lot, and met a lot of great people. I really hope to be able to attend the next one.

Access 2012

Sad to see Access 2011 end, but for next year, a  site will be set up to see who will host it, and the planning of the conference will be continued code4lib style.

Role of Vendors in Open Software Ecosystem @ Access 2011

Marty Tarle from Bibliocommons came to talk about a vendor’s perspective on the open source environment. From the chatter going on, not everyone agreed with everything he talked about, but that would almost be expected with a crowd that seems to have many very big open source supporters. Here are the major points that I jotted down.

Typical Library Software Ecosystem

  • lots of components
  • some open source software
  • lots of proprietary software
  • all needs to work together

Perception of Proprietary Software Vendors

  • perceived as closed and inflexible
  • lack of APIs, difficult to integrate with
  • long development cycles

If this is true for you, then you’re not working with the right vendors. Vendors should be committed to what the users need.

Focus is Often on the Wrong Things

  • open sourcing – think that any changes can be made, but inefficient and costly without vendor buy-in
  • standards support – but standards out of date and limited
  • direct access to data – think can do whatever want with data, but tremendous duplication of algorithms, infrastucture, operations

Focus Should be on Vendor Cooperation

  • interoperabililty is a two-way street
  • vendors need to
    • proactively enable integrations
    • proactively integrate other solutions into theirs

Vendor Development & Delivery Models

  • development
    • agility is critical
    • scrum and lean are now the norm
    • long development cycles are unacceptable
  • delivery
    • rapid deployment of new functionality
      • a lot of it is underlying architecture and a lot of testings
      • being open and flexible
    • rapid scaling of hardware
    • industry trend is towards “continuous deployment”: narrowing the gap between conception and production plus building the analytics to see whether it’s working

Vendor Culture

  • openness = part of company DNA i.e. being invested in client success
  • integration = core organizational capability
  • openness = proactive, continuous effort

What to Ask Your Vendors

  • pace of innovation
    • how many releases
    • how many notes
    • development model
    • delivery model
  • API
    • public
    • scalable
    • flexible
  • ask about attitude towards open source, whether used any, etc.

Best of Both Worlds

Best to use combinations from both worlds e.g. Evergreen + Bibliocommons

Partnership

Vendors and open source communities can work together. What makes a partnership successful?

  • communication
  • transparency
  • accountability on deliverables
  • shared success

Evergreen ILS Undressed @ Access 2011

A panel of speakers presented on different aspects of the Evergreen ILS during today’s session. Speakers were:

The Sitka Perspective

  • 54 libraries in BC
  • consortia model
  • think about the end user first
  • multi-faceted selection criteria
  • check with your colleagues about your ideas
  • every ILS is a work in progress
  • got equinox to teach them to fish
  • now they teach others to fish

Why Open Source? The Community

  • community is a powerful thing and driven by the community
  • vibrant, growing community
  • who do you want to be involved with?
  • plus you can have control

Examples

  • centralized policy and way to push out to staff computers
  • localize view for search results
  • easy to access data and pull data for reports and visuals
  • mobile OPAC using an open web services API to add My Account functions (still in development)

Sneak Peak to Evergreen 2.2

  • increased flexibility for MARC match set editor
  • authority control sets, ability to customize control set

Join Us!

  • Evergreen 2013 in Vancouver!

Implementing Open Source ILS @ Access 2011

Matt Carlson, ILS Administrator, from King County Library System and Grace Dunbar, COO, from Equinox talked about implementing Evergreen ILS at King County.

Why a New System?

  • many reasons, wanted to have more control over tool that everyone was interacting with
  • a lot of development
  • buy in is hugely important: demos with all branches, took Evergreen on a road show
  • might provide new features

Are you ready for [the OSS]?

  • and Is [the OSS] ready for you?
  • is there a test server with a stable release
  • do a gap analysis – software dependent? or workflow dependent?
  • are gaps major or minor?
    • major gaps = large development projects e.g. missing acquisitions module
    • minor gaps = if missing, be creative e.g. receipt not printing exactly the same way
  • Have the resources i.e. developers in-house? If not, you may have to outsource (how Equinox got involved)

Requirements

  • what do you really need?
  • requirements: don’t have staff sit down and say what they want, use
  • use cases – no edge cases, focus on what people do
  • workflows
  • focus on outcomes, not processes
  • be specific

Finding your development partner(s)

  • engage the community via irc, mailing lists, conference
    • evergreen conference is in Vancouver in 2013
  • look locally (other OS projects, students, GSoC participants, etc.)
  • write an RFI or RFP: if want OSS, rethink how RFI/RFP is written because companies don’t own software, provide service
  • request a quote from a vendor
  • may need consultant to help

Contract

Be specific in:

  • hours estimates
  • costs
  • ownership of work
  • documentation
  • interaction with community: make sure that contributions/development work will be accepted, local customizations can be the death of a system
  • deliverables
  • milestones
  • testing/sign

Client Perspective

  • challenges
    • communication
    • scope creep: important to assess input, but cannot just keep adding things
    • be realistic about time for testing, clarifications and feedback
  • best practices
    • update your project plan
    • build a team of subject matter experts
    • provide real examples, use cases and mockups whenever possible
    • never too soon to start thinking about your go live timeline and identify dependencies

Vendor Perspective

  • challenges
    • multiple clients/projects competing for time
    • communication: keeping communication restricted to need to talk to people, while making sure community is kept in , while making sure the feedback can get back up in a meaningful way
    • use cases and mockups: drawings can solve a lot of problems
  • best practices
    • 1-to-1 project managers: one from client side, one from vendor side
    • clear, shared objectives (client/vendor/community)
    • set priorities: something will get changed or not implemented, so set top 5 things

Test

  • create a test manual and use it
  • engage staff and patrons in creative solutions
  • will need a test server for testing and training
  • have an exit strategy

Stay on Target

  • still stick to priorities
  • functionality is key, outcomes work?
  • can always make tweaks later
  • must have plan B, no plan survives initial contact!

Training

  • managers aren’t necessarily trainers: critical to find the right trainer
  • set aside mandatory time: absolutely needed! Something that people will be interacting every day
  • structured feedback is critical, so that feedback is meaningful
  • have a plan for on-going training: new staff, staff that couldn’t attend, changes that come along that need refresher

Implementation

  • implement in phases, whenever possible
  • have a fall back position: rollback to previous version, hot spare, offline mode, handwritten checkouts, smoke signals – communicate fall back plan to staff (aware of procedure, etc.), make sure patrons know you’re doing something new
  • change is hard: celebrate

Take Aways

  • Don’t… freak out
  • Do… have fun, this thing you’re doing is really cool!
  • Do… have a life outside this project

What’s Working and Not Working Now

  • things have gone very well
  • implemented many changes, several upgrades
  • minimal downtime, had some bumps
  • still some features still not there yet

Koha – Free Software & Community @ Access 2011

Chris Cormack from Catalyst IT is one of the founders of Koha, an open source ILS, and one of the lead developers. He gave a talk on Koha today, but focused more on the free software, caring, sharing, and community.

Free Software

  • freed to run the program, for any purpose
  • freedom to study how the program works, and change it to make it do what you wish (access to the source code is a precondition to this)
  • freedom to redistribute copies so you can help your neighbour
  • freedom to distribute copies of your modified versions to others

Why Free Software?

  • end goal is freedom
  • open source puts the emphasis on the development model
  • free software puts the emphasis on freedom
  • free software allows to weed, expand collection, and share

Koha

  • pile of code and documentation
  • more importantly, Koha is a community
  • widespread, fairly sized community with159 committers from every continent except Antartica
  • 35% women, partly because librarianship dominated by women, partly because of how it developed
  • 11+ years of development and an average 3.7 commits/day

Background

  • New Zealand libraries had a suboptimum ILS, and was not legally allowed to fix it
  • wrote RPS and got responses, but none worked for their requirements
  • some requirements were unique to New Zeland e.g. had to work on phone lines because of electric fences
  • decided to develop their own

If you would like to know more, there is a code4lib article on its forming.

What to do when things go wrong

Chris Cormack also gets extra thumbs up for encouraging library students to report bugs as part of their assignment by giving us chocolate! I will have to post our Koha vs. Evergreen Circulation Module Evaluation later.

Big Data (in Libraries) @ Access 2011

MJ Suhonos and Peter Van Garderen from Artefactual Systems did a talk on big data in libraries. In particular, I was interested in some of the points MJ talked about on big data. Here are my notes:

  • relative: 1980: 2.5GB = big data
  • definition: datasets that grow so large, become difficult to work with
  • big data is… big, and complicated
  • maybe we’ve simply been putting a square big in a round hole
  • don’t believe the cloud hype
  • big data is less about size, and more about freedom
  • open source tools + distributed design = new opportunities