1. The database is linear allowing only one avenue of search, browse, and exploration. This method alienates the possibility of searching for anything other than historic properties (such as historic resource surveys, historic districts, and national register listings).
2. The look and feel of the website is simplistic (and Spartan). Now, on the one hand, simple is good. But too simple is just bare-bones, unappealing, and sad. It doesn't encourage use.
Both of these issues can be solved the same way thankfully. We need to rethink the layout of the website. If we have four different type of materials which users can search, how do we advertise that in a way that is a)effective, b)efficient, and c)engaging?
Now CollectiveAccess can certainly achieve all of these things no problem. The hurdle I need to jump is calling on my CSS/HTML know-how and refining my PHP skills.
Because CollectiveAccess is open source, however, I have access to code from projects that also utilized CollectiveAccess. Enterthe University of Colorado's fossil database! See here: http://coloradodev.whirl-i-gig.com/pawtucket2/
This website has the bones (pun intended) of what I want for the #HPDatabase. First, it has a general home page with portals to three collections of materials (in our case we'll have four). Second, once you mine down into each collection, the search function and browse are sophisticated and easily accessible. There is plenty of explanation along the way. Finally, the layout is more fitting to the normal desktop computer and more visually appealing. While we'll change some of the basics (e.g., color scheme and logos), I like the general appearance. I also like that there are tons of links back to the home pages of the university and the library. This will be essential to our database, so that patrons can easily navigate back to the SHPO and Department of Archives pages.
At this stage in the process, I am going through the code and changing the essentials of Colorado's bones to fit our database.