I have great news: the South Carolina Historic Properties Record is now live and can be explored at http://schpr.sc.gov! After much cobbling together of code, I present: SCHPR! (Or Morgan's Monster!!!) Below is a snapshot of the home page featuring tutorials, a carousel of images, and an interactive map of the SC counties. As with any website, I will need to make changes based on user feedback for a better user experience. We have some quirks that need to be resolved (like image captions only sometimes appearing), but overall, I'm happy with the site's performance. If you have a chance to look it over, send me a note on what you think of it!
0 Comments
By the process of elimination of every other acronym we could fathom (including SARA and HARIS), we at the South Carolina SHPO finally gave the historic properties database its real name. We present to you, the South Carolina Historic Properties Record, or SCHPR (pronounced "Skipper.") Of course, "Skipper" brings to mind several different mental images: Barbie's kid sister, an exuberant Labrador retriever, and of course, the penguin from Madagascar. That last one is my favorite. I am currently in the process with our IT Department of moving our instance of CA and SCHPR from it's current server to two new servers. The first is for the core backend database instance (Providence); the second, the public facing interface (Pawtucket). Finally, media will rest on yet another server that regularly backs up to a safety net. All of this separation is for at least two reasons.
1. An increased performance speed and ability. Currently, our instance of CA is running in a Windows 7 UI. This setup is fine for a test of the system. But in the long run, it's not the most efficient platform for the database. We're moving the backend to live in a Windows Server environment instead. 2. Safety and security. In my mind, I can't begin to understand why anyone would want to try to hack into a historic properties database. But it's not as silly as it might seem. In fact, the point of breaking into a site like this would be to gain a foothold. So if our front end was directly connected to the backend, and the backend to the network, then anyone ramming into our database would simply find themselves with a nice place to rest and think about where to move laterally from there. So really, it's just a best practice to separate out the front and back ends. I'll be working on this new setup in November. At the moment, our plan is to have SCHPR launched in January 2016. At this point, we have 16870 objects with associated metadata in SCHPR; this includes historic properties, historic resource surveys, and national register listings. We have about 50 digitized items associated with historic properties also in SCHPR. Going forward, the goal is to finish uploading all of our born-digital metadata -- historic property information in Access -- and begin data entry from and digitization of legacy data -- historic property site cards in the archives. We'll also work on a batch media upload of digitized national register files. All that said, when SCHPR does go live in January, it will have plenty of material already present. We'll just be working on bulking it up even more. I'll keep you posted! Although the Historic Properties Database was technically ready for beta testers on April 1st, we weren't able to distribute it until this week. I'm glad to have it off my hands for a little while. There are a lot of things that need to be done with the project that don't involve messing with the front end which I'll be working on:
1. Adding metadata for National Register Listings 2. Prepping/standardizing the rest of the data in the Newberry Survey 3. Prepping/standardizing data from another county's survey 4. Adding unique data for Newberry County National Register properties 5. Attend a workshop planning conference call for the NCSHPO tech committee 6. Attend a PALMCOP board meeting to discuss an upcoming event 7. Take care of treasurer duties for PALMCOP 8. Attend and monitor South Carolina's Historic Preservation Conference Although the road to putting out my prototype (powered by CollectiveAccess2015) was bumpy, I think I can say it's been a productive venture. We've learned a lot from the process. Most importantly, though, we're now able to learn from some of our users' feedback. I plan on gathering input and going back to the drawing board on May 1st with whatever contributions I have from the beta-testers. I expect to namely update the look, depth, and usability of the site. I'm excited (nervous!) to hear back from our users! Several weeks ago, I had someone on Twitter ask me what I thought of CollectiveAccess. To be frank, at that point I didn't really know how I felt about CA. Now, however, I can give a detailed description of the what makes CA user friendly and likeable.
1. Let's state the obvious: IT'S FREE. That's a huge deal for a lot of cultural heritage institutions right now. There just isn't always money to dedicate to a new system. And if there is money, there might not be enough. Or the institution really needs to prioritize something else over your project. Either way, a free tool is always a plus. 2. It's open-source. This allows for a much greater level of customization than some out of the box tools. For example, I could create a metadata schema to build the system around and customize user interfaces. Another bonus to this is that users/developers share their code/documents. 3. CA allows for (perhaps even focuses on) item level description! This is a huge deal for me since I'm creating a database that needs representations for each historic property and its corresponding site card. 4. Data entry can be performed through the cataloguing back-end (Providence). This tool is user-friendly for any staff member with a little training. 5. Data is stored in the MySQL database the user sets up on which the Providence tool runs. This means that catalog records exist on your server and would be retrievable if CA failed or you decided to move on to another product. 6. Pawtucket (front-end, web-publishing tool) is extremely visual. 7. Users can register/login. This is important to me since I'll need to create the ability for surveyors to electronically submit their survey results to us in the future. 8. CA support staff/developers are extremely helpful! I've worked with two of them (Seth and Jonathan) and both responded to my requests in a timely manner and made themselves available on a regular basis. On top of all of that, the forum is a productive environment for troubleshooting and problem solving. Once I've presented the website to my colleagues in Historic Preservation, I might be able to tell you a little about the cons from their perspective if there are any. |
About Morgan-I graduated in May 2014 with my Masters of Science in Library Science from UNC-Chapel Hill's School of Information and Library Science. I currently work for the South Carolina State Historic Preservation Office. I've been with them since June of 2014. Archives
June 2017
Categories
All
|