Achieving Big City Dreams at Small Town Libraries (ACRL 2015)
•Download as PPTX, PDF•
1 like•332 views
How Seven Regional College Libraries Used Collaboration and Adobe Captivate to Create an Online Information Literacy Program
Recommended
More Related Content
Similar to Achieving Big City Dreams at Small Town Libraries (ACRL 2015)
Similar to Achieving Big City Dreams at Small Town Libraries (ACRL 2015) (20)
More from Linscheid Library
More from Linscheid Library (20)
Recently uploaded
Recently uploaded (20)
Achieving Big City Dreams at Small Town Libraries (ACRL 2015)
- 1. How Seven Regional College Libraries Used Collaboration and Adobe Captivate to Create an Online Information Literacy Program Adrianna Lancaster, Sharon Morrison, Chelsea Baker, Allison Embry
- 2. Regional Universities in Oklahoma
- 4. Shared Issues Students with limited IL skills Some at a distance Librarian Turnover
- 5. 2008 - Planning Grant
- 6. OKLSI
- 9. 2009 - Amigos Grant
- 10. 2011 - IMLS Grant
- 11. IMLS Year One
- 12. IMLS Year Two
- 14. Experience and Lessons Learned The Creation Process
- 15. Captivate: The Good Robust and complex software More sophisticated than similar products Interactive elements Assessment elements
- 16. Captivate: The Bad Robust and complex software High learning curve Buggy and finicky Frequently updated Expensive
- 17. Decide to Commit
- 19. Communication is Key “The single biggest problem with communication is the illusion that it has taken place.” - George Bernard Shaw
- 22. Respect the Creative Process
- 23. Submissions
- 24. Round and Round
- 25. It’s Alive!
- 26. Where do we go next? Tutorials in progress Langston University – Worldcat Northeastern State University – Citations and plagiarism – in review Rogers State University – Search terms Rogers State University – Copyright Southeastern Oklahoma State University – EBSCO Discovery Service – (EDS)
- 27. Contact Us Adrianna Lancaster – alancaster@ecok.edu Sharon Morrison – smorrison@se.edu Chelsea Baker – cbaker@ecok.edu Allison Embry – aembry@rsu.edu http://www.oklsi.onenet.net
- 28. Image Credits Slide 2 Oklahoma Outline White from d-maps.com. Image is used with permission. Slide 3 Rural Sonoma from ah zut. Image is used under CC BY-NC-ND 2.0. Small Toad from Scott*. Image used is under CC BY-NC-SA 2.0. Empty Bottle in a Dry Pond– from alfie. Image is used with permission. Slide 4 Phyllo Apple Turnovers from Kelly Sue DeConnick. Image is used under CC BY-SA 2.0. Slide 5 The AT&T Logo from Mendaliv. Image is used under fair use. Slide 7 Pasea Sailing from Eric Gevaert. Image is used under CC BY 2.0. Slide 8 Framework from Junichi Ishito. Image is used under CC BY-NC-SA 2.0. Slide 9 Amigos Library Services Logo from Amigos Library Services. Image is used under fair use. Slide 10 IMLS Logo Black from the Institute of Museum and Library Services. Image is used with permission. Slide 11 Strip Foundation from Finn Mac Ginty. Image is used under CC BY 2.0. Slide 12 A Mansion in Adelaide from Ron Sanderson. Image used is in the public domain. Slide 13 Frustrated Man at a Desk from LaurMG. Image used is under CC BY-SA 3.0. Slide 17 Do We Have Your Commitment? from Jantoo.com/Mike Flanagan. Image is used under fair use. Slide 18 iStock_000014186302Small from Annie Biggs. Image is used under CC BY 2.0. Slide 20 Expect the Unexpected from Pixabay. Image used is in public domain. Slide 21 Good Friends from Juliana Coutinho. Image is used under CC BY 2.0. Slide 22 Billy Joel Piano Man from acme401. Image is used under CC BY-SA 2.0. Slide 24 Merry Go Round from John Luty. Image used is in the public domain. Slide 25 Young Frankenstein from Insomnia Cured Here. Image is used under CC BY-SA 2.0.
Editor's Notes
- 6 Regional Universities -NWOSU, NSU, SWOSU, SOSU, UCO, ECU 4 Regional-like Universities -OPSU, Langston, RSU, Cameron 8 of the 10 have participated in at least one of our projects Every project has had at least 6 participants
- Off the 8 who have participated, we have several characteristics in common – rural, small, limited resources in terms of time, money, staff https://www.flickr.com/photos/mon_oeil/7437130418 - Rural https://www.flickr.com/photos/jsmoorman/171463865/in/photolist-g9Nex-6Po97b-5WBfMH-feCjKL-pUUKHZ-HgMDt-8zdjYV-fLPFmg-putzmU-9MkkwM-fDe9ih-87ip6M-oReknU-5k18oZ-ax98ye-4TLwWQ-7nRYSr-5k17YX-oAfreo-cZSdwQ-nvS1P5-dfjTZN-8SkXM-nVtRiQ-gYpBFm-7kekPL-pysxCA-P6qeg-TfrYs-nKkzgG-ojFPnw-8SjXr-cjfgJ-owcRaj-2ebruM-hbErfk-fkkjhb-nW1Mbq-ojf7bm-a74Hjs-2FGKdn-nVsqkC-e9g2tK-hmv3C3-igSgfN-5fP8y2-hydLQJ-if34tU-78ED4M-qyHy13 – small http://www.flickr.com/photos/offshore/472307882/ - limited resources http://www.flickr.com/photos/kellysue/318881900/ - turnover
- Purpose was to leverage our resources collectively and share amongst us
- https://www.flickr.com/photos/crlbvi/2889352913
- Developed set of instructional guidelines – about this tutorial – date, acrl standards, author, which slides are specific to the institution overview main content (direct instruction – multiple tools) conclusion – some time of evaluation…even if that is sefl-eval/reflection Developed a design manual – in order to put the focus on content Selected a software – Captivate Develop a template Created a process by which an institution would submit a tutorial for approval https://www.flickr.com/photos/junnn/15699105322
- Six of us…
- Year one of the IMLS grant was really laying the foundation and building the infrastructure for tutorial creation. During year one, Each participating institution had at least one person undergo a half-day face-to-face workshop on Captivate basics with Jamie Holmes, a librarian from Tulsa with a lot of Captivate experience. In addition to the face-to-face training, we had the consultant who initially worked with the group to select a software package and create templates…create a few quick crash-course tutorials on using Captivate, and specifically using it in the context of this collaborative project. We felt that these were really crucial because Captivate does have such a steep learning curve that a lot of people who attended the F2F training were going to need refreshers, and as small regional universities, we do tend to have a lot of turnover so we needed a way to quickly train any new instruction librarians on the software and the template. Another big focus during year one, was purchasing and installing the software itself and any other products that one might need to create a tutorial. For instance, many institutions purchased microphones for high-quality audio recording. Some purchased more powerful computers so that they could run Captivate with fewer problems. Others purchased other pieces of software such as Photoshop that they intended to use in concert with Captivate. Thankfully, this money had been written into the grant, so each institution was able to get the equipment and software they needed to move forward with tutorial creation. Since the major goal of this grant was to have a centralized repository where all of the project files could be posted so that everyone and anyone could download them and modify them for their own purposes, we needed a lot of online storage space. The project had initially started out in a PbWorks wiki which only had 2 GB of storage overall and a maximum file size of 50 MB. It quickly became clear that this wasn’t going to cut it. So we talked to the OneNet, which is the statewide networking group, and they agreed to give us as much space as we needed. So we ended up migrating the site to a pretty simple Wordpress site. So when you are looking at a grant or other large project like this, it’s important to realize just what all will be involved in getting the project off the ground. Training is always important, but even more so with a collaborative project where you have people with a lot of different skill levels. And then it’s also crucial to ensure that everyone has the resources that they need, such as software and hardware, and the project has the resources it needs, such as storage space. So that was all more or less in Year One
- Year two is when all of the hard work had to be done – going from just a foundation to move-in ready, fully furnished project. We really kicked into high gear when Allison contacted me to submit a finished tutorial in Oct. 2013…before any mechanisms were in place to approve tutorials and even before the new website was complete. Furthermore, around this same time, we realized that Cp 7 was coming out, which meant that we’d need to make a lot of changes to our documentation. So it was finally time to convene the OK LSI Review Committee which was mandated in the original Policy & Procedures manual from 2009. The manual charged the committee with reviewing and approving tutorials. The composition of the committee was supposed to be one library dean or director and two instruction librarians, all from different institutions. Sharon, Allison, and I volunteered to serve on that committee. I had created several tutorials in Captivate so I was familiar with the software and the policy & procedures manual. Allison joined since she had also completed a tutorial. And Sharon got on board since she was one of the original directors included in the grant. So we all got together in Dec. 2013 to start cleaning house on the P & P manual.
- I’m sure that you’ve all had the privilege of revising a policy or procedure that someone else wrote. If you’ve succeeded in blocking that memory out, let me remind you that it can really be a tedious, frustrating process. Not knowing the original intent of the author is a big problem, and in this case we had a few other compounding issues. The manual is really quite comprehensive and covers everything from writing suggestions, to layout and design guidelines, to citation procedures, to submission processes. It’s about 25 pages long. Since about 4 years had at this time passed since its creation, we found quite a few changes that needed to be made in the manual. They ranged from small wording changes, to changes necessitated by the migration to Cp7, to larger changes based on shifting best practices. So we all had a lot of homework from that Dec. meeting and sent many emails back and forth over the following couple of months. And as we were finishing up the revisions instigated by our Dec. meeting, Allison was migrating her tutorial into Cp7. She’s now going to discuss the process of creating a tutorial in Captivate and the lessons she learned in the process
- I’m Allison Embry. I currently serve as the Access Services and Distance Learning Librarian at Rogers State University, and I’m going to talk about my experience and everything I learned from the perspective of a developer. Prior to joining this project in the summer of 2013 I had limited experience creating instructional tutorials. I had used Jing and Camtasia to create simple video capture tutorials, but OKLSI was my first experience building robust, interactive tutorials. In hindsight, the tutorial creation and peer-review process turned out to be more difficult, but also more rewarding than I expected. I hope that what I learned will be of value to anyone considering joining or leading this type of project.
- First, I want to talk about Captivate, because the software package that you choose is going to greatly influence the process and outcome of your project. There are many advantages to Captivate, and depending on what you hope to accomplish, this software package may meet your needs better than similar ones. First, Captivate is robust and complex. Once you have mastered the software, you can create very professional, polished tutorials in a reasonable amount of time. In my experience, it is more sophisticated than similar products because there are fewer limitations on the kinds of things you can do. For example, you can build custom templates that go far beyond basic PowerPoint slides. You can also format tutorials to be viewed on desktop and mobile platforms. (And these things just scratch the surface.) Captivate also allows developers to incorporate interactive elements into tutorials. When done well, this creates a more engaging experience for learners. Finally, Captivate also allows developers to incorporate assessment elements into tutorials, which is very advantageous if you want to build an online information literacy program, and is the reason Captivate was chosen for this project.
- There are many good reasons to choose Captivate for an online information literacy project, but it also comes with some disadvantages. The software’s complexity is as much a disadvantage as an advantage. If you want to move beyond basic screen capture and use this software to its potential, Captivate has a high learning curve compared to similar products. Our colleague Jamie Holmes, who trained all of us in Captivate, said that in order to this software well, it would take about a month of practicing with it eight hours per day, five days a week. Captivate’s complexity also makes it buggy and finicky, and part of the learning curve is learning to trouble shoot. For example, sound might not play on one slide even tough you have done everything by the book and you will have to figure out why. There are tools available to help you with this; Adobe has a discussion forum where users can help each other troubleshoot problems. There is also a troubleshooting manual that you can purchase from Adobe. However, bugs that tricky to troubleshoot can be an enormous source of frustration with this software. Captivate is also updated frequently. We started this project on Captivate 6 and upgraded a few months after 7 was released. Not too long after we upgraded, 8 was released. Last but not least, Captivate is expensive. We paid about $600 for a single license of 6, and had to pay nearly $300 per license to upgrade to 8. So, while Captivate is a superior product, these are things you will want to take into consideration before deciding to commit to it. Now that I have talked about my experience as a developer, I would like to talk about some of the important lessons I took away from this experience.
- The first lesson is on the importance of commitment. I have worked on grant projects before but OKLSI is, by far, the one in which I have been most involved. Adrianna summed this up well in a recent conversation: the success or failure of grant projects depends on the level of commitment of those involved. If your library does choose to become involved in this project or a similar one, it is important to commit fully. This is what I mean by commit fully: First, commit with your eyes open. Know that this type of project will require a significant time investment, probably more than you originally anticipate. This project enabled our library to acquire software and equipment that we would not have otherwise been able to afford. It has also enabled us to start seriously thinking about moving towards an online instruction model. Had we not joined this project, such a thing would have been out of the question for us. Our library has received, and is continuing to receive, significant benefits from our involvement in this project. And in turn, this required a considerable amount of time and effort spent developing tutorials on our part. When I submitted my tutorial for the first time, I did not expect to have to revise it multiple times over. This leads me to my second point: Once my colleagues and I decided to become part of this project, I had to continuously remind myself that this project was not about what was convenient for me or my institution. The majority of academic librarians that I know, and I include myself here, hold themselves and their work to remarkably high standards. We strive for our work to be as close to perfect as possible. When I became part of OKLSI, to a new standard, and at times it was a struggle to put myself aside and work towards making sure my work met expectations. Finally, commitment is required on all levels, including colleagues and department heads. o, if your library becomes involved in this type of project, understand that commitment extends beyond individual developers.
- This leads me to my second point: I could never have successfully participated in this project had it not been for the support of my department head and colleagues, and the cooperation of our IT department. From a developers perspective I will say that support of from your colleagues department head and colleagues is absolutely essential, so be sure that you have it before you agree to something like this. None of us work in a vacuum. The time and effort that are required of you will definitely effect your colleagues. That may mean that you won’t be able to spend as much time on the reference desk for a couple weeks, or that other people in your department might have to pick up some of your instruction sessions. You may need your department head to work with IT to make sure your technical needs are met. When seeking support, be honest with everyone in your department about what you need so they are not surprised.
- And this brings me to my third point. I love this quote from Shaw because it sums up the overwhelming majority of communication problems so perfectly and so eloquently. Good communication would be paramount for a single institution taking on this type of project. When multiple institutions are involved, communication becomes all the more important, and all the more difficult. Having served as both a developer and a reviewer on this project, I cannot over-emphasize the importance of communication. If you are a developer, familiarize yourself with the project’s requirements from the beginning, and don’t be afraid to ask questions. If you have doubts about whether something in your tutorial meets project standards, ask early in the development process. If you wait until you have submitted your tutorial, you may have to spend a lot of time on revisions you could have otherwise avoided. Also, if you are a developer, responsibility for communication will likely fall on you, because you are the person at your institution who is closest to the project. From a reviewer’s perspective, I would encourage reviewers to never assume that information is being clearly communicated to developers by department heads. Communicate with developers directly, if possible.
- This probably needs little explanation. However… As in all things, that which you don’t account for will probably happen, so be prepared. (Website example.)
- As much as you and your institution will gain from this type of project, it’s a lot of work, especially for developers. If you are a developer, especially if you are relatively inexperienced like I was, I would encourage you to seek support from a colleague who is experienced in the software and is willing to help you. I was lucky because , Jamie, the librarian trained us in Captivate has been a teacher in a previous life, and was willing to spend time with me and the other developers so we could become more proficient in the software. So, it makes a world of difference if you have someone who can answer your questions, and hold your hand if needed. As I mentioned earlier, we changed templates and upgraded software mid –project. This required a partial rebuild of my tutorials, twice. Jamie’s patience, technical expertise, and willingness to teach made the process much easier. If you are a dean or library director considering a similar project, I would strongly encourage you to hire a trainer to work with your developers. If you are a department head or dean considering trying this type of project, a trainer will be your best investment. I would seek out someone who is knowledgable, and also patient enough to work with project participants.
- Finally, building tutorials is a creative process. I recently heard a radio clip from an interview with musician Billy Joel where he was talking about his approach to writing songs. He said that he usually writes the music first, and then uses the music to inspire his lyrics. This is not the way that everyone writes music, but it is the way that works for him. And I think this idea applies to all creative pursuits, not just songwriting. So, if you are a developer, find your own creative process and let it flourish. You will probably hear a lot about the “right” way of doing things (“Write the script first!” “You need to create a story board!”). The so-called “right” way may or may not work for you, so take it with a box of Morton salt. If I were to write my script and try to create a storyboard, it would take me three times as long to build my tutorials. I’m a visual person, so build the images and interactive elements of my tutorial first, and then I write my script. This may seem disorganized to some people, but it is how I work most effectively. From a reviewer’s perspective, I would strongly encourage you to respect the creative process of others. On this project, we do have a 25 page manual that specifies how things must be done, but our process also allows for creativity. If you look at each of the tutorials on our site, they are all different from one another. Each tutorial is a reflection of each developer’s knowledge and creativity. So if you are reviewing and approving another person’s tutorials, be careful not to impose your own preferences on their work, as long as their work meets project standards.
- When Allison submitted her tutorial we were so happy to be getting the project of the ground finally. However, we didn’t anticipate that her tutorial would bring up more issues for us to discuss, such as adding styling for the quiz elements into the template and whether or not we should mandate a maximum tutorial length, leading to more revisions to the manual. In March, we approved Allison’s tutorial as the first completed tutorial for this project, and we also sent out the revised P&P manual to the other library directors for review. Thought we had worked out all of the kinks, answered all of the questions, in going through Allison’s tutorial. We were wrong. Like Allison said, each tutorial reflects the creativity of the developer. For the committee, that has meant that each tutorial has brought up new questions for us to address. Krista Ramirez from Southeastern submitted her tutorial on library sources vs. freely available web sources in June reviewing her tutorial led us to contemplate, among other things, whether closed captioning was necessary if the content of the audio was typed on the screen. So this led to more revisions approved in August I submitted my tutorial on Understanding Types of Periodicals in November generated some discussion about how to handle the inclusion of institution-specific slides approved in December Shannon Leaper from Northwestern Oklahoma State University submitted her tutorial on Developing a Research Topic in December raised some questions about whether we wanted to require a formal assessment or if a review or reflection element was sufficient approved in January Susan Woitte from Northeastern submitted her tutorial on Plagiarism in mid-January this has, ironically, brought up questions about image copyright and citation. And that one has yet to be approved.
- So the P&P Manual has been a bit like a merry-go-round ride that we can’t get off. As each institution works on a tutorial and interprets the guidelines in their own way, they raise more questions that we need to consider and clarify in the manual.
- So we have come to realization that P&P is a living document and have come to accept the fact that we are going to need to make continuous changes. The biggest challenge here is to keep the big picture in mind – making these usable for people at different institutions with different needs – while paying close attention to a hundred small details that ensure consistency across institutions. It’s really been beneficial to have three people from different institutions and in different positions on this committee. We each bring different strengths – Allison is more creative and has the motivation to understand the ins and outs of Captivate, I am very detail-oriented and driven to ensure that each tutorial conforms to the standards, and Sharon is the big picture, long range planning person. We can really examine any given issue from multiple angles, and we’re a good representation of the other institutions, as well. [transition to website]