There’s been a lot of talk about “Breaking up with ContentDM” but for a library with limited tech staff to develop our own digital library platform, calling it quits isn’t in the cards…no matter how abusive ContentDM is to us.
Abusive? Well, let’s list it here to be on record:
- As of this writing core functionalities like the image viewer and search do not work in IE10 due to Compatibility Mode (but then again IE10 users are just asking for it…time to move on folks!)
- phrase search doesn’t work well
- stop words are not stopped which is especially bad since phrase searching doesn’t fix this
- commonly used JQuery UI features cannot be used in custom pages without conflicting with the Advanced Search drop down
- Worst of all, once you upload a JS or CSS file, it’s in there for good…no deletions are possible!
- Objects that are composed of an image layer and an OCR text layer do not display correctly in Firefox (but that’s probably more on Mozilla than OCLC)
So, I knew it was time to draw a line in the bedroom when our attempts at customizing the user experience within the ContentDM web configuration toolset went terribly wrong.
Our JQuery almost always caused conflicts, our attempts at responsive design went horribly wrong within the very unresponsive framework of ContentDM and the way ContentDM is structured (with separate CSS/JS uploads for each customized collection) spelled long-term disaster for managing change.
Then came the latest release update when even more went wrong (largely in IE10).
In the end, I couldn’t take it anymore and called up OCLC and begged them to reset the whole site to default configurations, so we could at least start fresh without concerns that legacy JS and CSS were going to cause problems (as I believe they were). They were very helpful and in a matter of 2 hours, had our collections all reset.
We’re doing it differently now as we roll out phased customizations.
Here are our hard-learned best practices:
- Never upload any custom CSS or JS to ContentDM…at least until OCLC creates a way to delete these. Instead, where you need such things, simply upload a reference file that points to externally hosted files, which you can edit/delete as needed
- For the system header, upload your banner image and resist the urge to include any navigation HTML. Instead, use the system menu creation tool. You can use your externally hosted CSS file (reference globally) to style these links (but if you have drop downs you need to given them using this method)
- Use a meta tag redirect to force ContentDM to redirect traffic to your externally hosted home page since ContentDM doesn’t allow you to replace the home page completely with an external page without resorting to this trick. Probably not great for SEO, but avoids the aggravations we endured for so long
- Use the custom page tools for your collection pages that allow you to replace the whole page (including the header and footer) with an externally hosted page. In our case, we are doing this for the really important collections, but others, we manage directly within ContentDM.
- Put any custom interface features into your externally hosted pages and develop to your hearts content
The result: users can now enjoy JQuery-powered interface features and more responsive designs from the home page down to the individual collection pages. If you want to add proven page-turning or timeline technologies in your collection pages, you can now do so without worry. The users only deal with ContentDM once they enter search result or image viewer pages.
To help with the browser issues, we will be deploying browser checks that will deliver messages to users coming to our site with IE or Firefox, hoping to head off bad user experiences with one-time, cookie-based messages. In other words, the first time you come to our site with one of these known problem browsers (for ContentDM), you’ll be urged to use Safari or Chrome.
Conceivably, you could use a CMS like WordPress or Drupal to manage your custom pages and start adding timeline, mapping and other plugins as you like. We’ll probably work toward this in 2014 or 2015.
Speaking of user disruption, the other cool thing about separating most of your digital library GUI from ContentDM, is that you can work in test environments, out of sight, and only update the public pages when you’ve thoroughly tested them. This was impossible when we tried to work in ContentDM itself. And when things went wrong, the users in our DL saw every thing in plain sight.
View the current production version of our Digital Collections.
Yeah, separate beds are just what the doctor ordered. Post any questions in the comments as I’m sure I raced through many of the details…