Using ArchivesSpace

For a class I taught in summer 2014 at the Univ. of Texas at Austin School of Information, students used a basic installation of ArchivesSpace to create collection descriptions. The public interface of the ArchivesSpace installation they used is no longer available.

We did not have any kind of membership agreement with ArchivesSpace at the time I taught the class. I will note that working through ArchivesSpace without access to the members-only help is very frustrating. While the web-based interface to the system is fairly well documented (mostly taking the form of roll-over tooltips), the overall usability of the interface is only adequate, and the system would require extensive customization and configuration to be usable in an archival setting. Substantial configuration of the system would require back-end access to the server, which I don’t currently have.

The labs I created for students were minimal. Students did create some tutorials as one of their assignments; if I can get permission from students to share them, I’ll add some of them here, as well.

ArchivesSpace Labs & Instructions

  • Creating Accessions and Resources (pptx)
  • Creating Subject and Agent Authority Records (pptx)
  • Creating Rights Statements and Events (pptx)
  • Exporting EAD (pptx)
  • ArchivesSpace User and Group Management (docx)

ArchivesSpace Bugs and “Features”

Interface Issues

1. A default configuration of ArchivesSpace has “Help” links that go to the members-only documentation. Not very helpful. You can suppress the Help settings by changing the following options in archivesspace/config/config.rb:

## Help Configuration
#AppConfig[:help_enabled] = true
#AppConfig[:help_url] = “”
#AppConfig[:help_topic_prefix] = “/Default_CSH.htm#”

2. The default configuration of ArchivesSpace is apparently hard-coded to use “localspace” as the URL of the collection. The link to go from the public interface to the staff interface shows up as http://localhost:8080/ (and the public interface is conversely linked as http://localhost:8081/):

ArchivesSpace localhost

The settings for this are controlled in archivesspace/config/config.rb. To customize URLs, uncomment and modify the following settings:

#AppConfig[:backend_url] = “http://localhost:8089”
#AppConfig[:frontend_url] = “http://localhost:8080”
#AppConfig[:frontend_prefix] = proc { “#{URI(AppConfig[:frontend_url]).path}/”.gsub(%r{/+$}, “/”) }
#AppConfig[:solr_url] = “http://localhost:8090”
#AppConfig[:public_url] = “http://localhost:8081”
#AppConfig[:public_prefix] = proc { “#{URI(AppConfig[:public_url]).path}/”.gsub(%r{/+$}, “/”) }

3. The interface breaks if you scale the text up or shrink the window down. And when I say “breaks,” I mean in fairly unhelpful ways:

ArchivesSpace interface fail

The interface as it ought to appear:

ArchivesSpace home page

Adding an Agent

1. There is a nice little Plug-In for LCNAF Import. At least, it seems nice until you try to use it and have to parse through the MARC data for the various possible matches. It is actually pretty unusable.

ArchivesSpace LCNAF Plug-in

2. If you choose to Add an Agent –> Person, you note that LCNAF is not a possible source. ULAN is.

ArchivesSpace Agent Source drop-down

3. It is possible to add LCNAF to the list of controlled values in the drop-down box; the list to look for is name_source. Unfortunately, you can’t create both the short-form and translation; whatever you enter in the Value of the Add Source pop-up will also be used as the Translation.

ArchivesSpace Create Value

Adding a Resource

1. The Language field in the Basic Information panel is not marked as a required or even a recommended element, but if you don’t add the information you will get a warning when you try to save the resource.

ArchivesSpace Resource Language tooltip

2. Dates. If you add a date, the Expression is marked as “Conditionally Required … Required when a normalized date is not recorded.”

ArchivesSpace Resource Dates Expression tooltip

However, there is a bug that only appears if you select Bulk Date from the drop-down and you add normalized dates without also adding an Expression. If you don’t add any dates, you get an error on save, which is correct. If you add normalized dates but don’t also add an Expression, you get an error that only shows up when you export the EAD. The error file is attached, but it’s pretty cryptic. It took me a while to figure out and almost make one of my students have a nervous breakdown. Perhaps it ought to pop up as an HTML pop-up (though it would be pretty unhelpful even so), but instead it’s saved as an XML file with the name of the resource, as if it really were EAD.

