SharePoint: Get It Right the First Time

It’s just one of those days. You sit in the tram going into work and on your mobile you’re reading just another blog post. In my case I was reading SharePoint: Get It Right the First Time. Suddenly I felt the immediate urge to reply. Not there was anything wrong with the essence of the post. No, everything written I could agree to. But four out of six headlines used by the author triggered a feeling of unease in me:

  1. There is no such thing as out of the box SharePoint
  2. One size does not fit all
  3. If you build it, they will not come (I agree)
  4. It’s never just about SharePoint (I agree)
  5. SharePoint is not an IT thing
  6. SharePoint is not an Office product

The author (Joe Shepley, Twitter: @JOESHEPLEY) already suspected his post might add to the regurgitation (a word that I needed to lookup). I don’t want to disappoint him, so here I go.

1. There is no such thing as out of the box SharePoint

Wrong. SharePoint does come out of a box (or out of downloaded installation file). Even better: To start with, it comes out of a free box called SharePoint 2010 Foundation. Depending on what you want to achieve, SharePoint 2010 Foundation gives a company all it needs to enable its employees to feel more engaged and work more closely together. I worked for (and am consulting at) a company that employs about 430.000 employees worldwide that heavily depends on exactly the functionality that is provided by the “free” version of SharePoint. However, they would never have successfully implemented their collaboration world, if it wasn’t for proper Change Management. Simply replacing the good old shared network drive one day and sending a link to a SharePoint collaboration site wouldn’t have done the job. The introduction of SharePoint can only be successful if it is executed as a Business Change Management Project. I had the opportunity to co-develop a generic change management strategy for introducing SharePoint when migrating from a shared networkdrive and was successful at exactly this. SharePoint out of the box is real. But you need to understand the magic of change management from both the business as well as from the IT perspective.

2. One size does not fit all

Wrong. One size does fit all. However, that size needs to be such that IT can still manage it and proper governance needs to be in place. Without it, you’re lost. Also, this one size should be considered a starting size. It may and will grow over time and then your collaboration world will change and with it its footprint will change. But we all know by now that SharePoint projects will fail if you want to start ahead of the game. Hence I recommend that every company, not matter its size, will start with a very basic SharePoint installation; one that covers 80% of the requirements. Most likely, that’s the one that just popped out of the box (see point 1). The last 20% is the hardest part. That is where companies start thinking about workflows, business intelligence, shops, newsletters or other heavily customized applications. Still in that case I like to take a look at the box. Was it really empty? Or maybe I can buy a second box. By now, there are lots of IT-companies selling top-class SharePoint extensions that probably cover another 80% of the requirements of the 20% that wasn’t covered yet!

5. SharePoint is not an IT thing

I know it’s common to say that SharePoint is not an IT thing. But in the end we all discover that we were wrong. Only proper governance that in the end is executed by IT will assure that wheels are still turning and employees are still engaged. However, in most cases, the IT department isn’t aware of its luck! It is true that SharePoint allows for decentralized management of permissions and structure. But that doesn’t mean IT isn’t any longer responsible. Whenever a hard disk is near capacity, who you are you going to call? Ghostbusters? No, you will call the IT-helpdesk. So IT needs to regroup and understand SharePoint and take its part in defining guidelines for guidelines for collaboration. It needs to stay ahead of the game. In that respect I really enjoyed reading this blog post, as it contains almost all pitfalls in one post.

6. SharePoint is not an Office product

Wrong. SharePoint = Office. SharePoint is where all Office products meet again after they left Redmond. Of course SharePoint is more. But I find it hard to believe that the strategists in Redmond would disagree with me. SharePoint is Microsoft’s product that moves Office into the private cloud, which means that companies that currently use SharePoint are all potential customers that may consider Office 365 and the Business Productivity Online Suite. Since a couple of weeks it’s also possible to synchronize your Office documents with Google Docs using Google Cloud Connect (which actually works quite nice). You could also consider using DropBox for simple document sharing. But the deep Office integration is key to what is SharePoint all about. Without it, SharePoint wouldn’t be as successful as it is today. Collaboration is about many things. But document management for sure is a big part of it. And even thought there are better products on the market for document management than SharePoint, none of them is as deeply integrated as SharePoint. In my humble opinion, this is and should be one the main drivers for businesses to consider SharePoint in the first place.

Don’t forget to visit the SharePoint App Market!

Inside SharePoint



jQuery Cookbook

In Bezug auf jQuery könntet man denken, dass alles schon gesagt ist. Höchstens nocht nicht von allen! Auf jeden Fall noch nicht von mir. Allerdings sollte man bedenken, dass ich kein Profi-Entwickler schlechthin bin. Es ist wahr, dass ich gerne auch mal Software entwickele. Aber mit einem Informatiker, der sein Studium summa cum laude absolviert hat, kann und möchte ich nicht mithalten. Gerade vor diesem Hintergrund könnte es interessant sein, hier kurz meine jQuery-Recherchen in Zusammenhang mit SharePoint aufzuzeichnen: Nicht für den Experten, sondern für die erfahrenen Anfänger!

