 |
 |
Well said Kyle - I am with you. The OPAC's services as modules are key to teaching the OPAC, and learning the concepts within workflow processes - often depicted as flowcharts - are a great lessons; especially adding the peculiarities of library policies and procedures, and how the old stuff was designed to include the unimaginably real complexity of library workflow. From that perspective, one learning outcome could be - how to simplify to scale... Best wishes, Cyril -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Kyle Banerjee Sent: Tuesday, August 07, 2012 12:15 PM To: [log in to unmask] Subject: Re: [CODE4LIB] Recommendations for a teaching OPAC? > > I teach an intro to IT survey class for the LIS school at Illinois. > The one-major-topic-a-week syllabus doesn't really give us time to > deep dive into IT topics, but it lets us explore them and give > contextual understanding to the building block pieces. Ideally, every > topic has some sort of hands-on exercise that gives real life > experience with the concepts/technologies. The exercises are usually > independent, but I've been kicking around the idea of using a simple > OSS OPAC to teach different elements of the class as a semester-long big cascading lesson.... I guess my perspective on this is a bit different than most people here. What makes the OPAC special isn't the technologies it employs, but rather the workflows and data it supports because these come straight out of the physical world and tools used decades ago. Aside from that, library automation is still heavily influenced by technologies developed when memory was measured in kilobytes rather than gigabytes. Discovery gets the lion's share of attention, but when you get right down to it, what people call an OPAC is only the public facing side of a specialized inventory control system that supports a wide range of functions. People need to learn the new stuff, but a huge part of grokking the OPAC is the old stuff -- otherwise, people simply arrive at the conclusion that the data/methods are stupid or irrelevant and they miss the main point. So where am I going with this? If I wanted to give people a crash course in OPAC, I'd take them on tours through acq, tech services, circ, and resource sharing led by people who are experts in the operational details of those operations so they can see what the systems support. If they simply muck about with systems without understanding what those systems support, I don't think they'll learn nearly as much. kyle