The error as it would appear if it were HTML (which it’s not; the original filename here is 001.TX-LS.US_ead.xml):

ArchivesSpace error

The error as it appears if you open the xml file in a text editor, as if it were EAD. Trying to run a transform on it fails, of course, as my student found out the hard way.

ArchivesSpace EAD error

3. Finding Aid Data –> Description rules is an optional drop-down to select the content standard used. “Describing Archives: A Content Standard” is listed twice. Perhaps the second entry was supposed to refer to the 3rd edition? All of the tooltips refer to the second edition.

ArchivesSpace Content Standard drop-down

This is an editable list of values (many are not), so I could delete the redundant entry (although you can’t delete one once it has been used) or merge it with the other DACS entry, which is what I did (make sure that you merge the bad one into the good one, to preserve the short name for the drop-down). I also added a new entry DACS 2nd edition, but I can’t create both a short value (dacs2) and translation, as noted above.

ArchivesSpace Content Standard Controlled Value list

4. Adding Instances of Digital Objects with links. From a Resource (or any child element), go to the Instances section. Add a new Digital Object. A non-Digital Object Instance would be used to manage physical instances (boxes, folders, etc.).

 Screen Shot 2014-07-27 at 12.05.21 PM

In the File Version section of the Digital Object, add a valid URL as the URI. Make sure that Publish is marked as True. I’m not sure about the XLink settings; changing them doesn’t seem to affect the public interface, but the values do export to the EAD.

Screen Shot 2014-07-27 at 12.05.38 PM

Adding multiple File Versions is possible, but in my test only the first File Version appeared in the EAD output (though both appear in the public interface). If you want multiple hyperlinks in your EAD, it seems like you need to create a separate Digital Object for each one.

Alternatively, if you already have Digital Objects, you can associate them with a resource through the Instances panel. Click “Add Digital Object” and type a few letters of the name of the Digital Object you want to add in the search box. ArchivesSpace will attempt to identify possible Digital Objects in the same repository. You can click on the name of a Digital Object to view it (you have to click on the View button that pops up; the Digital Object will open in a new window/tab, so you don’t lose any changes you’ve made the the Resource you’re editing).

Screen Shot 2014-07-27 at 7.01.50 PM

When you have selected the correct Digital Object(s), save the resource. Although it’s tempting to click “Add Digital Object” again to confirm the addition, you should not do that. That button simply causes a new Digital Object entry box to appear.

Screen Shot 2014-07-27 at 7.00.55 PM

If you try to save the resource with an empty Digital Object, you will get a rather cryptic error:

 Screen Shot 2014-07-27 at 7.01.21 PM

Make sure the resource and all the children, etc. are published. You should be able to view your resource in the public interface to confirm that the digital objects exist and have hyperlinks.

Another bug in ArchivesSpace occurs if you select “Add Digital Object” from the Instances panel

A note about XLink: In general, the XLink Show Attribute “New” is supposed to cause the resource to open in a new window, while “embed” ought to work like an <img> element in HTML. The XLink Show Attribute “onLoad” ought to make an embedded image embed immediately, while “onRequest” should suppress it until it is clicked. See for more information. I don’t know why these don’t work in the ArchivesSpace public interface.


I’m not quite sure what sorts of events ArchivesSpace logs internally. It does create an event when transferring a resources from one repository to another. It does not log creation or deletion of resources or even accessions as events that can be viewed from the web interface. If I were to use the system in an archival setting, I’d want to be able to customize which events get logged. I’d also want to have an option to make copies of accessions/resources/digital objects — not just export the EAD or whatever, but actually start working on a record in a sandbox (which could be set not to have any public interface) and copy it over to a repository when ready, without deleting the original.

ArchivesSpace does have some logging at the backend. You can config this in archivesspace/config/config.rb:

