Over the past year, you’ve probably noticed a change in the public computing environments in Duke University Libraries. Besides new patron-facing hardware, we’ve made even larger changes behind the scenes — the majority of our public computing “computers” have been converted to a Virtual Desktop Infrastructure (VDI).
The physical hardware that you sit down at looks a little different, with larger monitors and no “CPU tower”:
What isn’t apparent is that these “computers” actually have NO computational power at all! They’re essentially just a remote keyboard and monitor that connects to a VDI-server sitting in a data-center. The end-result is really that you sit down at what looks like a regular computer, and you have an experience that “feels” like a regular computer. The VDI-terminal and VDI-server work together to make that appear seamless.
All of the same software is installed on the new “computers” — really, virtual desktop connections back to the server — and we’ve purchased a fairly “beefy” VDI-server so that each terminal should feel very responsive and fast. The goal has been to provide as good an experience on VDI as you would get on “real” computers.
But there are also some great benefits …
When a patron sits down at a terminal, they are given a new, clean installation of a standard Windows environment. When they’re done with their work, the system will automatically delete that now-unused virtual desktop session, and then create a brand-new one for the next patron. From a security standpoint, this means there is no “leakage” of any credentials from one user to another — passwords, website cookies, access tokens, etc. are all wiped clean when the user logs out.
Reduced Staff Effort:
It also offers some back-end efficiency for the Specialized Computing team. First off, since the VDI-terminal hardware is less complex (it’s not a full computer), the devices themselves have been seen to last 7 to 10 years (vs. 4 years for a standard PC). There have also been reports that they can take quite a beating and remain operational (and while I don’t want to jinx it, there are reports of them being fully submerged in water and, once dried out, being fully functional).
Beyond that, when we need to update the operating system or software, we make the change on one “golden image” and that image is copied to each new virtual desktop session. So despite having 50 or more public computing terminals, we don’t spend 50-times as much effort in maintaining them.
It is worth noting that we can also make these updates transparent to our patrons. After logging in, that VDI session will remain as-is until the person logs out — we will not reboot the system from under them. Once they logout, the system deletes the old, now-outdated image and replaces it with a new image. There is no downtime for the next user, they just automatically get the new image, and no one’s work gets disrupted by a reboot.
We can, in fact, define multiple “golden images”, each with a different suite of software on it. And rather than having to individually update each machine or each image, the system understands common packages — if we update the OS, then all images referring to that OS automatically get updated. Again, this leads to a great reduction in staff effort needed to support these more-standardized environments.
We have deployed SAP and Envisionware images on VDI, as well as some more customized images (e.g. Divinity-specific software). For managers who don’t otherwise have access to SAP, please contact Core Services and we can get you set up to use the VDI-image with SAP installed.
We recently upgraded the storage system that is attached to the VDI-server, and with that, we are able to add even more VDI-terminals to our public computing environment. Over the next few months, we’ll be working with stakeholders to identify where those new systems might go.
As the original hardware is nearing it’s end-of-life, we will also be looking at a server upgrade near the end of this year. Of note: the server upgrade should provide an immediate “speed up” to all public computing terminals, without us having to touch any of those 50+ devices.
Last week, I presented our New Project Request Process at First Wednesday. This request process is to help the Digital Strategies & Technology (DST) Leadership Team more effectively evaluate and prioritize projects that require ITS resources. Over the summer, we developed and tested a two-stage workflow aimed to lower the barrier for library staff to submit project ideas and streamline the prioritization of projects into our three new project management streams: Library Systems, led by Karen Newbery; Web Experience, led by Tom Crichlow, and Application Development, led by Cory Lown, or into the existing Operations stream, led by John Pormann.
You can view the presentation here. (My presentation begins at 35:45, but you should definitely watch Karen present on the Updated Request App and her trip to DKU.)
The quick summary notes of our process is this:
Project Summary is a short, one page summary of your project idea that includes 4 major elements:
The DST Leadership will evaluate Project Summaries within one month of submission and accept it, decline it, or request more information.
Accepted Project Summaries will be assigned a Project Lead, who will guide the Project Sponsor in writing the Project Charter.
Project Charter is an in-depth project plan that includes these elements:
Requirements – list of the high-level project requirements
Scope Statement – narrative description of the project scope
Deliverables – A deliverable is a unique and verifiable product, result or capability to perform a service that must be produced to complete a process, phase or project.
Estimated Schedule – focus on schedule and timeline, not specific dates
Completion Criteria – what must occur before project is considered complete
Goals – specific measurable objectives the project must achieve for completion
Dependencies – any outside factors, including people, data, and systems
Collaboration and communication strategy – frequency of meetings, project management tools used, plan to provide communication to those outside the project
Risks to Scope, Budget, Resources, Schedule, Technologies
Stakeholders – people outside of ITS (List of names and contact information)
Project Team – roles needed for team (Specific team members will be assigned, if project is approved and scheduled)
Budget – especially important for grant-based projects
The DST Leadership will review Project Charters within one month of submission. Accepted project charters will be prioritized based on one or more of the following:
Portfolio Management review of resources by the Director, ITS
EG input for projects involving two or more divisions, or that impact campus users, or that impact a majority of DUL staff
Input of corresponding AUL, if competing projects require same team members of an previously approved project in queue
Input from DUL department or existing committee with governance oversight of a particular area, such as WebX or Digital Preservation and Production Program
We believe this process will enable us to plan projects more effectively with project sponsors and utilize the Libraries’ resources more efficiently. We also believe this will improve communication with stakeholders and provide EG with better information to make priority decisions for projects that have benefit or impact to our staff and users.
You can download the Project Summary and Charter template here. You can submit your Project Summary to firstname.lastname@example.org.
When Duke students tour the Digital Production Center, I always show them our video digitization system, and point out that Duke Libraries’ collection of U-matic, VHS and Betacam analog videotapes are ancient relics from the last century. This fall’s first-year students were born in the new millennium. They have little use for physical media, except for perhaps an occasional external thumb-drive. Their concept of video is something you capture on your iPhone or stream online, not play using a crude plastic rectangular-shell. And rewinding videotape? “Like… what is that?, it’s so… weird!”
So, imagine my surprise when I recently walked into Raleigh’s brand new Alamo Drafthouse Cinema, and entered their Video Vortex, a massive library of over 75,000 video titles on VHS and DVD, that are free for customers to check out and watch at home. Video Vortex even rents out VHS players, another historical artifact. This may seem odd at a time and everyone is streaming movie content online. But, Video Vortex specializes in movies you can’t get from Netflix, Amazon and other streaming services. Many of their titles are out of print, and some of these films were never released on DVD, or in any digital format, so the only way you can see them is on VHS.
Walking through the VHS collection is like going to a run-down grindhouse movie theater in 1975, or tuning into an obscure cable-TV channel at 3 A.M. in 1987. Many of the films would be classified as “exploitation:” cheaply-made horror, cult or action titles that never had a chance at the Oscars, and are “so bad, they’re good,” like “Blood Orgy of the Leather Girls.” But there’s also critically acclaimed films like Frank Perry’s “Last Summer,” which earned an academy award nomination in 1969. Due to copyright issues or lack of funds, these two films have never made it into the digital realm, and can only be seen on VHS.
Josh Schafer is co-manager and “VHS Culture Captain” of Video Vortex. He moved here from New Jersey to work in the vortex, because he’s a longtime connoisseur and expert on the VHS format, and even publishes a VHS fanzine called “Lunchmeat.”
“The whole goal here is to not just reimagine the video store, and give people that feeling and experience again, but also give people this library, this community asset where both film-lovers and the casual movie-goer alike, can come in and explore all kinds of cinema, for free,” says Schafer. The Alamo’s lobby, where Video Vortex lives, is decorated with rare movie posters, giant VHS facsimiles, and has tables where film-nerds can congregate, order from the Alamo’s full kitchen and bar, and discuss their favorite obscure animation titles.
Skip Elsheimer of AV Geeks has taken on the job of helping to maintain the Video Vortex collection, which involves cleaning off mold, splicing tape, fixing cases and repairing DVDs. “A lot of these videotapes and DVDs were boxed up for years in storage spaces that were not ideal,” says Skip. “We do TLC on these titles, many of which don’t exist in any other format.”
DVDs are actually harder to fix and reclaim than videotape. Skip says the rescue rate of VHS is about 90%, because he can swap out tape, put it in a new cassette case, splice it, etc. But once the lamination separates on a DVD, or if there’s a significant scratch, it’s toast, because the laser can no longer read the data, and there’s no way to retrieve it. So much for the idea of digital = permanent. Or as the VHS Culture Captain says, “only analog is real.”
In addition to Video Vortex, Alamo Drafthouse Cinema offers a mix of first-run, independent and vintage films on 11 screens. The comfy theater seats recline, and customers can order an eclectic mix of foods, cocktails, craft-beers and wine, right from their seat. Most everyone who works at Alamo is a movie fan, and it shows in everything from the vintage movie posters that line the walls, to the enthusiasm of the employees. The only way to dampen that enthusiasm is if you talk or text in the theater, because, after one warning, you will be asked to leave, as explained in this colorful public service announcement.
I recently worked on an interactive kiosk for a new exhibit in the library — Views of the Great War: Highlights from the Duke University Libraries. Elizabeth Dunn, the exhibit curator, wanted to highlight a series of letters that shared the experiences of two individuals during the war. She was able to recruit the talents of Jaybird O’Berski and Ahnna Beruk who brought the writings of Frederick Trevenen Edwards and Ann Henshaw Gardiner to life.
Elizabeth and I booked time for Jay and Ahhna in the Multimedia Production Studio where we recorded their performances. I then edited down multiple takes into more polished versions and created files I could use with the kiosk. I also used youtube’s transcript tool to get timed captions working well and to export VTT files.
Here is an example:
The final interface allows users to both listen to the performances and read timed transcriptions of the letters while also being able to scroll through the original typed versions.
Post contributed by: Emily Daly, Thomas Crichlow, and Cory Lown
If you’re a frequent or even casual user of the Duke Libraries catalog, you’ve probably noticed that it’s remained remarkably consistent over the last decade. Consistency can be a good thing, but there is certainly room for improvement in the Duke Libraries catalog, and staff from the libraries at Duke, UNC, and NCSU are excited to replace the current catalog’s aging infrastructure and outdated user interface with an entirely new collaboratively developed open-source discovery layer. While many things are changing, one key feature will remain the same: The catalog will continue to allow users to locate and access materials not only here at Duke but also across the other Triangle Research Libraries member libraries (NCSU, NCCU, UNC).
Commitment to collaboration
In addition to an entirely new central index that supports institutional and consortial searching, the new catalog benefits from a shared, centrally developed codebase as well as locally hosted, customizable catalog interfaces. Perhaps most notably, the new catalog has been built with the needs of library and complex bibliographic data in mind. While the software used for the current library catalog has evolved and grown in complexity to support e-commerce and business needs (not higher ed or library needs), the library software development community has been hard at work building specialized discovery layers using the open-source Blacklight framework. Peer institutions including Stanford, Cornell, and Princeton are already using Blacklight for their library catalogs, and there is an active Blacklight development community that Duke is excited to be a part of. Being part of this community enables us to build on the good work already in place in other library catalogs, including more intuitive facets, adaptive linking for subjects and other fields, a more responsive user interface for access via tablets and phones, and the ability to preserve the order of MARC fields when it’s useful to researchers (MARC is an international standard for representing bibliographic and related data).
We’re upping our collaboration game locally, too: This project has given us the opportunity to develop a new model for collaborative software development. Rather than reinvent the wheel at each Triangle Research Library, we’re combining effort and expertise to develop a feature-rich yet highly customizable discovery layer that will serve the needs of researchers across the triangle. To do this, we have adopted an agile project management process with talented developers and dedicated product owners from NCSU, UNC, and Duke. The agile approach has helped us be more productive and efficient during the development phase and increased collaboration across the four Triangle Research Libraries, positioning us well for maintaining and governing the catalog after we go live.
The development team has already conducted multiple rounds of user testing and made changes to the user interface based on findings. We’re now ready to hear feedback from library staff. To facilitate this, we’ll be launching the Duke instance of the catalog to all library staff next Wednesday, August 1. We encourage staff to explore catalog features and records and then report feedback, providing screenshots, URLs, and other details as needed. We’ll continue user testing this fall and solicit extensive feedback from faculty, students, staff, and general researchers.
Our plan (fingers crossed!) is to officially launch the new Duke Libraries catalog to all users in early 2019, perhaps as soon as the start of the spring semester. A local implementation team is already at work to be sure we’re ready to replace Duke’s old catalog with the new and improved version early next year. Meanwhile, development and interface enhancement of the catalog will continue this fall. While we are pleased with what we’ve accomplished over the last 18 months, there is still significant work to be done before we’ll be ready to go live. Here are a few items on the lengthy TO DO list:
finish loading the 16 million records from all four Triangle Research libraries
integrate Duke’s request workflows so users can request items they discover in the new catalog
develop a robust Advanced Search interface in response to user demand
tune relevance ranking
ensure that non-Roman scripts are searchable and display correctly
map non-MARC metadata so items such as digital collections records are discoverable
There is a lot of work ahead to be sure, but what we will launch to staff next week is a functional catalog with nearly 10 million records, and that number is increasing by the day. We invite you to take the new catalog for a spin and tell us what you think so we can make improvements and be ready for all researchers in just a few short months.
That same team is now back for a sequel, collaborating to tackle additional issues around system integrations, statistics/reporting, citations, and platform maintenance. Phase II of the project will wrap up this summer.
I’d like to share a bit more about the DSpace upgrade project, beginning with some background on why it’s important and where the platform fits into the larger picture at Duke. Then I’ll share more about the areas to which we have devoted the most developer time and attention over the past several months. Some of the development efforts were required to make DSpace 6 viable at all for Duke’s ongoing needs. Other efforts have been to strengthen connections between DukeSpace and other platforms. We have also been enhancing several parts of the user interface to optimize its usability and visual appeal.
DSpace at Duke: What’s in It?
Duke began using DSpace around 2006 as a solution for Duke University Archives to collect and preserve electronic theses and dissertations (ETDs). In 2010, the university adopted an Open Access policy for articles authored by Duke faculty, and DukeSpace became the host platform to make these articles accessible under the policy. These two groups of materials represent the vast majority of the 15,000+ items currently in the platform. Ensuring long-term preservation, discovery, and access to these items is central to the library’s mission.
Integrations With Other Systems
DukeSpace is one of three key technology platforms working in concert to support scholarly communications at Duke. The other two are the proprietary Research Information Management System Symplectic Elements, and the open-source research networking tool VIVO (branded as Scholars@Duke). Here’s a diagram illustrating how the platforms work together, created by my colleague Paolo Mangiafico:
In a nutshell, DSpace plays a critical role in Duke University scholars’ ability to have their research easily discovered, accessed, and used.
Faculty use Elements to manage information about their scholarly publications. That information is pulled neatly into Scholars@Duke which presents for each scholar an authoritative profile that also includes contact info, courses taught, news stories in which they’re mentioned, and more.
The Scholars@Duke profile has an SEO-friendly URL, and the data from it is portable: it can be dynamically displayed anywhere else on the web (e.g., departmental websites).
Elements is also the place where faculty submit the open access copies of their articles; Elements in turn deposits those files and their metadata to DSpace. Faculty don’t encounter DSpace at all in the process of submitting their work.
Publications listed in a Scholars@Duke profile automatically include a link to the published version (which is often behind a paywall), and a link to the open access copy in DSpace (which is globally accessible).
Upgrading DSpace: Ripple Effects
The following diagram expands upon the previous one. It adds boxes to the right to account for ETDs and other materials deposited to DSpace either by batch import mechanisms or directly via the application’s web input forms. In a vacuum, a DSpace upgrade–complex as that is in its own right–would be just the green box. But as part of an array of systems working together, the upgrade meant ripping out and replacing so much more. Each white star on the diagram represents a component that had to be thoroughly investigated and completely re-done for this upgrade to succeed.
One of the most complicated factors in the upgrade effort was the bidirectional arrow marked “RT2”: Symplectic’s new Repository Tools 2 connector. Like its predecessor RT1, it facilitates the deposit of files and metadata from Elements into DSpace (but now via different mechanisms). Unlike RT1, RT2 also permits harvesting files and metadata from DSpace back into Elements, even for items that weren’t originally deposited via Elements. The biggest challenges there:
Divergent metadata architecture. DukeSpace and Elements employ over 60 metadata fields apiece (and they are not the same).
Crosswalks. The syntax for munging/mapping data elements from Elements to DSpace (and vice versa) is esoteric, new, and a moving target.
Legacy/inconsistent data. DukeSpace metadata had not previously been analyzed or curated in the 12 years it had been collected.
Newness. Duke is likely the first institution to integrate DSpace 6.x & Elements via RT2, so a lot had to be figured out through trial & error.
Kudos to superhero metadata architect Maggie Dickson for tackling all of these challenges head-on.
User Interface Enhancements in Action
There are over 2,000 DSpace instances in the world. Most implementors haven’t done much to customize the out-of-the-box templates, which look something like this for an item page:
The UI framework itself is outdated (driven via XSLT 1.0 through Cocoon XML pipelines), which makes it hard for anyone to revise substantially. It’s a bit like trying to whittle a block of wood into something ornate using a really blunt instrument. The DSpace community is indeed working on addressing that for DSpace 7.0, but we didn’t have the luxury to wait. So we started with the vanilla template and chipped away at it, one piece at a time. These screenshots highlight the main areas we have been able to address so far.
We configured DSpace to generate and display thumbnail images for all items. Then we added icons corresponding to MIME types to help distinguish different kinds of files. We added really prominent indicators for when an item was embargoed (and when it would become available), and also revised the filesize display to be more clear and concise.
Usage & Attention Stats
Out of the box, DSpace item statistics are only available by clicking a link on the item page to go to a separate stats page. We figured out how to tap into the Solr statistics core and transform that data to display item views and file downloads directly in the item sidebar for easier access. We were also successful showing an Altmetric donut badge for any article with a DOI. These features together help provide a clear indication on the item page how much of an impact a work has made.
We added a lookup from the item page to retrieve the parent collection’s rights statement, which may contain a statement about Open Access, a Creative Commons license, or other explanatory text. This will hopefully assert rights information in a more natural spot for a user to see it, while at the same time draw more attention to Duke’s Open Access policy.
Scholars@Duke Profiles & ORCID Links
For any DukeSpace item author with a Scholars@Duke profile, we now display a clickable icon next to their name. This leads to their Scholars@Duke profile, where a visitor can learn much more about the scholar’s background, affiliations, and other research. Making this connection relies on some complicated parts: 1) enable getting Duke IDs automatically from Elements or manually via direct entry; 2) storing the ID in a DSpace field; 3) using the ID to query a VIVO API to retrieve the Scholars@Duke profile URL. We are able to treat a scholar’s ORCID in a similar fashion.
Other Development Areas
Beyond the public-facing UI, these areas in DSpace 6.2 also needed significant development for the upgrade project to succeed:
Fixed several bugs related to batch metadata import/export
Developed a mechanism to create user accounts via batch operations
Modified features related to authority control for metadata values
By summer 2018, we aim to have the following in place:
Add collapsable / expandable facet and browse options to reduce the number of menu links visible at any given time.
Present a copyable citation on the item page.
Upgrade the XSLT processor from Xalan to Saxon, using XLST 3.0; this will enable us to accomplish more with less code going forward
Revise the Scholars@Duke profile lookup by using a different VIVO API
Create additional browse/facet options
Display aggregated stats in more places
We’re excited to get all of these changes in place soon. And we look forward to learning more from our users, our collaborators, and our peers in the DSpace community about what we can do next to improve upon the solid foundation we established during the project’s initial phases.
In 2008, Google released their free web browser, Chrome. It’s improved speed and features led to quick adoption by users, and by the middle of 2012, Chrome had become the world’s most popular browser. Recent data puts it at over 55% market share [StatCounter].
As smartphones and tablets took off, Google decided to build an “operating system free” computer based around the Chrome browser – the first official Chromebook launched in mid-2011. The idea was that since everyone is doing their work on the web anyway (assuming your work==Google Docs), then there wasn’t a need for most users to have a “full” operating system – especially since full operating systems require maintenance patches and security updates. Their price-point didn’t hurt either – while some models now top-out over $1000, many Chromebooks come in under $300.
We purchased one of the cheaper models recently to do some testing and see if it might work for any DUL use-cases. The specific model was an Acer Chromebook 14, priced at $250. It has a 14” screen at full HD resolution, a metal body to protect against bumps and bruises, and it promises up to 12 hours of battery life. Where we’d usually look at CPU and memory specs, these tend to be less important on a Chromebook — you’re basically just surfing the web, so you shouldn’t need a high-end (pricey) CPU nor a lot of memory. At least that’s the theory.
But what can it do?
Basic websurfing, check! Google Docs, check! Mail.duke.edu for work-email, check! Duke.box.com, check! LibGuides, LibCal, Basecamp, Jira, Slack, Evernote … check!
LastPass even works to hold all the highly-complex, fully secure passwords that you use on all those sites (you do you complex passwords, don’t you?).
Not surprisingly, if you do a lot of your day-to-day work inside a browser, then a Chromebook can easily handle that. For a lot of office workers, a Chromebook may very well get the job done – sitting in a meeting, typing notes into Evernote; checking email while you’re waiting for a meeting; popping into Slack to send someone a quick note. All those work perfectly fine.
What about the non-web stuff I do?
Microsoft Word and Excel, well, kinda sorta. You can upload them to Google Docs and then access them through the usual Google Docs web interface. Of course, you can then share them as Google Docs with other people, but to get them back into “real” Microsoft Word requires an extra step.
Aleph, umm, no. SAP for your budgets, umm, no. Those apps simply won’t run on the ChromeOS. At least not directly.
But just as many of you currently “remote” into your work computer from home, e.g., you _can_ use a Chromebook to “remote” into other machines, including “virtual” machines that we can set up to run standard Windows applications. There’s an extra step or two in the process to reserve a remote system and connect to it. But if you’re in a job where just a small amount of your work needs “real” Windows applications, there still might be some opportunity to leverage Chromebooks as a cheaper alternative to a laptop.
I’m curious to see where (or not) Chromebooks might fit into the DUL technology landscape. Their price is certainly budget-friendly, and since Google automatically updates and patches them, they could reduce IT staff effort. But there are clearly issues we need to investigate. Some of them seem solvable, at least technically. But it’s not clear that the solution will be usable in day-to-day work.
If you’re interested in trying one out, please contact me!
Did you ever stop to think about how the materials you find in the Library’s catalog search get there? Did you know the Duke Libraries have three staff members dedicated to making sure Duke’s library catalog is working so faculty and students can do their research? The library catalog is the backbone of the library and I hope by the end of this post you will have a new appreciation for some of the people who support this backbone of the library and what is involved to do that.
Discovery Services is charged with supporting the integrated library system (ILS), aka “the catalog”. What is an “integrated library system”? According to Wikipedia, “an ILS (is used) to order and acquire, receive and invoice, catalog, circulate, track and shelve materials.” Our software is used by every staff person in all the Duke Libraries, including the professional school libraries, the Goodson Law Library, the Ford Library at the Fuqua School of Business, and the Medical Center Library, and the Duke Kunshan University Library. At Duke, we have been using Ex Libris’s Aleph as our ILS since 2004.
Discovery Services staff work with staff in Technical Services who do the acquiring, receiving and invoicing and cataloging of materials. Our support for that department includes setting up vendors who send orders and bibliographic records via the EDIFACT format or the MARC format. Some of our catalogers do original cataloging where they describe the book in the MARC format, and a great many of our records are copy cataloged from OCLC. Our ILS needs to be able to load these records, regardless of format, into our relational database.
We work with staff in Access and Delivery Services/Circulation in all the libraries to set up loan policies so that patrons may borrow the materials in our database. All loan policies are based on the patron type checking out the item, the library that owns the item and the item’s type. We currently have 59 item types for everything from books, to short-term loans, sound CD’s, and even 3D scanners! There are 37 patron types ranging from faculty, grad students, staff, undergrads, alumni and even retired library employees. And we support a total of 12 libraries. Combine all of those patrons, items and libraries, and there are a lot of rules! We edit policies for who may request an item and where they can choose to pick it up, when fines are applied and when overdue and lost notices are sent to patrons. We also load the current course lists and enrollment so students and faculty can use the materials in Course Reserves.
The ILS is connected with other systems. There was a recent post here on Bitstreams about the work of the Discovery Strategy Team. Our ILS, Aleph, is represented in both the whiteboard photo and the Lucidchart photo. One example of an integration point the Library’s discovery interface. We also connect to the software that is used at the Library Service Center (GFA). When an item is requested from that location, the request is sent from the ILS to the software at the Library Service Center so they can pull and deliver the item. The ILS is also integrated with software outside of the library’s support including the Bursar’s Office, the University’s Identity Management system, and the University’s accounting system.
We also export our data for projects in which the library is involved, such as HathiTrust, Ivy Plus, TRLN Discovery (coming soon!), and SHARE-VDE. These shared collection projects often require extra work from Discovery Services to make sure the data the project wants is included in our export.
Discovery Services spent the fall semester working on upgrading Aleph. We worked with our OIT partners to create new virtual servers, install the Aleph software and upgrade our current data to the new version. There were many configuration changes, and we needed to test all of our custom programs to be sure they worked with the new version. We have been using the Aleph software for a more than a decade, and while we’ve upgraded the software over the years, libraries have continued to change.
We are currently preparing a project to migrate to a new ILS and library services platform, FOLIO. That means moving our eight million bibliographic records and associated information, our two million patron records, hundreds of thousands orders, items, e-resources into the new data format FOLIO will require. We will build new servers, install the software, review and/or recreate all of our custom programs that we currently use. We will integrate FOLIO with all the applications the library uses, as well as applications across campus. It will be a multi-year project that will take thousands of hours of staff time to complete. The Discovery Services staff is involved in some of the FOLIO special interest groups working with people across the world who are working together to develop FOLIO.
We work hard to make it easy for our patrons to find library material, request it or borrow it. The next time you check out a book from the library, take a moment to think about all the work that was required behind the scenes to make that book available to you.
Last week, an indefatigable team at Duke University Libraries released an upgraded version of the DukeSpace platform, completing the first phase of the critical project that I wrote about in this space in January. One member of the team remarked that we now surely have “one of the best DSpaces in the world,” and I dare anyone to prove otherwise.
DukeSpace serves as the Libraries’ open-access institutional repository, which makes it a key aspect of our mission to “partner in research,” as outlined in our strategic plan. As I wrote in January, the version of the DSpace platform that underlies the service had been stuck at 1.7, which was released during 2010 – the year the iPad came out, and Lady Gaga wore a meat dress. We upgraded to version 6.2, though the differences between the two versions are so great that it would be more accurate to call the project a migration.
That migration turned out to be one of the more complex technology projects we’ve undertaken over the years. The main complicating factor was the integration with Symplectic Elements, the Research Information Management System (RIMS) that powers the Scholars at Duke site. As far as we know, we are the first institution to integrate Elements with DSpace 6.2. It was a beast to do, and we are happy to share our knowledge gained if it will help any of our peers out there trying to do the same thing.
Meanwhile, feel free to click on over to and enjoy one of the best DSpaces in the world. And congratulations to one of the mightiest teams assembled since Spain won the World Cup!
Just over one year ago, Duke University Library’s Web Experience team charged a new subgroup – the Discovery Strategy Team – with “providing cohesion for the Libraries’ discovery environment and facilitate discussion and activity across the units responsible for the various systems and policies that support discovery for DUL users”. Jacquie Samples, head of the Metadata and Discovery Strategy Department in our Technical Services Unit, and I teamed up to co-chair the group, and we were excited to take on this critical work along with 8 of our colleagues from across the libraries.
Our first task was one that had long been recognized as a need by many people throughout the library – to create an up-to-date visualization of the systems that underpin DUL’s discovery environment, including the data sources, data flows, connections, and technical/functional ownership for each of these systems. Our goal was not to depict an ideal discovery landscape but rather to depict things as they are now (ideal could come later).
Before we could create a visualization of these systems and how they interacted, however, we realized we needed to identify what they were!This part of the process involved creating a giant laundry list of all of systems in the form of a google spreadsheet, so we could work on it collaboratively and iteratively. This spreadsheet became the foundation of the document we eventually produced, containing contextual information about the systems including:
Name(s) of the system
Links to documentation
Technical & functional owners
Once we had our list of systems to work from, we began the process of visualizing how they work here at DUL. Each meeting of the team involved doing a lot of drawing on the whiteboard as we hashed out how a given system works – how staff & other systems interact with it, whether processes are automated or not, frequency of those processes, among other attributes. At the end of these meetings we would have a messy whiteboard drawing like this one:
We were very lucky to have the talented (and patient!) developer and designer Michael Daul on the team for this project, and his role was to take our whiteboard drawings and turn them into beautiful, legible visualizations using Lucidchart:
Once we had created visualizations that represented all of the systems in our spreadsheet, and shared them with stakeholders for feedback, we (ahem, Michael) compiled them into an interactive PDF using Adobe InDesign. We originally had high hopes of creating a super cool interactive and zoomable website where you could move in and out to create dynamic views of the visualizations, but ultimately realized this wouldn’t be easily updatable or sustainable. So, PDF it is, which may not be the fanciest of vehicles but is certainly easily consumed.
We’ve titled our document “Networked Discovery Systems at DUL”, and it contains two main sections: the visualizations that graphically depict the systems, and documentation derived from the spreadsheet we created to provide more information and context for each system. Users can click from a high-level view of the discovery system universe to documentation pages, to granular views of particular ‘constellations’ of systems. Anyone interested in checking it out can download it from this link.
We’ve identified a number of potential use cases for this documentation, and hope that others will surface:
New staff orientation
We’re going to keep iterating and updating the PDF as our discovery environment shifts and changes, and hope that having this documentation will help us to identify areas for improvement and get us closer to achieving that ideal discovery environment.
Notes from the Duke University Libraries Digital Projects Team