Not really that I can see. Since I maintain the API, I maintain the API responses and I only return what is necessary for display and interaction. For example, our Service & Location Hours (http://www.library.jhu.edu/hours.html) are all managed in separate Google Calendar calendars. The GCal API response for a week's worth of opening and closing times is around 9k (per calendar). With 10 services/locations, that would be 100k in JSON alone being sent every time the hours page loads. So, the Gcal API response is processed on the server side so that I only send about 600 bytes to the user (per calendar). My API also sits behind varnish so the responses are cached and served up super quick. I <3 varnish. We're not currently in the central CMS. It's just a locally hosted Apache site. But, we have a branch campus (https://www.sais-jhu.edu/library) that is hosted within their centralized (and rather locked-down) Drupal install that makes use of some of the same API components (the list of libguides and databases). And really, your data backend could be anything. It could be a "dark" Wordpress install from which you grab ATOM feeds from for content. We use a mixture of Google Calendar, Google Docs, LibGuides, Wordpress, Twitter, and locally-generated XML. -Sean On 8/14/13 10:37 AM, "Josh Welker" <[log in to unmask]> wrote: > That's an interesting idea. Do you run into performance issues with the > abundance of DOM updates with the javascript? Also, how much control do you > have over the content of library pages on the CMS? > > Josh Welker > > On Aug 14, 2013, at 8:35 AM, Sean Hannan <[log in to unmask]> wrote: > >> You could do something like what I did and run your own data backend and use >> whatever you need to/have to to display content. >> >> Our website is just static HTML, CSS, and Javascript. Everything >> dynamic/data-powered is javascript that is pulling from a centralized API >> (written using grape: http://intridea.github.io/grape/). We can move the >> website to some cloud provider, into a central IT-managed system, or >> elsewhere and it won't break. >> >> I originally presented the concept at code4lib 2011 (slides: >> http://www.slideshare.net/MrDys/lets-get-small-a-microservices-approach-to-l >> ibrary-websites), but it's in production now. >> >> -Sean >> >> On 8/14/13 9:21 AM, "Joshua Welker" <[log in to unmask]> wrote: >> >>> 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:[log in to unmask]] On Behalf Of >>> Jimmy Ghaphery >>> Sent: Tuesday, August 13, 2013 5:49 PM >>> To: [log in to unmask] >>> 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 <[log in to unmask]> >>> wrote: >>> >>>> Hi, >>>> >>>> On Tue, Aug 13, 2013 at 6:53 AM, Wilhelmina Randtke <[log in to unmask] >>>>> 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: [log in to unmask] >>>> 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