In letzter Zeit sind immer wieder neue Technologien an die Oberfläche aufgetaucht. Ausdrücke wie Ruby On Rails, Google Web Toolkit aber auch jQuery lassen es bei vielen sicherlich klingeln. Viele dieser neuen Technologien sind allerdings nicht neu-neu, sondern vielmehr handelt es sich um eine weitere Abstraktion einer bestehenden Technologie. So auch im Fall von jQuery. jQuery ist im Grunde eine JavaScript-Erweiterung (eine sogenannte Klassenbibliothek) die vor allem UI-Entwickler unterstützt weil sie:

  1. Komfortable Funktionen zur DOM-Manipulation und DOM-Navigation zur Verfügung stellt. Anders formuliert: Mit jQuery kann ein UI-Entwickler auf einfacher Art und Weise HTML-Elemente selektieren, manipulieren und Leben einhauchen.
  2. Moderne AJAX-Funktionen implementiert und somit ist die asynchrone Kommunikation zwischen Browser und Server und die Verarbeitung der asynchron gesammelten Daten durch DOM-Manipulation Kinderspiel.
  3. Eine Vielvalt von Browsern und Betriebssysteme unterstützt.

Noch mal anders formulier: jQuery ist eine JavaScript-Klassenbibliothek die kleiner als 20Kb ist und Entwicklern fast unendliche Möglichkeiten beim Erstellen dynamischer Web Applikationen bietet.

Die zentrale Frage ist allerdings ob und wenn ja wie ein SharePoint-Entwickler AJAX optimal einsetzen kann und ob jQuery da überhaupt Sinn macht. Diese Frage ist ein Fallgruben: jQuery ist nicht gleich AJAX sondern bietet auch -wie oben bereits erwähnt- eine Reihe Funktionen zur DOM-Manipulation und DOM-Navigation. Diese Funktionen stehen zwar in einem engen Zusammenhang mit einenander, sollten allerdings separat betrachtet werden. Einerseits bietet AJAX dem Entwickler eine Technologie um “unbemerkt” asynchrone HTTP-Anfragen auszuführen um so Anwender-Daten zu verarbeiten ohne dass die HTML-Seite neugeladen wird. Anderseits ist AJAX kein Regelwerk, das vorschreibt wie die HTML-Seite manipuliert werden soll. Anders formuliert, diktiert AJAX nicht wie die Auswirkung der Verarbeitung der Anwender-Daten browserseitig realisiert werden soll.

Welche AJAX-Optionen stehen dem SharePoint-Entwickler eigentlich zur Verfügung?

Option 1: UpdatePanel

Hier soll ich wirklich kurz sein. Die Idee mit dem UpdatePanel ist mir bereits seit Jahren unsympatisch. Das Konzept wobei die Seite bei jeder asynchronen HTTP-Anfrage komplett neu ausgeführt wird um dem erzeugten HTML-Output ein einziges DIV-Element zu entnehmen was dann schliesslich zurück an den Browser gesendet wird ist unglaublich ineffizient und führt früher oder später zu Probleme. Das interessante dieses Ansatzes ist allerdings, dass ein UI-Element wie z.B. ein DIV-Element nicht browserseitig sondern serverseitig aufbereitet wird. Das aufbereitete Element wird dann in der vorliegenden Form zurück an den Browser gesendet und ersetzt das bisherige DIV-Element.

Option 2: ASP.NET AJAX 4.0 / ASP.NET AJAX Control Toolkit

Ein erfahrener SharePoint 2010 Anwender wird nicht entgangen sein, dass in SharePoint 2010 Seiten nicht immer neu geladen werden. Vielmehr scheinen da unbemerkt Daten asynchron zwischen Browser und Server zu fliessen ohne dass die Seite langsam wirkt oder gar nicht mehr reagiert (was im Fall des UpdatePanels noch regelmässig passieren konnte). Die gute Nachricht ist, dass die hier verwendete Technologie auch von Entwicklern eingesetzt werden kann. Mehr Information findet man auf CodePlex: http://ajaxcontroltoolkit.codeplex.com/. In diesem Fall würde man viele UI-Elemente aus dem dem ASP.NET AJAX Control Toolkit verwenden, wie z.B. eine Animation, Accordion oder das DragPanel. Ich möchte hier kein ASP.NET AJAX 4.0 Beispiel zeigen. Dafür verweise ich zum Beispiel mal gerne auf die interessante Serie von Lee Richardson http://www.nearinfinity.com/blogs/lee_richardson/client_side_ajax_applications.html. Mit ASP.NET AJAX 4.0 ist die asynchrone Kommunikation zwischen Browser und Server schlicht, einfach und verständlich abgedeckt. Wichtiger noch, die Technologie bietet eine klasse Unterstützung von ADO.NET und somit bestehen klare Vorteile wenn es geht um die Integration von WCF-Services (und somit wenn es geht um die Anbindung von SharePoint Web Services).

Option 3: ASP.NET AJAX 4.0 / jQuery

Möchte man diesbezüglich nicht die ASP.NET AJAX Control Toolkit verwenden, zum Beispiel weil die jQuery UI Bibliothek mehr Möglichkeiten bietet, kommt man nicht an jQuery vorbei. Mit ASP.NET AJAX 4.0 ist es jetzt möglich nur Datenpakete mit einem (Web-) Dienst auszutauschen, z.B. im JSON- oder XML-Format. Das impliziert, dass diese Daten browserseitig noch verarbeitet werden müssen. Sprich, es braucht noch eine Logik, die HTML-Elemente selektiert, manipuliert und Leben einhaucht. Hier ist jQuery schlicht, einfach und … Na ja, verständlich erst dann, wenn man folgendes Buch gelesen hat …


Weiter lesen …

Vor kurzem wurden auf SharePointMagazine.net zwei spannende Blogposts veröffentlicht, die ebenfalls das Zusammenspiel zwischen SharePoint und jQuery versuchen zu erklären: http://sharepointmagazine.net/articles/a-jquery-primer-for-sharepoint und http://sharepointmagazine.net/articles/a-jquery-primer-for-sharepoint-selectors-attributes-and-traversing-oh-my.