R

1
R D for Libraries

• Pete Boguszewski
• Stephen Meyer
• Library Technology Group
• UW-Madison Libraries

2
What is this about?

• Who? libraries
• What? delivering first rate services
• When? the sooner the better
• Where? at home (I mean, work)
• Why? we can always do better
• How? w/ agility and creativity

3
Who?
Yes, you. You control the Information
Age. Welcome to your world.
4
Who?
Librarian
Yes, you. You control your librarys
data. Welcome to your world.
5
What?

• Researching and developing better systems and
  services in libraries.

6
When?

• Now

7
Where?

• Right where you are.

8
Why?
Because no one quite has it figured out yet.

• (Google is just not afraid to admit it.)

9
What?(contd)

• A paradigm change
• Embrace the beta!
• Main Entry 1beta
• ...
• 4 a nearly complete prototype of a product (as
  software) ltreleased in betagt ltthe beta versiongt
• (source http//www.m-w.com/dictionary/beta)

10
Why release an unfinished product?

• We dont know yet what we dont know.

(But neither do our users.)
11
How?

• Research Development

12
A Web 2.0 darling Netflix

• Site update schedule 2 weeks
• They know the benefits of failing fast

13
Failing Fast

• Ironically, teams that fail fast improve as fast,
  if not faster, than those who try to get it right
  the first time. The reason is simple Teams
  trying to get it right the first time fail as
  often as everyone else does.

source http//www.uie.com/articles/fast_iteration
s/
14
Agility
15
Warning

• RD can be a dangerous enterprisean organization
  must have clear goals
• venturing into development requires focus
• solve only known problems
• solve problems that are important

16

• What is the problem I am trying to solve?
• Do the tools exist to take on this project?
• Do the staff exist to take on this project?

17
What if I fail?

• What can I learn from the experience upon
  failure?
• What can I learn from the experience if the
  product or service does not materialize?

18
Library Tech Group
Overview Infrastructure
19
The Library Tech Groups Infrastructure
Virtualization Security Ability to move fast
20
Virtualization on Vmware
It is truly magic
21
Server Setup is Time Consuming
Virtual servers can be cloned quickly We setup
servers with specific software sets, patch them,
test results for consistency
22
Why do we care at all?

• It is really cool
• Allow us to be able to look at multiple products
  and/or applications at once
• We can easily create servers to host products
  that have different needs simultaneously
• Easily compare functionality, look and feel

23
Cloning (of servers) is good
24
Last bit on virtualization
Virtualized servers allow us to take a snapshot
of the environment before doing development Can
quickly revert to a moment in time if development
goes bad
25
(No Transcript)
26
Virtual Environment
Now we have our server environment
27
Security
Integral part of development Never replaces
good programming practices or proper development
techniques
28
Web Environment
29
Security helps development
Blocks out malicious users This locked down
environment allows us to put applications up
quickly
30
Library Tech Group Helpdesk
31
Project Background
32
Ticket System Research
Web Search Ask other institutions Read current
user opinions
33
Ticket System Preparation
Commercial Products
Open Source

• Read documentation

• Read documentation
• Research which platform is best suited for
  application
• Research back-end requirements

34
Pick your favorite flavor
35
Pick your database
36
Ticket System Setup
Open Source
Commercial

• Install according to documentation
• Modify based on your specific environment
• Clearly document all changes, snags, surprises

• Install according to documentation

37
Ticket System
Compare all products
Compare Products
38
Commercial Products
Advantages
Disadvantages

• Easy to install
• Tech support

• Less flexible because we do not have the source
  code
• Cost
• Less flexible by design

39
Open Source
Advantages
Disadvantages

• Constantly changing, fixing bugs
• Ability to modify the source code
• Community enhancements and plug-ins
• Simple, easily changeable interface

• Constantly changing, fixing bugs
• No direct customer support
• Development is not free

40
What I learned about Open Source

• Free software is a matter of liberty, not
  price. To understand the concept, you should
  think of free as in free speech, not as in
  free beer.
• Richard Stallman
• It can be great in the right situations

41
Open source is the big winner
42
Ticket System

• Reinstall to get a clean, unmodified starting
  point
• Implemented but in perpetual beta
• Only used inside our office

43
Open Source Benefits

• Constantly adding features
• Email generated tickets
• Web forms
• Inventory information
• - Home-grown scripts

44
A learning experience

• Time is money - open source is not free but can
  still be well worth the effort
• Economies of scale
• Later projects on Linux benefit from this
  experience
• Now have expertise in-house

45
Make the catalog data work harder
46
Inspiration

• The OPAC Sucks
• Libraries don't just collect things, we build
  collections
• the value of a library lies in its
  bibliographers, not just its bibliographic info
• A faculty member claimed there is no stack browse

47
Why does the OPAC suck?
48
(No Transcript)
49
(No Transcript)
50
(No Transcript)
51
(OPAC)
52

• Who's ever written a great work about the immense
  effort required in order not to create?

Dostoyevsky Wannabe from the movie Slacker
53
(OPAC)
54
Leveraging our greatest strengths

• Patrons come to the library because we have the
  goods
• Without an infinite budget, we collect smartly,
  rather than indiscriminately
• Bibliographers and collection managers build
  collections

55

• There is no online equivalent to browsing the
  stacks.

source paraphrase of a faculty comment during
question and answer session of a library lecture
series
56

• Actually...there is.

57
(No Transcript)
58
Gawd, like even my llama knows that.
59

• Real point of need
• vs.
• Awkward access to our data

60
SaneCat(a mini RD project)
61

• Is it possible to build and OPAC-like toy that
  addresses these issues over the winter
  intersession?

62
Primary challenge

• How do I realize the my goals within the
  construct of a web database application?

63
What are the problems I am trying to solve?

• To create an OPAC-like prototype that doesnt
  suck
• To showcase library collections not just provide
  the call number for an individual title
• To approximate the experience of browsing the
  stacks in 2-D

64
Focusing the task at hand

• not sucking vague, fuzzy, dangerous

65
Focusing the task at hand(contd)

• showcasing library collections

how does one bibliographic record stand in
relation to others in the collection?
66
Focusing the task at hand(contd)

• browsing the stacks online

When does a patron browse the stacks?
67
Which problems are important?

• More importantly, which problems are not
  important?

68
How was it built?

• A random selection of 72,000 catalog records
• almost 1 of our catalog
• 59,686 after dups and errors were thrown out
• 87,761 unique subjects
• 213,719 subfields within subjects

69
How was it built?(contd)

• With a whole lot of help and guidance.

70
(No Transcript)
71
(No Transcript)
72
(No Transcript)
73
(No Transcript)
74
Geeky Details(prototyping tools)

• MySQL database
• marc4j libraries (for parsing raw MARC data)
• Java/Tomcat webapp
• Spring application framework
• Hibernate Object Relational Mapping
• jsp with jstl tag libraries

75
techie design goals

• model relationships among bib records(bibliograp
  hers build collections)
• provide access to data at point of need(faculty
  member did not find the access that exists when
  he needed it)

76

• SaneCat

77
What did I learn?

• there are doors to be opened
• there are performance issues to be resolved
• there are data hooks that would need to be
  addressed
• there is no reason to write acq, cat, circ
  modules
• we need live circ data

78
What if ... we never create a SaneCat?
79

• we have a mockup that can stand as leverage with
  vendors
• we have proof that our data can do what we want
• we know that Amazon does not have a monopoly on
  'more like this'
• we can lend our tech to vendors so our systems
  are better

80
Where could we take this?

• work out the performance problems
• graph theory and a research map
• begin collecting intentional data
• develop the next gen MARC records an
  object-oriented bibl. record

81
Why should we do this?
82

• This is a fantastic tool for simulating something
  like browsing through the stacks. I have enjoyed
  playing with it for a few minutes.
• ...
• Again, this is a great tool. I look forward to
  using it extensively in the future. Please let me
  know if I can help in any other way.

source faculty member who would like to browse
stacks online