## Log level for the backend, values: (everything) debug, info, warn, error, fatal (severe only)
#AppConfig[:backend_log_level] = “debug”

I need to experiment with this to see if anything useful gets logged with different settings.

In general, I’m not comfortable working on live systems. I want to have some level of version control in everything I’m doing. In my class, either I or a student managed to delete an accession the student had put a tremendous amount of work into. Poof! All gone, with no record of the work. This was an accession record — I don’t think you should be able to just delete those out of the system without leaving some trace of what happened.

Most of the issues listed here are just bad design, I think. The EAD export when using the Bulk Dates has been reported as an actual bug, as has the error message concerning empty Digital Objects. I’m assuming that the “Send Feedback” link actually works, of course; I haven’t yet received confirmation that a bug report was in fact received by anyone at ArchivesSpace.

DPLA Hackathon Reflections

On Sunday, April 27, 2014, I coordinated a hackathon focused on the DPLA API as part of the Texas Conference on Digital Libraries. The hackathon was sponsored by the Texas Digital Library and The University of Texas at Austin Libraries, with support from DPLA.

This was pretty overwhelming for me. I’d never coordinated a hackathon before. In fact, I’d never really attended a hackathon before, at least not one that produced actual code. The genesis of the event was a call for workshop proposals from the conference organizers in November 2013. As a DPLA Community Rep, I knew that I’d like there to be an event that focused on DPLA, and I wanted it to be a technical event to attract developer-types. In January 2014, I asked the conference organizers for their thoughts, secretly hoping that someone else had already proposed something. No such luck! While the organizers supported the idea of a hackathon (organized by “not-them”), they were limited in terms of options. We finally decided to squeeze the event into a half-day and to hold it on Sunday, the day before the conference was to begin. This meant that the event could be free and that people from outside of Austin could attend without having to pay for an extra night at the hotel, at least in most cases. However, it meant that the time available for actual hacking would be limited.

Hacking DPLA at TCDL, 2014-04-27

Hacking DPLA at TCDL, 2014-04-27. Ben Brumfield is talking about pair programming.

I did some research on hackathons before we opened registration. A few of the things I learned:

  • Organizing a hackathon is not a one-person task. It’s best to have a group of people with a variety of interests and technical abilities. I was fortunate to get a great team of people together to help me with this. Special thanks go to Rachel Vacek and Sean Watkins, at the University of Houston Libraries, Ben Brumfield with From the Page, Jennifer Hecker from the UT Libraries, and Kristi Park from the Texas Digital Library.
  • There are resources available to help with some of the simple organizational tasks, like registration, announcements, and project formation. I decided to use HackerLeague, which is free for this level of use. Information about our hackathon, Hacking DPLA at TCDL, is still available.
  • A half-day is not enough for meaningful hacking. Most hackathons are a full day or longer; a day and a half seems like a nice option. To maximize our limited time, the organizers decided to do some pre-hacking so that we would be starting the session with some projects that people could join, if they so desired. This also meant that the organizers were familiar with DPLA and other projects that used the DPLA API.
  • Organizers don’t get to hack. We actually bent this rule a bit, with various organizers leading small group projects, but it’s true that my time and attention was divided between the group I was working with and logistical issues that arose.
  • Set a goal for the event in advance. Our goal: Introduce people to DPLA and the DPLA API, with an emphasis on how the API can be used to build neat tools. Hackathon will be a learning environment, and participants will have opportunities to work at their own pace through examples.

We announced the event and opened registration about a month in advance of the event. Soon after we opened registration, I started getting email from people who were interested in the hackathon but who were concerned that they didn’t have enough technical ability to participate. In March 2014, I’d had the opportunity to attend the LTG Summit, also held in Austin. At this event, I was made aware of the extent to which many women, non-white males, individuals with disabilities, and LBGT have been excluded from opportunities in the field of technology, even within the library profession. I didn’t want this to be an issue with our hackathon, so I reassured all people who contacted me that they were welcome and tweaked the wording of the event description to say that it was open to anyone interested in hacking. In the end, almost a third of the 19 people who attended described themselves as beginner coders or user and content specialists who didn’t do much, if any, coding.

