Tag Archives: drupal

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.