Tag Archives: cms

Responsive Design Now Ordinary

Posted on by

I had a great time at Matthew Reidsma’s talk on Responsive Design last week here in Chicago. But as I explored the concepts on a MAMP install of WordPress, I was startled to see just how ordinary Responsive has become. That’s because the default themes of WordPress are now responsive (and have been since last year’s Twenty Eleven Theme). Talk about “un-sexying” a technology!

It’s actually quite funny (and yet not funny) because I know many people (not in WordPress) who are working really hard to create responsive CSS using media queries from scratch. And this can be quite a job, because you really need to think differently about content, styling, design and even HTML. In fact, the whole enterprise of building a website is turned upside down…assuming you believe (as I do) that the simplest approach to building a responsive site is a Mobile First strategy.

WordPress (and some Drupal themes) just took all the mystery away, I suppose. If you’re fortunate to be able to use WordPress, responsive is just baked into the system and you can instantly see how it will look on different screen sizes by just dragging your browser window in and out.

Once again, this CMS impresses me for its elegance at solving the user experience issues of our day. Hats off to the WP community.

Omeka.net is Looking Good

Posted on by

We used Omeka.net to help partners at another University publish a database of Catholic letters (not published yet, so it’s not ready to share) and I think everyone was quite taken by the ease of using the hosted version of Omeka. Unlike the locally installed version of Omeka, Omeka.net is a freemium web service that requires little to no coding skills and no server to get started.

Essentially, Omeka.net works like a hosted blog platform such as Blogger or WordPress.com. You have limited options in terms of look and feel, but the underlying collection building tools are there.

What I like about Omeka.net:

  1. Free or very cheap. You can put together a free collection if your needs are small. If, as was our situation, you have to import your metadata via spreadsheet or have some other plugins you need (some you have to pay for an account to use), then you’ll have to pay a subscription fee. But the fees are likely quite affordable for your organization.
  2. Easy peasy. Very little if any understanding of web technologies is required. In our situation, we had some problems that required some technical thinking mostly in terms of cleaning up our spreadsheet , converting it to UTF-8 and making it work with Omeka, but this kind of expertise should be easy to find in your institution. Once the platform is set up, non-technical staff can pretty much run it and add to it without issue.
  3. It’s pretty good and just getting started. In the past few months, new themes and plugins have started to come online and I expect that this platform will be very robust in just another year or two.
  4. Your collection will become part of the Omeka.net network of collections, which should help with Search Engine Optimization as well as serendipitous discovery.
  5. It feels pretty rock-solid and reliable.

What I don’t like about it:

  1. It’s still early days and some features from the full Omeka version are not yet available.
  2. Very limited theming, meaning you have only 8 different themes and none of these let you control color. However, you can add banner images and footers to brand it.
  3. The help documentation is fairly helpful for most situations, but if you run into some advanced issues, you’ll have to hope someone on the Omeka forums can help.

Saved by the Cloud

Posted on by

I’ve been playing around with Omeka.net, the hosted version of the digital collections platform Omeka, and have fallen hard for it.

A number of months ago, my university partnered with the National University of Ireland at Galway to find a new home for an annotated catalog of letters and primary documents from the Vatican Archives. It turns out that online access to the collection was in danger due to the financial troubles in Ireland, specifically, that the funding for the server and the IT staff required to support it was going away.

So, my library offered its assistance and I began exploring the options.

The ideal platform would have to have staying power, be relatively cheap and satisfy the feature list as closely as possible from the old website. Also desirable, of course, would be that it would use web standards, be simple to maintain and require no IT support.

Fortunately, this was happening just after the folks at George Mason University had turned their open source Omeka platform into a hosted service. Omeka is a platform designed around familiar web publishing conventions similar to WordPress, so for administrators, it would be quite easy. However, the traditional in-house server-based version would require at least one full-time IT staff member who could configure a LAMP server, install and configure Omeka and then keep it updated and running.

