I agree 100% with all points, and i want to keep the library server separate. I just was curious if anyone had any advice otherwise.
Does anyone have experience using a separate library CMS hosted on a campus-IT server? (Also I recently implemented a Wordpress library site and loved it, but at my new job I am leaning towards Drupal. The admin interface for WP is not great when you are using custom content types, and non-techie librarians were getting scared. Also, Drupal 8 is resolving a lot of my complaints about the content creation UI. But yes I will probably miss the ease of theming and plugin creation in WP. ) Josh Welker On Aug 14, 2013, at 8:38 AM, Michael Schofield <[email protected]> wrote: > Our university has Cascade Server and we have a Wordpress Network on in-house > servers we control. Here is a list of good reasons to fly solo [if your > library can support it properly, etc.]: > > 1.) A lot of university websites really suck, and as part of your > institution's CMS you are going to have a lot less freedom to innovate or > implement an immediate design change. Of course, these options might be > already culled depending how strictly you're mandated to adhere to your uni's > style guide. If you have enough freedom for it to matter, you might benefit > from the control. > > 2.) Campus IT often doesn't comprehend the usability needs of a library's > unique and varied patronbase - and if they do, they are concerned more with > registration and any of the other constituents (colleges, departments, admin) > to devote to the library. Your patrons are potential power users and they > will be critical and vocal about access and usability flaws. > > 3.) Moving to an open CMS like [sigh ...] Drupal* or [yay!] Wordpress lets > your library participate in and--if you're able--contribute to the #libtech > community. You may create a module or plugin that may seem particularly > geared toward the library niche, but you will be surprised by the positive > feedback from this excellent community of good-natured peers if you let > others use and improve on it. > > 4.) Contribute is going to make it difficult to aspire to either DRY Content > or community. If your colleagues are going to produce a lot of content for > the web, you will benefit from a CMS - what's more, if it's a CMS your > library controls, then you can more fairly respond to any training or > technical needs that might otherwise pend in your university's significantly > larger queue. > > 5.) If you control your own PHP server, it doesn't just *have* to be a Drupal > / WP silo; you'll be able to plug in or build any assortment of applications > as your library requires. > > All the best, > > Michael Schofield > // Front-End Librarian > // www.ns4lib.com > > * I'm just kidding, but I've chosen my colors! > > -----Original Message----- > From: Code for Libraries [mailto:[email protected]] On Behalf Of > Joshua Welker > Sent: Wednesday, August 14, 2013 9:21 AM > To: [email protected] > Subject: [CODE4LIB] Separate library CMS systems vs Campus-wide CMS systems > (was [CODE4LIB] LibGuides: I don't get it) > > Does anyone have any suggestions as to where the library should or should not > compromise when it comes to using an institutional CMS rather than a custom > library one? We are going through this process right now. Our web pages are > currently all in static HTML and LibGuides. I am wanting to move to Drupal, > and campus IT wants us to move to their Adobe Contribute platform. AFAIK, > Contribute does not allow for any server-side scripting and does not have any > sort of plugin system, and I am very concerned that Contribute would harm the > library's ability to effectively integrate its online resources into a single > web portal (server-side caching, indexes, scheduled tasks, etc). > > I know the answer to this question is "it depends," but I am hoping others > can share the fruits of their experience. > > Thoughts? > > Josh Welker > Information Technology Librarian > James C. Kirkpatrick Library > University of Central Missouri > Warrensburg, MO 64093 > JCKL 2260 > 660.543.8022 > > > -----Original Message----- > From: Code for Libraries [mailto:[email protected]] On Behalf Of Jimmy > Ghaphery > Sent: Tuesday, August 13, 2013 5:49 PM > To: [email protected] > Subject: Re: [CODE4LIB] LibGuides: I don't get it > > I have followed this thread with great interest. In 2011 Erin White and I > researched many of the issues the group has been hitting on, demonstrating > the popularity of LibGuides in ARL libraries, the locus of control outside of > systems' departments, and the state of content policies.[1] > > Our most challenging statement in the article to the library tech community > (which was watered down a bit in the peer review process) was "The popularity > of LibGuides, at its heart a specialized content management system, also > calls into question the vitality and/or adaptability of local content > management system implementations in libraries." > > One of the biggest challenges I see toward creating a non-commercial > alternative is that the library code community is so dispersed in the various > institutions that it makes it difficult to get away from the download tar.gz > model. Are our institutions ready to collaborate across themselves such that > there could be a shared SaaS model (of anything > really) that libraries could subscribe/contribute to? The barriers here > certainly aren't technological, but more along the lines of policy, > governance, etc. > > As for Research Guides in general, I see a very clear divide in the > public/tech communities not only on platform but more philosophical. From the > tech side once it is all boiled down, heck why do you even need a third party > system; catalog the databases with some type of local genres and push out an > api/xml feeds to various disciplines. From the public side there is a long > lineage of individually curated guides that goes to the core of value of > professionally knowing one's community and serving it. > > [1] https://ejournals.bc.edu/ojs/index.php/ital/article/view/1830 > > best, > > Jimmy > > > > On Tue, Aug 13, 2013 at 11:13 AM, Galen Charlton <[email protected]> > wrote: > >> Hi, >> >> On Tue, Aug 13, 2013 at 6:53 AM, Wilhelmina Randtke <[email protected] >>> wrote: >> >>> There's not a lock-in issue with LibGuides, because it's used to >>> host pathfinders. Those are supposed to be periodically revisited. >>> One of >> the >>> big problems is that librarians will start a guide and never finish, >>> or make one then never maintain it. Periodically deleting >>> everything is a good thing for pathfinders and subject guides, and >>> people should do it anyway. No one's talking about tools for >>> digital archives, which have >> lock >>> in issues and are way more expensive. >> >> Lock-in doesn't have to be absolute to be effective, it just has to >> has raise the bar sufficiently high to make users think twice about >> migrating away. >> >> This applies even if the data to be moved is transitory and constantly >> changing. For example, if a library has been diligently updating their >> pathfinders, but wants to switch platforms, if there were no way to >> export them to load into the successor system, the effort of redoing >> them or doing a lot of copy-and-pasting could be prohibitive. >> >> As a general statement -- and I know that this battle has been >> bitterly fought in the ILS space -- I believe that *all* library >> software services, whether based on F/LOSS software or proprietary >> software, should provide a way for the library to obtain a full dump >> of their data, in an accessible format, at no additional charge. >> >> I see that LibGuides advertises the ability to make local backups of >> individual pages and also provides (via a paid add-on module) an XML >> export function. I don't know if SpringShare will also provide free >> one-time exports on request, but I would hope they do. >> >> Of course, even if one has the data in hand, data migrations can still >> take a lot of time, effort, and expertise. >> >> Regards, >> >> Galen >> -- >> Galen Charlton >> Manager of Implementation >> Equinox Software, Inc. / The Open Source Experts >> email: [email protected] >> direct: +1 770-709-5581 >> cell: +1 404-984-4366 >> skype: gmcharlt >> web: http://www.esilibrary.com/ >> Supporting Koha and Evergreen: http://koha-community.org & >> http://evergreen-ils.org > > > > -- > Jimmy Ghaphery > Head, Digital Technologies > VCU Libraries > 804-827-3551
