Pete Boguszewski Stephen Meyer

215
-1

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
215
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pete Boguszewski Stephen Meyer

  1. 1. R & D for Libraries Pete Boguszewski Stephen Meyer Library Technology Group UW-Madison Libraries
  2. 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. 3. Who? Yes, you. You control the Information Age. Welcome to your world.
  4. 4. Who? Librarian Yes, you. You control your library’s data. Welcome to your world.
  5. 5. What? Researching and developing better systems and services in libraries.
  6. 6. When? Now
  7. 7. Where? Right where you are.
  8. 8. Why? Because no one quite has it figured out yet. (Google is just not afraid to admit it.)
  9. 9. What? (cont’d) A paradigm change: Embrace the beta! Main Entry: 1be·ta ... 4 : a nearly complete prototype of a product (as software) <released in beta> <the beta version> (source: http://www.m-w.com/dictionary/beta)
  10. 10. Why release an unfinished product? We don’t know yet what we don’t know. (But neither do our users.)
  11. 11. How? Research & Development
  12. 12. A Web 2.0 darling: Netflix • Site update schedule: 2 weeks • They know the benefits of failing fast
  13. 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_iterations/
  14. 14. Agility
  15. 15. Warning • R&D can be a dangerous enterprise an organization must have clear goals • venturing into development requires focus – solve only known problems – solve problems that are important
  16. 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. 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. 18. Library Tech Group Overview *Infrastructure*
  19. 19. The Library Tech Group’s Infrastructure Virtualization Security = Ability to move fast
  20. 20. Virtualization on Vmware It is truly magic
  21. 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. 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. 23. Cloning (of servers) is good
  24. 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. 25. Virtual Environment Now we have our server environment
  26. 26. Security Integral part of development Never replaces good programming practices or proper development techniques
  27. 27. Web Environment
  28. 28. Security helps development Blocks out malicious users This locked down environment allows us to put applications up quickly
  29. 29. Library Tech Group Helpdesk
  30. 30. Project Background
  31. 31. Ticket System Research Web Search Ask other institutions Read current user opinions
  32. 32. Ticket System Preparation Commercial Products Open Source • Read documentation • Read documentation • Research which platform is best suited for application • Research back-end requirements
  33. 33. Pick your favorite flavor
  34. 34. Pick your database
  35. 35. Ticket System Setup Open Source Commercial • Install according to • Install according to documentation documentation – Modify based on your specific environment • Clearly document all changes, snags, surprises
  36. 36. Ticket System Compare all products Compare Products
  37. 37. Commercial Products Advantages Disadvantages • Easy to install • Less flexible because we do not have the source • Tech support code • Cost $$$ • Less flexible by design
  38. 38. Open Source Advantages Disadvantages • Constantly changing, • Constantly changing, fixing bugs fixing bugs • Ability to modify the • No direct customer source code support • Community • Development is not enhancements and plug- free… ins • Simple, easily changeable interface
  39. 39. 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
  40. 40. Open source is the big winner
  41. 41. Ticket System • Reinstall to get a clean, unmodified starting point • Implemented but in perpetual beta – Only used inside our office
  42. 42. Open Source Benefits – Constantly adding features • Email generated tickets • Web forms • Inventory information – - Home-grown scripts
  43. 43. 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
  44. 44. Make the catalog data work harder
  45. 45. 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
  46. 46. Why does the OPAC suck?
  47. 47. (OPAC)
  48. 48. Who's ever written a great work about the immense effort required in order not to create? Dostoyevsky Wannabe from the movie Slacker
  49. 49. (OPAC)
  50. 50. 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
  51. 51. 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
  52. 52. Actually...there is.
  53. 53. Gawd, like even my llama knows that.
  54. 54. Real point of need vs. Awkward access to our data
  55. 55. SaneCat (a mini R&D project)
  56. 56. Is it possible to build and OPAC-like toy that addresses these issues over the winter intersession?
  57. 57. Primary challenge How do I realize the my goals within the construct of a web database application?
  58. 58. What are the problems I am trying to solve? • To create an OPAC-like prototype that doesn’t 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
  59. 59. Focusing the task at hand not sucking = vague, fuzzy, dangerous
  60. 60. Focusing the task at hand (cont’d) showcasing library collections how does one bibliographic record stand in relation to others in the collection?
  61. 61. Focusing the task at hand (cont’d) browsing the stacks online When does a patron browse the stacks?
  62. 62. Which problems are important? More importantly, which problems are not important?
  63. 63. 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
  64. 64. How was it built? (cont’d) With a whole lot of help and guidance.
  65. 65. 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
  66. 66. techie design goals • model relationships among bib records (bibliographers build collections) • provide access to data at point of need (faculty member did not find the access that exists when he needed it)
  67. 67. SaneCat
  68. 68. 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
  69. 69. What if ... we never create a SaneCat?
  70. 70. • 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
  71. 71. 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
  72. 72. Why should we do this?
  73. 73. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×