That would be impossible at my university where no server was available (or at least no production servers) to the library and where PHP (which Omeka is based on) is frowned upon.

But, with the hosted version coming online, Omeka.net, we could meet all of our criteria with additional benefits:

  • No server required…just sign up for an account and you’re ready to get started
  • No IT staff required
  • Simple item and collection management through web forms, making it possible for the researchers to continue adding to their collection without further assistance
  • A growing list of plugins, including CSV imports, Dublin Core mapping, etc. to meet most of the feature requirements
  • OAI-PMH interoperability, making it possible for the collection to be harvested by other systems and uses
  • Plus, the collection automatically rolls up into the growing universe of other Omeka.net collections, enhancing SEO and find-ability

The only real shortcomings of the system were its very limited theming and some missing plugins, such as faceted browsing and timeline features. However, it’s clearly early days for this blossoming platform and I expect good things to be added in the near future.

The live version will go online soon after we finalize a few graphics and textual decisions. But the collection is now safe and sound and poised to grow and develop in a stable and promising platform.

Rolling out Campus Guides

Posted on by

We began implementing Campus Guides (LibGuides CMS) this week. Two projects will kick-off this new platform for us:

  1. Building out new informational pages that target specific campus groups (faculty will come first)
  2. Redesigning the “LibGuides” workflow for guide publication by using groups for admin purposes

The informational pages have been a usability disaster for some time, but we had delayed doing anything about this because our current CMS is it’s own kind of disaster. Now that we have Campus Guides, though, we can implement some information architectural changes and interface enhancements (using JQuery) to vastly improve the utility of these kinds of pages.

An admin group that requires admin access to edit content will serve as the content management system for things like navigation boxes, Jquery features and other code-intensive objects that non-technical staff should not be touching. Another group will house the “guides” themselves, where librarians can access templates embedded with the admin group’s content.

We’ll be doing something similar with our traditional libguides content: creating an admin group that contains the “steal this guide” content with things like canned search boxes, book feeds, etc. We’ll also be creating a Test group for these libguides where interesting features can be explored without allowing others to copy such content. Once these tests are approved as public content, we can then simply place that new content into the “steal this guide” group for use across the system.

I’m curious if others out there have tried this approach. On paper it looks great. We shall see…

UnLibGuiding LibGuides

Posted on by
Libraries Website Re-created in LibGuides

Our library website re-created using Campus Guides as a WCMS by overriding the default CSS and creating an administrative group to protect HTML and Javascript code.

When my library launched LibGuides last year, we spent some time tweaking the CSS in order to streamline the LibGuides interface. As any user of this very fine product knows, LibGuides displays a lot of information that is very task-oriented, but in my opinion, can overwhelm the page to where all this info gets in the way of users getting their primary task done: that is, finding library resources pertinent to their research topic.

During this exercise of turning off these features, it became quite obvious that you could override much more than “displaying:none” several print and tagging features. One could, in fact, redesign the entire interface.

Fast forward 1.5 years later and along comes SpringShare’s Campus Guides, which is essentially LibGuides, but with the ability to run multiple instances (Groups) of LibGuides, each with its own unique customizations.

Immediately, I saw an opportunity to create a “Group” of guides that could serve as an experiment without affecting our live LibGuides service. The end result was turning Campus Guides into a true Web Content Management System (WCMS).

To be sure, I was going to override alot of CSS, largely by restyling the look and feel, but also “displaying:none” many parts of the site. But another aim was to continue using the CMS features of LibGuides, so that any group of pages could still be managed stably for the long-term and leverage all the power that makes LibGuides so great to work with.

To accomplish this, I created one Campus Guides Group to serve as the back-end content management area and another for creating the public facing guides. The CMS group was called Library Administration and contained image collateral, rich text boxes with HTML and javascript, JQuery libraries and menu systems that could be used in templates by page managers in the public-facing group.

