Steve Lay is an assessment software expert with a CV that includes working at Cambridge Assessment, University of Cambridge and Questionmark as well as chairing the IMS Question and Test Interoperability (QTI) team for 5 years. He’s worked with Blackboard, Moodle and Sakai as well as SharePoint and in this guest post, shares his perspective on SharePoint.
My first real encounter with SharePoint was about 6 years ago when I was surprised to find that a small project pioneering the use of mobile devices in education had built a collaboration environment based on SharePoint.
So why was I surprised? At the time was I was working in an academic environment where Microsoft was neither popular, nor a particularly good fit for such an heterogeneous technology environment. What set SharePoint apart in those days was its role as a development tool. SharePoint was a natural choice for developers who were already using a Microsoft platform to work on and who wanted to develop a website.
Since my first encounter I’ve spoken to lots of people who have decided to use SharePoint to help them develop a website. Interestingly, the expectation that Microsoft technologies tend to be adopted by the core IT department and pushed out to (sometimes reluctant) departments has not been the norm. The experience of SharePoint seems to be the reverse. Many of the projects I’ve observed have started in smaller departments and have gradually expanded across the organization. Admittedly some central Windows-based infrastructure is important to get going but the fact that a department can run SharePoint and offer services internally without having a protracted conversation with the IT department has definitely helped it gain adoption.
There are frameworks with similar functionality to SharePoint that are based on more open technology stacks, but if you want to develop a self-contained website and are not interested in running on server platforms other than those from Microsoft then SharePoint is the obvious choice.
SharePoint as an LMS
Although the technologies, and even the product visions, are poles apart the way people I meet are adopting SharePoint has a lot in common with the way people are adopting Moodle – a popular open source Learning Management System (LMS). In both cases there is a strong element of “DIY” about the technology choice. Moodle has a well-defined plug-in architecture and plenty of options for customizing the look and feel and for customizing the student experience.
Like SharePoint, Moodle does a lot of work for you so it is a pragmatic choice of platform for people that want to get going quickly and concentrate more on the learning management and less on the ‘system’.
From my point of view, as an LMS, SharePoint’s strength lies in its existing use as a collaboration environment for every day work tasks in many offices. In these cases it makes sense to integrate learning functions into an existing portal environment rather than have them as a bolt-on additional system. This fits nicely with ideas about the 70+20+10 model which is summed up by the recognition “that daily life provides a learning environment for us to enjoy” – nominally denoted by the 70+20 percent. So it makes sense to integrate learning management functions like assessment into the environment you use in daily life to help people get the best from their 70+20, not just their 10!
Integrating with SharePoint
This brings me to the subject of integration. As Integration Products Owner at Questionmark this subject is close to my heart. If SharePoint is going to build on its existing strengths as a portal and become a viable alternative to installing a separate learning management system, integration will be vital.
In my experience, SharePoint has been weaker here. SharePoint integrates fairly well with the rest of Microsoft’s technology stack but even a company the size of Microsoft cannot hope to provide all the specialist tools we need to supporting learning across a wide variety of job roles and disciplines.
The hardest challenge that I have encountered is the difficulty of integrating identity and authentication between SharePoint and external systems. Developers often resort to hard-coding credentials into Web Part code but this makes it hard to share their Web Parts with other SharePoint users, except those that are comfortable compiling and packaging their own Web Parts from source.
Even when authentication is achieved using Microsoft’s own “Windows Authentication” there can be significant compromises such as the need to cache credentials within SharePoint, or even within the documents shared there.
These techniques are not significantly different from those adopted by many of the earlier web service clients, including most of the original twitter apps: in this model a third party requests your credentials and proxies your request to the original service provider in order to enhance their offering. This is clearly inadequate when the stakes are a bit higher and the industry has responded with negotiated connections between identities based on variations of the de facto web standard OAuth. In this model you authenticate separately to each service during the negotiation phase ensuring that your credentials are never exposed to the wrong party. The connection can also be unilaterally, and individually revoked at a later date. Twitter themselves have implemented this approach allowing you to tweet from various third party apps and services, including from Google+.
Of course, OAuth is perhaps seen as overkill for most SharePoint integrations as they happen within an organization, obviating the third party risk. But if SharePoint is to break out of the intra-office integration and provide a platform for integrating externally hosted tools, this will need to be improved. Fortunately there are recipes emerging that help developers use OAuth with SharePoint. This article on a SharePoint to LinkedIn Connector provides a recipe using the excellent open source dotNetOpenAuth library.
This project seems to demonstrate an unusual fusion between the open source development community and Microsoft. However, not only have Microsoft already adopted the open source JQuery but they even support the Codeplex open source hosting service. A quick look through Codeplex clearly demonstrates that the SharePoint development community is very active and is perhaps the most recognizable part of Microsoft’s customer base to traditional developers of specialist learning tools.