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:
- IE is required to create pages and carry out many editing tasks within the browser due to certain Active X-based features
- 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.
- 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.