That public facing group, which I dubbed Spork after our sandbox project, would have the public-facing CSS overrides and all the regular librarian-generated pages that would make up our LibGuides replicant of our website.

Taken together, here’s how these two pieces completed the full Campus Guides WCMS:

  1. When a new page is created, the author would decide which section of the site it would live in. For example, if the page was part of the About section, they would start by making a new guide from the About Template.
  2. This About Template would contain all of the content boxes that every About page should have, including the sub-navigation menu for the About area of the site, which is a box duplicated from a box in the Library Administration Group. This means that the page creator cannot alter the content of that navigation, but also any changes made in Library Administration would cascade down to all pages using that sub-navigation box.
  3. It’s also important to note that the Library Administration group can be password protected so that non-admin librarians cannot inadvertently destroy carefully constructed HTML content that is meant to “UnLibGuide” Libguides.
  4. Once the librarian has created their page from the About Template, they can add any box content they wish in the usual way. Importantly, our custom CSS overrides keep whatever they do to continue looking like the polished website we created in our custom CSS.

Using this strategy, we were able to do many things without fear of creating something that could be undone by non-HTML-savvy staff. We could embed forms, JQuery features and even remote database content into our Spork site. In fact, we were able to replicate just about every feature of our live Library Site within Campus Guides…and make it look like a professionally designed portal.

Parts of the site are still not filled out yet, but to see examples of some of what we’ve done, I’ve included the following links:

The lesson from our experiment is that libraries with technically literate staff could take LibGuides to a rather impressive level. In fact, this whole project came out of our frustration with doing something similar in Drupal. Point being: Campus Guides is far easier at creating basic web sites than Drupal (although admittedly not as powerful a tool…yet!).

I should also point out that this is strictly an experiment. My library is moving to SharePoint next winter.

SharePoint: A Square Peg in a Round World

Posted on by

My university is moving its entire web content management system over to Microsoft SharePoint, and so I thought it would be a good idea to dive into the platform to get ready. My recent experience with a sandbox SharePoint installation on a hosted server has answered some questions, and made me appreciate some of SharePoint’s power, but in many ways, my initial concerns remain.

It almost goes without saying that anything Microsoft is going to be clunky. The once-enigmatic Tech Titan has not aged well. The list of failures is legion: Internet Explorer, XP, Vista, Window Mobile…As a result, many people have gone Mac or Android, Mozilla or Chrome.

It didn’t help that during its heyday, Microsoft’s market strategy focused on forcing the world of round pegs to conform to its square peg model. So the public at large has been fleeing in droves and the once mighty emperor is left naked on the stage as was the case at this year’s CES keynote given by MSFT CEO Steve “I’m going to F**kin’ Kill Google” Ballmer. Ouch.

Sadly, MSFT remains fairly entrenched in business and education, even as the precipitous flight of employees and students to anything not-Microsoft carries on. And so, we’re left with this disconnect between the ecosystem of our users and the ecosystem of IT departments. Long-term, this will get sorted out in a way that is highly unlikely to favor Microsoft, but in the transition period, we all must do what we can to fit those square pegs into their assigned holes.

Such was my primary mission for Project Spork, a multi-pronged CMS exploration that tested different CMS against a selection of requirements from our library’s production site. In this project, we built three prototyope sites in LibGuides, Drupal and SharePoint.

SporkSP (the SharePoint version) started off with a large dose of suspended disbelief as I waded through a product that was originally designed as a document-oriented wiki. It bears noting that the WCMS components in SharePoint were only later added when Microsoft realized that many of its Intranet customers were applying SharePoint to Internet problems. And this really shows when you start trying to create an institutional website with it.

Like Drupal and other CMS systems, if you come from a hand-coding/Dreamweaver background, you’re going to be put off right away. But in SharePoint, it’s much easier than in Drupal to code the old-fashioned way. However, while you can easily jump into codeview in SharePoint Designer, there is never any guarantee that the wiki-oriented SharePoint won’t strip out your code and drive you batty with security warnings.