DPLA API Search tutorial

Danielle Cunniff Plumer works with beginner coders as they go through the DPLA API Search Tutorial.

My main personal contribution to the pre-hacking was the development of a beta tutorial showing how the DPLA API could be used. My example was a simple search form with results; I took ideas for the code from two existing DPLA Apps, the DPLA Search Widget developed by  Dean Farrell and Josh Wilson, and the EBSCO Discovery Service and DPLA Highlights app developed by Eric Frierson, who was generous enough to send me the app source code. I modeled my tutorial on the Railsbridge for Women Intro to Rails tutorial, though I decided to use PHP as the basis for development since I’m more comfortable in that language. The tutorial is available at and the complete code is available at

Dan Cohen, DPLA

Dan Cohen introducing the DPLA platform at the Hacking DPLA at TCDL event, 2014-04-27.

We got incredibly lucky with our hackathon, because Dan Cohen, Executive Director of DPLA, was scheduled to be the first keynote speaker at TCDL on Monday. He was able to come in early and attend the hackathon, although he had to catch an insanely early flight on Sunday to do it. Thank you, Dan!

Our half-day followed this schedule:

12:30-1:00 p.m.  –  Snack and socialize
1:00-1:15 p.m.  –  Introduction to DPLA
1:15-1:30 p.m.  –  Introduction to DPLA apps
1:30-2:00 p.m.  –  Sample DPLA app projects
2:00-2:30 p.m.  –  Break and Pair Up
2:30-4:30 p.m.  –  Hacking
4:30-4:45 p.m.  –  Reports from teams
4:45-5:00 p.m.  –  Closing thoughts and next steps

I learned some valuable lessons along the way:

Hacking DPLA at TCDL

