Build.ZSR: Doing DH by Facilitating DH
•Download as PPTX, PDF•
1 like•662 views
Z. Smith Reynolds Library is working to implement an infrastructure to support digital projects at Wake Forest University that is responsive to the particularities of the university's context, mission, and size. The aim is to provide a solution that is both scalable and sustainable, from simple course blogs to custom web applications. Existing in parallel with Find.ZSR, our library's catalog, Build.ZSR is intended to convey that our library is not just a place to seek information resources, but also a place to construct new knowledge. We will share our process for conceptualizing and implementing Build.ZSR, as well as elicit thoughtful critique from other participants.
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Build.ZSR: Doing DH by Facilitating DH
- 1. build.ZSRDoing DH by facilitating DH Chelcie Juliet Rowell Kevin Gilbertson
- 2. Who are we? Kevin Gilbertson Web Services Librarian Z. Smith Reynolds Library Wake Forest University gilberkm@wfu.edu Chelcie Juliet Rowell Digital Initiatives Librarian Z. Smith Reynolds Library Wake Forest University @ararebit
- 3. Can collaboration & consultation with others who are building scholarly digital projects be cast as ‘doing DH’?
- 4. The library is not a bookshelf but a space for the active creation of new knowledge.
- 5. the faculty website problem
- 8. reframing creative process & product
- 9. service tiers of build.ZSR
- 10. project charter
- 11. Image Credits ❏ SLIDE 001: NYC Panorama Model 3 by Mr.TinDC on Flickr. ❏ SLIDE 004: little type by bettinche on Flickr. ❏ SLIDE 005: Glitch Art by Hugh Manon on Flickr. ❏ SLIDE 006: Untitled by Mira Pangkey on Flickr. ❏ SLIDE 007: Old Advertising Board_Walsall Station_Apr11 by Ian on Flickr. ❏ SLIDE 008: strawtron-exterior by Brian (Ziggy) Liloia on Flickr. ❏ SLIDE 009: IMG_6870 by Never House on Flickr. ❏ SLIDE 010: Building Blocks by Eran Sandler on Flickr.
- 12. References ❏ IDEO. (2014). Design thinking in a day: An at-a-glance guide for advancing your library. Retrieved from http://designthinkingforlibraries.com. ❏ Paton, B., & Dorst, K. (2011). Briefing and reframing: A situated practice. Design Studies, 32(6), 573–587. doi:10.1016/j.destud.2011.07.002 ❏ Varner, S. (2014). Project Charter. Retrieved from http://stewartvarner.com/2014/05/06/project-charter. ❏ Vinopal, J., & McCormick, M. (2013). Supporting Digital Scholarship in Research Libraries: Scalability and Sustainability. Journal of Library Administration, 53(1), 27–42. doi:10.1080/01930826.2013.756689
- 13. Appendix: Assessment of Build.ZSR ❏ determining success criteria ❏ evaluating client satisfaction ❏ identifying what did and didn’t work ❏ calculating staff hours spent on development and support activities ❏ estimating costs and possible efficiencies ❏ considering next steps
Editor's Notes
- Build.ZSR is a service we are designing to support scholarly digital projects on Wake Forest University’s campus. We hope to begin making this service available for the 2015–2016 AY. During our lightning talk we’re going to focus more on our process of designing this service than we are going to talk about the service itself. And since we’re still in the early stages of creating this service, we’d welcome your feedback during Q&A or discussion.
- The topic of this panel is ‘doing DH library style,’ and the central question of our lightning talk is whether our efforts to build build.zsr counts as ‘doing DH.’ Or, more broadly, does collaboration & consultation with others who are building scholarly digital projects be cast as ‘doing DH’? This question ties in with the question of academic libraries’ role in supporting digital humanities on their campuses, as well as the question of librarians’ roles when working with faculty and technologists and others on collaborative digital projects. Trevor Munoz argues very forcefully and eloquently that digital humanities is not a service. Rather, it’s a methodology, a set of methodologies, an argument, a set of arguments. Consequently, no, digital humanities can’t be a ‘service’ provided by a library or any other unit on campus. Instead, the service rendered may be sustainable support for web projects of various levels of complexity, or consultations about metadata, or a referral by a library liaison to relevant campus or library resources, or an embedded librarian in undergraduate courses doing digital projects. The varieties of examples of ‘services’ illustrates that it’s difficult to design infrastructure (technological or human) without knowing what we’re infrastructuring. All of these questions were at the front of our mind when we were thinking about build.zsr, and we reached the conclusion that building build.zsr is certainly doing DH, even though it’s the straight-up design of a service, because we are using design methodologies to build build.zsr.
- To start designing this service, we wanted to understand — to really understand — the context of the problem. Here, we supply a specific foundational principle: the library is not a bookshelf but a space for the active creation of new knowledge. This understanding, this claim, may be controversial to some faculty, even to some librarians perhaps, who think of the library — and librarians — in certain static ways. By starting with a foundation of creating and building new knowledge, we’re changing the initial context, the space for solutions, the terms of interaction. We’re changing the terms of what problems we can solve and how we can solve them.
- At New York University “we find ourselves challenged to respond effectively to what we have come to call ‘the faculty website problem’ — an ever growing number of requests for web based spaces and tools to collaborate on scholarly research and share the results.” — Jennifer Vinopal & Monica McCormick What is a ‘website’? Wiki or blog Custom database Tools for collaboration Integration with other platforms Some combination of all these! What support is needed? Single consultation Semester-long course collaboration Open-ended commitment to implement new tool or manage scholarly digital collection
- Of course, there are a number of roles involved. For us on the library side, we have experienced a continuum from technician to collaborator — from “just a technician,” framed dismissively by faculty, to full-fledged collaborator, where we share in the process and outcome. We want the space on this continuum to be dynamic, to allow for shifting roles — the challenge is not to be cast as only one thing. Limited casting, limited acknowledgement of the varying roles, or inchoate infrastructure, can result in missed opportunities.
- Kevin: Stephanie Pellet. Online workbook. Interactive captions. No infrastructure. Just PDFs online. Chelcie: On the other hand, our collaboration with one faculty member (Phoebe) originated as a service request — make me a blog for my journalism course. It evolved into a clearer vision for a mobile-first community journalism site, an ongoing publication which students from different semesters contribute to and use to build their portfolio. These were the kinds of projects we wanted to support, projects which gave us an opportunity to share in that process of envisioning the scholarly output.
- Kevin: We’ve already talked about reframing in this morning’s plenary. It’s an important concept, an important step in the process. Here, as we’ve defined our roles explicitly, we’ve positioned ourselves to reframe the creative process. As partners, as collaborators, as facilitators, we have a distinct responsibility to question and ideate and iterate in a way that seeks the best possible outcome, or product. Chelcie: Our thinking was influenced by a research study, in-depth interviews with people in design professions about what they found satisfying and dissatisfying about interactions with clients. One of the main themes that emerged from analysis of these in-depth interviews was that designers find client interactions more satisfying when they have the opportunity to participate in the framing of the problem space, rather than being brought in long after the problem space has been defined and being asked to provide a solution. Instead, one of the kinds of expertise that design professional have to offer is the practice of listening to the client but then, crucially, reframing the problem so that the client can see a different array of possible solutions. We are trying to design build.zsr in such a way that it facilitates this kind of interaction between librarian and scholar, which both find mutually satisfying. And thinking of outcomes leads us to designing our service model.
- We have — will have — 3 services tiers: provision (several platforms and technologies available where you can use to 'build on your own' - a wordpress install, an omeka site, etc) customization (less hands-on than the 'build your own' model, we provide individual support for a project. Our model for Tier 2 focuses on helping to fulfill cross-campus needs. This tier requires funding so that it can continue to exist) creation (the premier tier where we build from scratch)
- Borrowed from Stewart Varner, who developed the charter with Brian Croxall and Miriam Posner at Emory’s Center for Digital Scholarship. Title. Project Owner. Project team (roles for individuals). Summary (scholarly goal of the project). Bulleted list of deliverables (each discrete part of the project that needs to be complete in order for the project to be called complete). Timeline for completion. Launch or production plan. Source of funding. End of life issues. Stewart sees the charter as having three purposes: – First, it guides you through an important series of conversations about what, exactly, you are doing and when you are doing it. – Second, it asks you to think about maintenance and preservation. – Third, having a charter in place gives you something to refer to when partners inevitably remember things differently. To that, we would add that the process of the project lead drafting the responses to the questions posed by the charter, and then perhaps revising it in consultation with a member of the build.zsr team, is an opportunity to build consensus. It’s also an opportunity to engaging in the situated practice of briefing with clients and reframing the problem space, in the way that the research project we discussed earlier found was fulfilling for both designer and client, librarian and scholar.