SharePoint’s real strength, however, is in its database tools. With one click, you can connect SharePoint to an XML file, RSS feed, REST web services or external database (of almost any flavor). You can even easily make SharePoint the database editor for your external SQL database. And once you’ve made the connections to that data, SharePoint seamlessly integrates the database with the rest of your site. On this level, it blows Drupal away.

But lest you forget that you are working in a Microsoft product, let me recall the list of “Microsoft” issues that come up with this tool:

  1. IE is required to create pages and carry out many editing tasks within the browser due to certain Active X-based features
  2. You must install Silverlight for no better reason than the controls in the browser are built with Silverlight. In other words, without Silverlight, you can’t work effectively in a SharePoint site.
  3. And of course, nothing is straightforward:
    • CSS class and ID names are frightfully machine-oriented and even change!
    • If you build a relational database (or something that feels like a relational database) in SharePoint (say in your test environment) you cannot move it without all the lookup fields being broken.
    • The development tools are divided between the IE interface and SharePoint Designer. Meaning you are constantly jumping between them and it is never clear where a given feature will be found. For example, you have to create a database in SharePoint Designer, but then create the lookup fields within IE…say what?

But if I had to pick the worst FAIL of them all, it would be the wonky way SharePoint requires you to integrate external widgets and tools into your SharePoint site. Again, to be fair, SharePoint was designed as a wiki-like tool that focused on internally held documents. So tyring to bring in external web features was not ever built into the initial product. As a consequence, the most straightforward way to do so is through an iFrame…yuck!

For example, bringing in our WorldCat Local Search Box required the iFrame method, because SharePoint strips out the search form when you place the code directly into the page html. Okay, so you use an iFrame. But this method ensures that, one, you will need to host the form html and styling on an external server, and two, that iFrames are always fraught with display issues across browsers and devices.

Later investigation suggests that the more stable way around this, is by developing web parts that can display external content. But that requires that you learn .Net and Visual Studio…just to put a search form on a web page, folks.

For a site whose most important feature (the Library Catalog) needs to be brought in through an iFrame or some other even more heavy-handed method…well, that would normally be a deal breaker for any library comparing its requirements against a CMS.

I’m sure that Campus IT can solve some of these kinds of issues for us. But that brings up my final point: using this platform means that a Library web team will almost always be reliant on Campus IT for things that they would otherwise be able to do with ease. Or, alternatively, be forced to learn to develop for SharePoint. This isn’t necessarily a bad thing, of course, but when you’re trying to keep pace with libraries that use more intuitive platforms (PHP, MySQL, Drupal, WordPress, etc.), well that means you’re likely to play catch up for years.

Library web services are always changing and will undoubtedly change even faster as we speed into the increasingly shifting landscape of e-readers, mobile devices, etc. The whole reason that librarians got into the IT business to start with, was because only they are familiar with their boutique technologies enough to make them all play nicely together.

SharePoint never had the library ecosystem in mind. Indeed, it never had web design in mind. Stil, you can use it to build very beautiful web pages that allow multiple users to edit them. The very nicely done pages that have already been deployed in SharePoint  at my institution testify to how well this product can work in some cases. But as a tool that improves the productivity of library web teams and library system teams, it fails.

Why Drupal is Just Okay

Posted on by

Project Spork continues…I’m reporting on my first impressions with Drupal. Short version: It’s confirmation for why I often steer clear of open source solutions.

First, a few words on my previous web development experience. I’ve designed and run several sites mostly the old-fashioned way: hand-coding with a few leanings on development environments like Dreamweaver to quickly build the more complicated dynamic elements. Throughout most of this work, the closest I’ve ever come to using a CMS was integrating tagged WordPress feeds in a way that allowed site owners to publish and edit content to their public sites via a private blog. Aside from the SEO issues this raised, it was a great solution for my non-technical clients.

