EDUCAUSE2006: Library/IT Partnerships
Constituent Group: Library/IT Partnerships
Malcolm B. Brown, Director of Academic Computing, Dartmouth College
Daniel Keith Marmion, Associate Director for Information Systems & Digital Access, University of Notre Dame
What are the issues on people’s minds?:
• space/learning centers,
• books vs. computers (some debate about framing it this way!),
• e-archiving, especially of non-text-based materials: faculty create images, tutorials, multimedia, etc.: how do we pick software, create repositories, archive and access?
• support for authoring/multimedia production: at University of North Texas, multimedia thesis projects are officially called “problems in lieu of thesis” by library!, library doesn’t want to deal with it so academic computing is doing, storing and providing access. Library won’t catalog! Was referred by group to some organizations for help: www.ndlp.org, slide librarians assosication, “digital library systems and services” @ Stanford. “These things should be available from the library web site because that’s where people go to find them” (I wonder?)
• embedded library/embedded computing,
• integrating with academic resources, e.g., CMS,
• who provides front-line support?: help desk vs. library, should merge but hard to do, librarians say “not my job” to answer tech questions, librarians don’t want students at the ref desk. Comment from Australia: when librarians rove in lab, there aren’t any questions, when students rove, there are lots! From Seattle: typically librarians are used to working out front, IT is typically behind e-mail or phone, by the time you get the question there’s no point in referring—you should answer! Teaching librarians to answer those questions helps them and provides better customer service. Another perspective: these are the two largest curricular support units on campus, they should focus on the customer! Librarians can help with document management, records retention, metadata: just need to figure out where each fits on the information continuum.
• IT support and training for “legacy staff”.
• Resource management and staff development: library makes demands on IT, move towards shibboleth etc. comes from library needs.
• In merged organizations issues like faculty status (get sabbaticals, “it is an issue if they get big heads, not otherwise”) vs. IT staff (get more money?), MLS vs. PhD. U Indianapolis is “sunsetting” faculty status—all are “professionals”. At CSULB academic technology reports via the library: “techs can learn library easier than librarians can learn tech”. At Kenyon, from new librarian: “merge is good, it fits the way I work, aligns me with my classmates from library school and with new faculty”. At Hamilton, VP IT and Library Director decided first to be collaborators, found it works best when project based and limited. At Binghamton: reserves/blackboard served as a good project to learn to work together, info commons is rockier. At Carleton, heads collaborated on projects (moodle, data services, gis)—don’t need to merge. Focus on similarities, treat as people. At Cornell: was (not now) an underlying lack of respect for skills of other side, it took some brownbags to get some projects going.
• Service points: are they shared? How does communications work in unmerged organizations?
Malcolm B. Brown, Director of Academic Computing, Dartmouth College
Daniel Keith Marmion, Associate Director for Information Systems & Digital Access, University of Notre Dame
What are the issues on people’s minds?:
• space/learning centers,
• books vs. computers (some debate about framing it this way!),
• e-archiving, especially of non-text-based materials: faculty create images, tutorials, multimedia, etc.: how do we pick software, create repositories, archive and access?
• support for authoring/multimedia production: at University of North Texas, multimedia thesis projects are officially called “problems in lieu of thesis” by library!, library doesn’t want to deal with it so academic computing is doing, storing and providing access. Library won’t catalog! Was referred by group to some organizations for help: www.ndlp.org, slide librarians assosication, “digital library systems and services” @ Stanford. “These things should be available from the library web site because that’s where people go to find them” (I wonder?)
• embedded library/embedded computing,
• integrating with academic resources, e.g., CMS,
• who provides front-line support?: help desk vs. library, should merge but hard to do, librarians say “not my job” to answer tech questions, librarians don’t want students at the ref desk. Comment from Australia: when librarians rove in lab, there aren’t any questions, when students rove, there are lots! From Seattle: typically librarians are used to working out front, IT is typically behind e-mail or phone, by the time you get the question there’s no point in referring—you should answer! Teaching librarians to answer those questions helps them and provides better customer service. Another perspective: these are the two largest curricular support units on campus, they should focus on the customer! Librarians can help with document management, records retention, metadata: just need to figure out where each fits on the information continuum.
• IT support and training for “legacy staff”.
• Resource management and staff development: library makes demands on IT, move towards shibboleth etc. comes from library needs.
• In merged organizations issues like faculty status (get sabbaticals, “it is an issue if they get big heads, not otherwise”) vs. IT staff (get more money?), MLS vs. PhD. U Indianapolis is “sunsetting” faculty status—all are “professionals”. At CSULB academic technology reports via the library: “techs can learn library easier than librarians can learn tech”. At Kenyon, from new librarian: “merge is good, it fits the way I work, aligns me with my classmates from library school and with new faculty”. At Hamilton, VP IT and Library Director decided first to be collaborators, found it works best when project based and limited. At Binghamton: reserves/blackboard served as a good project to learn to work together, info commons is rockier. At Carleton, heads collaborated on projects (moodle, data services, gis)—don’t need to merge. Focus on similarities, treat as people. At Cornell: was (not now) an underlying lack of respect for skills of other side, it took some brownbags to get some projects going.
• Service points: are they shared? How does communications work in unmerged organizations?
0 Comments:
Post a Comment
<< Home