Tag: usability

Code4LibBC Workshop: Usability On a Budget

I taught a workshop last week on doing usability on a budget. Usability is such a big topic that it’s impossible to cover everything in just 3 hours, but it’s a quick overview of how to put some of these methods into practice in a low cost, low resource way.

These are the notes I have along with all the links and such. Continue reading “Code4LibBC Workshop: Usability On a Budget”

Code4Lib Day 2: Morning Notes

REST IS Your Mobile Strategy

REST

  • Representational State Transfer – a methodology developed alongside HTTP 1.1
  • clients request representations of resources from servers – typically a document
  • basically turns into an API

Examples

  • Twitter
  • New York Times –  Congress API
  • Chicago Transit

iOS Development

  • need to know: Xcode, Objective-C, Cocoa Touch, Provisioning
  • Xcode – Apple developer, like Visual Studio or Eclipse
  • Objective-C – strict superset of C
  • Cocoa Touch – frameworks to talk to iOS, similar to RubyRails
  • UIKit
  • Provisioning Portal – annoying paperwork

OCLC Classify API

  • give it an item, tell you how it’s classified including call number

Process

  • Use Rested -MAC tool,grabs API information, and provides you the raw output
  • Xcode – create a new basic project
  • go from XML to Objective-C
  • use RestKit – maps XML to Objective-C
  • use PaintCode – create GUI
  • hire an artist
  • Apple App Review Process

Librobot App

  • in the store by April 2nd

Why REST Matters – What are the Major Milestones

  • math formula – importance of technology can be determined by the amount of money involved in a court case
  • Personal Computers
  • The Internet
  • Mobility
  • Build an API – ask for ideas, and apps will come.

Take Away

  • you have interesting data
  • make an API
  • If we build it, they will come for it!

All Teh Metadatas Re-Revisited

  • Esme Cowles, UC San Diego Library
  • Matt Critchlow, UC San Diego Library
  • Bradley Westbrook, UC San Diego Library

Continues the story from last year.

Needs

  • more consistent data
  • maintain syntax of hierarchical subjects
  • improve support for complex objects
  • align more strongly with the digital libraries community – most important

User Stories

  • to understand requirements of administration and researchers

Sorry, I had to take a brain break and got a little lost. I’m also going to blame twitter and IRC for distracting me. Take a look at the slides:

Implementation

  • DAMS Repository – new version of lightweight repository, with APIs
  • Manager – separate and uses the API
  • Public Access System – new frontend in Hydra, great community

Timeline

  • release in summer
  • code now available on Github

Browser/Javascript Integration Testing with Ruby

  • Jessie Keck, Stanford University
  • Slides

The Problem

  • needed to test JavaScript
  • especially since using progressive enhancement
  • site works without JavaScript, then more features with JavaScript
  • mistakes happen e.g. killed navigation,

Some Solution(s)

  • Watir == Web Application Testing in Ruby
  • built on watir-webdriver
  • Capybara – RSpec/Cucumber driver
  • ability to test responsive design
  • webkit integration available
  • personally like Capybara syntax (vs. Watir)
  • automated test that there is JavaScript bug e.g. automatically test that facets working

Gotchas

  • might want to use Watir Rails
  • transactional fixtures

Linked Open Communism: Better discovery through data dis- and re- aggregation

  • Corey A Harper, New York University

How to shut up about linked data and actually build something.

Context

  • context, the narrative of the library/archive
  • user stories

Death of Browse

  • discovery systems don’t use authority control
  • browse broken as UI design
  • rich data in authorities disconnected

The Idea Implemented

  • take EAD records, blow them up, take headings to match MARC records
  • pull people, coporations, and topic – pull info from DBpedia
  • index in Solr
  • slower than would like
  • On Github but is buggy

Solr Update

  • Erik Hatcher, LucidWorks

Sorry, but we don’t use Solr, and anyone really interested I think can look up information the update. e.g. Apache Solr Release Notes

Check out the slides:

Break Time

white otter
Time to Get Some Hugs

Ask Anything

Who’s faculty? Half Faculty – small handful who care about being faculty

Planing and pilot phase of bringing together all resources of types. How to decide what to use and where to start?

Normalizing records from MARC to Solr. Want help with format.

How many have library degrees? 2/3 do, 1/3 don’t

Code4Lib – archiving our stuff? Talk to Mark/anarchivist. Mailing list is archived on the university server. Mirrored on post. Regular basis, dumped to media forward.

Goals of BIBFRAME? Replacing/superseding MARC.

First-timers to c4lcon? majority of room. All? < 20

Anyone collecting social media on behalf of user community or collection building purposes? Going to be a lightning talk tomorrow.

Anyone from a theology library? ~5 ppl

Want to know successful examples of gamification to support information literacy by @maccabeelevine e.g. Lemontree

Glossary of technology and stacks. On code4lib wiki? A guide for the perplexed. We can work on it.

Who is using graph databases? 2-3 ppl

Using DSpace? 25-30 FedoraCommons? 25-30 Hydra? 10-15

This conference working for you? Almost everyone.

What do people think of the wiki? One idea is to move it over to github code4lib account.

From the federal government? 3

Anyone interested in integrated TSM into Solr? anarchivist says he knows people

How many non-library degree people considering getting one? 2

How many have project managers as their title? ~12 Public? 5 Academic? rest

CodeRead – looking at PyMARC (sp?). Anyone else looking into this?

Didn’t get all the questions, but that’s most of them.

Lunch Time

squirrel begging for food

Steve Krug: You’re NOT Doing Usability Testing? Are You Nuts?

The University of Toronto iSchool was lucky enough to get Steve Krug of Don’t Make Me Think fame. If you haven’t read it and you’re at all interested in usability, I would definitely recommend it. Anyway, here are my notes from today’s talk.

Goal

Convince you that usability testing is the most valuable thing you can do to ensure that what you’re building works.

12 Years Ago – The Debate

Realized seeing the same story over and over again. He first started by turning it into a comic. Basically the same debates happened over and over, frequently without decisions being made. It’s difficult to find a middle ground, because each person comes with their own perspective. Partly, there’s no hard and fast answer, because it depends on the context.

Usability testing eliminated most debates. Seeing users use what they designed changed their perspective and start talking from the user perspective rather than personal biases.

Keeping It Simple

Traditionally, usability is done in a lab with the minimum 8 users in a day by an outsider, ending in an expensive report which may not be convincing to the team.

Rocket Surgery Made Easy written more for people intending to actually do usability testing.

Just do it with:

  • 3 users per round
  • set up a monitor in another room to watch
  • record screencast
  • no stats, no faux validity, but produces meaningful insight
  • no big report, just debrief over lunch, report in 1-2 page email

Live Demo

Use script, which can be downloaded from Krug’s website. Instead of a website, he did a live demo on the Clear mobile app. Interestingly, the participant could not complete the task, which was interesting since the app is highly praised.

RSME: The 22-minute version

6 Maxims

  • A morning a month is all we ask.
  • Start earlier than you think makes sense. – Can start before you start by testing a competitor’s or old version, or even a sketch on a napkin.
  • Recruit loosely and grade on a curve. – Take just about anyone, and judge whether everyone would have that problem or if it’s just because not from target audience.
  • Make it a spectator sport.
  • Focus ruthlessly on the few, most serious problems. – Right away write down the top 3 problems to take into debrief.
  • When fixing problems, always do the least you can do. – The smallest change might do to solve or help mitigate the problem. Tweak, don’t redesign.

Q&A

  • James Chudley CX Partners wrote on the approach to doing mobile app testing that needs context.
  • Tools for Remote Testing – Goto Meeting, WebEx and need high quality audio
  • Analytics good to help know what to test
  • Do usability more frequently rather than testing a lot of people, because you quickly hit diminishing returns
  • Task specification – allow user to have the choices of content