Since those days, I’ve used a custom-built CMS which was more of a PDF cataloging system for a research portal at Adobe Systems (the shell of that site had to be managed by hand-coding in Dreamweaver); and I’ve been using Serena Collage at my current job, which is half-way between straight hand-coding and the full-on CMS that is Drupal.

If I had to describe Drupal in one word, it would be “patchy.” If you’ve worked with this platform for more than a day, you’ll probably know what I’m talking about. Drupal is built for very, very simple, collaborative sites that are more akin to blogs or wikis than traditional institutional sites. To get it to provide features that act more like applications, you’ll have to deploy those features  elsewhere and bring them in through iframes, etc.; or start building up the patches.

The Drupal community calls these patches “modules.” The problem is, because Drupal is an open-source product, these modules are not built with one focused direction in mind as might be the case with a CMS built by a company. Some might call this a strength, since it means that there are modules out there for pretty much any CMS problem that needs a solution. But often these modules rely on one-another to function and sometimes they don’t play nicely together, meaning that a web manager might spend more time trying to troubleshoot module disunion than they might otherwise take to build a custom solution in-house the old-fashioned way.

This was the case with Spork’s Drupal instance.

The problem we faced was re-creating our library hours widget, which is essentially a database-driven application that sits on our library homepage and functions much like the opening hours feature on a Yelp page. If the Library is open, a green OPEN message is displayed; if closed, you get the red CLOSED message. This feature works across our various locations, which often have special opening hours that change around holidays and finals. It also allows users to work with a calendar widget to select date ranges in the future or past.

This is where Drupal started to break down on us.

Building the databases in Drupal 7 is quite easy and I had great success building a tagged set of FAQs that could display only on relevant sections of our Drupal site. No doubt, the hour database would be easy to build, but creating the app and site functionality that made this database pop would require dozens (seriously) of inter-related modules. To add all these modules took significant time to upload and install. When it was all said and done, I still did not have the hours application I was hoping for, but worse, I had a dizzying array of modules imported into my site, which just felt like a administrative nightmare waiting to spring forth at the next Drupal update.

Drupal themes also seemed problematic. These also appeared largely dependent on one’s version and any customizations might be lost if one were to upgrade. Moreover, there were a few themes that did not seem to function all that well. Yeah, I understand that this is open source. But this is also my professional reputation being tied up in someone else’s hobby.

But the real problem I have with Drupal (and this may turn out to be with all CMS), is that I really just want to add code to my sites the old-fashioned way when I need to get something done…and done quick and done well. From my experience thus far, Drupal does not make this part easy and I was actually missing LibGuides and even the broken CMS we currently use.

Case in point, my colleague Jim LeFager was trying to add JQuery functionality to a Drupal page. JQuery is supposed to be integrated in Druapl 7, but it turns out that to get any JQuery to work, you have to include one line of php referencing the JQuery library. Okay, not so hard, except that this critical piece is not documented anywhere. We only discovered it when Jim found a blog entry by someone out there who had run into the same issue.

Really? Is that what we can expect?

Sorry, but for all the hype about Drupal, I’m not sold. The new Views module and CCK integration are great additions for building database-driven sites, but a CMS built for web developers, this is not. There has to be a better way.

Project Spork: Putting the LAB back into FAIL!lab

Posted on by

Fresh from the CMS Smackdown at Internet Librarian, a severe case of Sandbox Longing struck me and so I proposed to the Libraries’ Administration that we start mucking around (technical term: experimenting).

Project Spork is a multi-pronged solution for Sandbox Longing, but it also serves a couple other discreet purposes:

  1. Experiment with a variety of CMS like SharePoint, Drupal, WordPress and (yes!) even LibGuides.
  2. Understand the strengths and weaknesses between different CMS
  3. Generate insights that will lead to more fruitful and informed discussions with Campus IT during our CMS migration (slated for next year).
  4. Keep our professional skills up to date with the latest technologies in the library field.