Hacking DPLA at TCDL, 2014-04-27. Individuals and groups are working on projects.

  • A half-day is just not enough. I think that if we’d been able to follow our half-day hackathon with a full-day of hacking, we’d have really gotten somewhere, though I suspect that only about half of the participants would have come back for the second day.
  • Build in time for introductions and project planning. We jumped directly from reviewing the app projects that the organizers had prepared in advance to working on projects in groups. Participants reported at the end of the day that they wished that they’d had a chance to get to know the other attendees a bit more and to share ideas for projects and other activities during our hacking time.
  • Terminology matters. The term “hackathon” is perhaps not the best way to describe this event. A few participants approached me quietly at the end of the day and asked about it. They clearly had negative perceptions of the term “hacker,” which is often used as a pejorative, sometimes with hints of criminality, in mainstream news reporting. I’m not quite sure what else to use, but it might be best to stick with the “AppFest” label that DPLA has previously used.
  • Lead time. From start to finish, we had three months of planning time. The announcement about the event went out about four weeks in advance, which was not enough lead time for people who were planning to fly in to the conference. Depending on your audience, you should announce the event about three months out (with a reminder at eight and four weeks out). Other than the travel issues, I don’t think having additional time to prepare would have helped us.
  • Room layout. A flexible layout is best. We were in a classroom with tables that could be rearranged, but even so people seemed to be awkwardly clumped around the room. Break-out rooms with space for 3-4 people each would be ideal, especially if they provided projectors to allow people to share their screens more easily. I had an extra projector with me, but I didn’t know until the end of the day that one of the groups had wanted to use one.
  • Internet. The Texas Digital Library staff arranged for us to have wireless Internet, and it was thankfully robust. The day before the event, the question of whether we would have reliable Internet occurred to at least three of the organizers separately. Without robust Internet access, I think we’d just have gone home. How do you test an API if there’s no Internet?
  • Promotion. I had intended HackerLeague to be the main entry point for our event, but I also created an event on Facebook and I thought about cross-promoting the event on and LinkedIn, as well, though I didn’t get around to it. I and other organizers also sent notices out to a variety of email lists. As a result, it was difficult to keep track of who might have seen what. People registered through HackerLeague and Facebook and notified me by email that they wanted to come. In the end, I was glad that I didn’t do the and LinkedIn cross-promotion, because it was difficult to manage all the different channels. Using a service like MailChimp or ConstantContact might have helped, but would have cost money. In future I would prefer that registration be handled though the main conference registration, though that, too, would apparently cost money.
  • Registration and attrition. I counted a total of 26 pre-registrants before the event. I put together a separate information form about a week before the event, with the goal of finding out about the technical background of participants, but only about half of the people who had previously indicated interest filled it out. We ended up with 19 people at the event, though only 14 stayed for the whole thing. Those attrition rates, while high, are not unusual for a free event, especially one held on a Sunday, but it did make planning things like food and drink more challenging.
  • Supplies. I provided supplies for participants in case the needed them. I had pads of paper, highlighters and markers, pens and pencils, post-it notes and dry erase markers. In the end, I don’t think any of them were used, but it is good to have those sorts of things available, especially for events that are more focused on designing new apps or functionality.
  • Food and drink. I provided sodas (diet and regular), bottled water, veggies and dip, fruit, and a variety of cookies. The total expense came to about $3.00 per attendee, but in reality we had a lot of food and drink left over. We didn’t know what to expect, so I didn’t solicit sponsorships from grocery stores or other possible sponsors. I’d definitely recommend doing that and also not opening up everything at the beginning, so that unused product could be returned.
  • Swag. DPLA provided t-shirts for the organizers and swag, in the form of stickers, for attendees. This was very popular. I suspect we could have sold t-shirts (I had one t-shirt left over that didn’t fit any of the organizers, and a participant begged me for it at the end of the day).
  • Sponsorships. We did not seek formal sponsorships outside of the Texas Digital Library, who provided the Internet, The University of Texas at Austin Libraries, who provided the room, and DPLA, who provided swag and t-shirts for the organizers. In part this was because we didn’t know where we would need assistance. Our only expenses were for food, which came to a total of $75, and a few supplies that I provided. We could have used sponsorship funds to pay for these items, for parking vouchers for attendees (parking in a University garage cost about $15 for an afternoon), and to help defray costs associated with registration, etc. In future, I would budget approximately $25 per attendee per day for those costs. I’d prefer not to charge a registration fee, or, if we did to offer scholarships to help people whose institutions couldn’t support them.

Highlights of the event:

Sara Brumfield at Hacking DPLA at TCDL

Sara Brumfield talking about using Yahoo! Pipes to interact with the DPLA API at the Hacking DPLA at TCDL event, 2014-04-27.

  • Dan Cohen (@dancohen) talking about the DPLA platform and how events like this one help build the DPLA community.
  • Rachel Vacek (@vacekrae) reviewing some DPLA apps and discussing cool concepts for future app building.
  • Sean Watkins (@seanwatkins) showing off his DPLA Display proof of concept for using the DPLA API along with Web Sockets. This small web application displays images, much like a picture floating screensaver, on a remote display, while users control the images being viewed from a mobile device.
  • Eric Frierson (@frierson) showing off his EBSCO DPLA Widget that adds DPLA results to EBSCO database displays and DPLA Nearby Search Widget that uses the Geoplugin PHP Webservice and Google Maps API to display DPLA results tied to a specified location.
  • Sara Brumfield (@saracarl) helping beginners learn how to use Yahoo! Pipes to parse the DPLA API. Tutorial outline
  • Danielle Cunniff Plumer (@dcplumer) releasing a beta tutorial for a DPLA Search Widget that walks new users through the process of creating a search widget in PHP with the DPLA API.
  • Ben Brumfield (@benwbrum) and Jessica Wood working on a Respect My Authority app that builds from a suggestion provided on the DPLA Hacking Projects page.

The consensus of the people who stuck with it until the end was that we should do this again. I’ve already started discussing time and space considerations with the Texas Digital Library staff, and they’re interested in sponsoring more technical opportunities like this one. If you’re interested in attending one of these events, or if you’d like some advice for planning for your own event, feel free to contact me at

Hacking DPLA at TCDL – recap

Thank you to everyone who turned out for the Hacking DPLA at TCDL event! We had a total of nineteen people participate — about right for our first-ever event.

Hacking DPLA at TCDL, 2014-04-27

Hacking DPLA at TCDL, 2014-04-27. Ben Brumfield is talking about pair programming.

Highlights of the event:

  • Dan Cohen @dancohen talking about the DPLA platform and how events like this one help build the DPLA community.

    Dan Cohen, DPLA

    Dan Cohen introducing the DPLA platform at the Hacking DPLA at TCDL event, 2014-04-27.

  • Rachel Vacek @vacekrae reviewing some DPLA apps and discussing cool concepts for future app building.
  • Sean Watkins @seanwatkins showing off his DPLA Display proof of concept for using the DPLA API along with Web Sockets. This small web application displays images, much like a picture floating screensaver, on a remote display, while users control the images being viewed from a mobile device.
  • Eric Frierson @frierson showing off his EBSCO DPLA Widget that adds DPLA results to EBSCO database displays and DPLA Nearby Search Widget that uses the Geoplugin PHP Webservice and Google Maps API to display DPLA results tied to a specified location.
  • Sara Brumfield @saracarl demonstrating how to use Yahoo! Pipes to parse the DPLA API.

    Sara Brumfield at Hacking DPLA at TCDL

    Sara Brumfield talking about using Yahoo! Pipes to interact with the DPLA API at the Hacking DPLA at TCDL event, 2014-04-27.

  • Danielle Cunniff Plumer @dcplumer releasing a beta tutorial for a DPLA Search Widget that walks new users through the process of creating a search widget in PHP with the DPLA API.

Special thanks to my event co-organizers, Rachel Vacek from the University of Houston, Sean Watkins from the University of Houston, Ben Brumfield from From the Page, and Jennifer Hecker from the University of Texas at Austin for their help pulling this together, and to the amazing Kristi Park from the Texas Digital Library for helping with event logistics.


Tagged with: ,

Hacking DPLA at TCDL

As part of the Hacking DPLA at TCDL event scheduled for April 27, 2014, I’m developing a tutorial for using the DPLA API. I’m starting with the DPLA Search Widget developed by Dean Farrell and Josh Wilson.

This widget, a WordPress plugin, allows a website visitor to enter one or more keywords and perform a search. The visitor is then taken to the DPLA site, where the search results are displayed.

The widget is great, as far as it goes. It is particularly nice in that people do not have to request an API key to use the widget. Although the basic download is in the form of a WordPress plugin, the code can also be used in a straight HTML environment. Users just need to insert a different chunk of code on their webpage:

<script src=""></script>
<div id="dpla_search_widget"></div>

The first line would usually go in the <head> area, as per the instructions at, but it works if it’s in the <body>, which might be easier for people using content management systems.

However, there are a few limitations that I have noted:

  1. Minor quibble, but I don’t like the search button, which has white text in a light gray button on my site. I’d also like the input area to be a bit wider, so it doesn’t look quite so squished.
  2. I don’t want visitors to leave my site. It would be better if the results were returned in a page that has the look and feel of my site. Barring that, I’d at least want the results to appear in a new tab or page, rather than in the same page.
  3. Advanced search. I can’t help it, I’m a librarian. I want to be able to limit my search to words in a title, or to authors, or even to known items. The DPLA site doesn’t allow advanced search, either, but the API does. Hmmm.
  4. This is a WordPress plugin. I need to examine the code to see whether it can be used nicely outside of WordPress.

So, I have a few tasks. First up, I want to examine the code. To do that, I go to the GitHub site for the plugin,, and download the code. The package is pretty simple; it consists of an image of the DPLA logo, a readme file, and a PHP file with the following code:

Plugin Name: DPLA Search Widget
Plugin URI:
Description: Plugin for displaying a search form to search the Digital Public Library of America
Author: Dean Farrell
Version: 0.1
Author URI:

function dpla_search_widget_load() {
 wp_register_script('add-dpla-widget-js', '', '', null,'');

add_action( 'wp_enqueue_scripts', 'dpla_search_widget_load');

Hmmm. To dig a bit more deeply into this, I check out

var DPLAWidgetConfig = {
            css_href: '',
            dpla_logo: ''

;(window.onload = function() {
    var css = document.createElement('link');
    css.href = DPLAWidgetConfig.css_href;
    css.type = 'text/css';
    css.rel = 'stylesheet';

    var headTag = document.getElementsByTagName('head')[0];

    var widgetImg = document.createElement('img');
    widgetImg.src = DPLAWidgetConfig.dpla_logo;
    widgetImg.title = 'Search the DPLA!';
    widgetImg.alt = 'Search the DPLA!';

    var form = document.createElement('form');
    form.method = 'get';
    form.action = ''; = 'dpla_search_widget';

    var widgetInputDiv = document.createElement('div'); = 'dpla-form-input';
    var search = document.createElement('input');
    search.type = 'text';
    search.placeholder = 'Search the DPLA!'; = 'q';
    var submit = document.createElement('input');
    submit.type = 'submit';
    submit.value = 'Search';


    var search_div = document.getElementById("dpla_search_widget");


Okay, there’s stuff going on here that I can work with. I’ll take these in order, as I numbered them above.

  1.  I note that there’s a CSS file that probably controls the color of the button. Let me take a look at that.
#dpla_search_widget {
  background-color: #FFFFFF;
  padding: 5px 5px 10px;
  margin: 3px;
  width: 200px;    
  height: 80px;

#dpla_search_widget input[type=text],
#dpla_search_widget input[type=submit] {    
    border: 1px solid #739AAE;
    -moz-border-radius: 5px;
    -webkit-border-radius: 5px;
    border-radius: 5px;
    vertical-align: bottom;    
    font-family: 'source_sans_pro_semiboldRg',arial,sans-serif;        
    font-size: 12px;
    font-weight: normal;    

#dpla_search_widget img {
  float:none !important;
  position: relative !important;
  box-shadow: none !important;

#dpla_search_widget form {  
    margin: 0;
    padding: 0 0 5px 5px;

#dpla_search_widget input[type=text] {
    color: #818285;
    width: 110px !important;    
    padding: 0 0 0 10px;  
    height: 25px;    

#dpla_search_widget input[type=submit] {
    cursor: pointer;
    color: white;
    background-color: #739AAE;
    margin-left: 5px;
    width: 60px;
    height: 25px;    

Yep, I see that the CSS for #dpla_search_widget input requests a background color of #739AAE, but for some reason that isn’t rendering correctly on my site. Probably it conflicts with my CSS. For a simple fix, I’ll just leave the background color as is and change the text to the same gray used in the input area (#818285). I can also increase the width to 120px, but then I’ll have to increase the width of the whole widget a little bit, as well.

  1. Going back to the JavaScript file, I see that the form is created at var form = document.createElement('form'); using a get method. I can try adding = '_blank'; here. Because the widget as it stands is just sending people to the DPLA site, there’s no way to get my preferred behavior, which would be to have the results appear on my site.
  1. Advanced search. Okay, again I don’t think there’s any way to solve this without going to the API.

To test this, I need to do three things:

  1.  Save the code to text documents that I can edit, and then upload the new code to my site. becomes, and becomes
  2. Create an HTML page to test the results. You can see this at (the original version is available at
  3. Once I’m happy with the results, modify the plugin for my site to use my version in WordPress. And here it is:

Next up: working with the API. I hope this whets your appetite for more! If so, please join us at the Hacking DPLA at TCDL event on Sunday, April 27, 2014, at the UT Austin, Perry-Castañeda Library, 1.124.