And, oh, there is one more: Delays in migrating from our current CMS have left us vulnerable as our current CMS is Serena Collage, a product that is no longer supported and which routinely fails. Indeed, we’ve had some scary moments where we thought the whole site was breaking down. So, Project Spork will provide one additional solution: getting the Libraries a back-up website that we can switch to in a pinch.

LibGuide as Library Home PageThat part of Spork is done: I’ve built an alternative site within LibGuides that actually works fairly well and even looks nice (that is, it doesn’t suffer from the boxiness that characterizes most LibGuides sites). To pull this off, I had to use a lot of custom CSS, but also some rather unscalable manual hacks such as making the main content box borders and header text match the white background. Alot of that CSS customization included setting various elements on the page to display:none so that the page would look nice and clean.

These pages are currently unpublished, so I’m providing a screenshot in this post. If we ever had to switch over to LibGuides as our main website, I think we could do this quite easily. Sub-menus could easily be built once and then added to appropriate pages as left-column boxes with pre-defined navigation links. My colleague Jim LeFager even got JQuery libraries uploaded into LibGuides which we can draw from for more advanced functionality. In sum, this worked quite well and I could see this as a very viable (though less-than-ideal) solution.

That’s Project Spork thus far. Coming next: Why Drupal is Just Okay.

Measuring the SharePoint Mood at #IL2011

Posted on by

I’m reporting from Internet Librarian in fog-cloaked Monterey, fresh from a SharePoint development talk by Danielle Pollock of the Sandia National Laboratory Library. In fact, SharePoint has come up in a number of unlikely venues at IL2011, surfacing (briefly and with much ridicule) even in the CMS Smackdown held yesterday. Clearly, this platform is emerging in library-land.

At my library, SharePoint was chosen by Campus IT before I came on board in 2010 and word has it that our IT project team is prepared to guide us out of Serena Collage and into SharePoint within a few weeks of my return from California.

Meanwhile, our revised plan within the library is that a parallel beta site will be available for public testing in January in concert with a public beta test of WorldCat Local. We hope to switch over permanently in the Spring Quarter.

It’s all exciting stuff: our library portal is an unusable mess of fractured platforms and siloed collections (as is the case with a lot of libraries) relying on the stability of an unsupported CMS. So we’re very happy to move.

But will SharePoint really fly?

I’ve got lots of doubts. Specifically, I doubt that it will be as easy or as ideal as other CMS choices. In yesterday’s smackdown, in fact, the panelists ranked a variety of major CMS used by libraries and Drupal came out on top, with WordPress a close second. Clearly, these are the preferred options, but unless SharePoint fails outright in our library, we won’t be able to choose a preferred platform.

Most librarians smirk, shriek, or express their heartfelt sympathies, when I mention our move to SharePoint. Often they just don’t believe it’s possible. Others see a long, tortured path ahead of us as we are forced by SharePoint’s limitations to adopt highly unworkable work-arounds. I happen to think this will be the case, in fact.

Enforcing my doubts, last month, a web services librarian at another institution contacted me about my experience thus far with SharePoint. She has recently been tasked with making SharePoint work as her library’s CMS. After doing her research and failing to integrate her many external web services and platforms into SharePoint, she was now beginning to put forward the argument that it could not be done. Her strategy now was to document all of the things she would not be able to do and recommend a move to Drupal or some other technology.

My hope is that her example and the year-long conversation I’ve been having with IT will get us the kind of access in SharePoint that will be required to accomplish what I see as my main focus: to integrate as seamlessly as possible our various platforms, which include the site itself, our catalog, room booking system, chat, libguides, digital commons IR and contentDM.

This was also a common meme at IL2011: integration. This is, without a doubt, a titanic task no matter what CMS you are using. Doing it successfully with a system that was actually designed more as an Intranet collaboration platform rather than as a true CMS will be even more challenging.

And so, as I wrap up here in Monterey, I will certainly have my work cut out for me. Expect more updates as the process begins. And pray for us as we charge ahead.