Grundlagen SharePoint-Anpassung (Branding & Design): Vor- und Nachteile individueller Designs - und was sich mit Modern UI ändert (Teil 1)
Dank der neuen Modern UI von SharePoint sehen heutige Webseites schon im Auslieferungszustand gut aus, und Microsoft arbeitet kontinuierlich an deren Verbesserung. Integrierte Mobilseiten, einfache Editierfunktionen sowie die Einführung in SharePoint Server 2019 tun ihr übriges, um deren Akzeptanz zu steigern. Allerdings ist die Modern UI im Vergleich zur klassischen Oberfläche stark beschränkt bei den Anpassungsmöglichkeiten. Wer bisher gewohnt war, das Design von SharePoint-Sites komplett nach individuellen Bedürfnissen zu ändern, wird mit Modern UI schnell an Grenzen stoßen.
Diese dreiteilige Artikelserie erklärt die Hintergründe von „SharePoint Branding“ und die Möglichkeiten und Grenzen von modernen SharePoint-Seiten. Sie zeigt zudem Alternativen auf für diejenigen, die sich mit den Beschränkungen nicht zufrieden geben wollen oder können.
SharePoint-Branding – die Entstehungsgeschichte
Die Serie im Überblick
- Grundlagen SharePoint-Anpassung/Branding – Teil 1
- Grundlagen SharePoint-Anpassung/Branding – Teil 2
- Grundlagen SharePoint-Anpassung/Branding – Teil 3
Die Grundlagen für Branding und Design von SharePoint-Sites wurden mit SharePoint 2007 geschaffen, als Microsoft den Content Management Server (MCMS) in SharePoint integrierte. Der MCMS basierte auf dem Web-Content-Management-System (WCM) NCompass Resolution, wodurch man Designern eine vollständige Kontrolle über das Seitenrendering eröffnete. Die neuen SharePoint-Publishing-Sites erhielten weitgehend alle MCMS-Funktionen, darunter auch die Möglichkeit, mit einem Design-Composite (Bild) zu starten und daraus eine bearbeitbare Seite zu erstellen, die identisch aussieht. Man muss allerdings auch dazusagen, dass die damaligen Out-of-the-Box-Websites nackt wirkten, und somit die Notwendigkeit von Anpassungen offensichtlich war.
Kurzes Intermezzo: Microsoft pusht SharePoint als WCM
Microsoft hat in der Folge damit begonnen, SharePoint als universelles WCM-System für den Aufbau öffentlicher wie privater Websites zu bewerben. In der Phase von SharePoint 2010 gab es dadurch eine Vielzahl an Webauftritten namhafter Firmen, die auf der Basis von SharePoint völlig individuell gestaltet wurden – siehe dazu auch unseren Artikel von 2011. Viele Beispiele dafür findet man heute noch auf dem Portal Top SharePoint-Websites. Allerdings sind die meistens Sites inzwischen veraltet oder so nicht mehr existent.
Trotz der Marketingbestrebungen kam SharePoint im WCM-Markt nie über ein Nischendasein hinaus. Dafür avancierte er zum Marktführer im Bereich Intranet-Sites. Dank seiner großen Flexibilität kam es in Mode, mit Designern und Entwicklern jede denkbare Website von Grund auf neu zu erstellen. Das ganze im Intranet kombiniert mit den Kernfunktionen Dokumentenmanagement, Suche, Sicherheit und weiteren nützlichen Funktionen für Unternehmensanwendungen. Auf dieser Basis entstanden viele aufsehenerregende und beeindruckende SharePoint-Lösungen.
Die typischen Kompatibilitäts-Probleme beim Update
Spätestens beim Update auf eine neue SharePoint-Version jedoch gab es immer wieder böse Überraschungen. Aufgrund der manchmal großen Veränderung der Server-Basis wurde entweder eine Menge Nacharbeit nötig, oder aber die Lösung musste komplett neu geschrieben werden. Viele Unternehmen sind dazu übergegangen, mehrere SharePoint-Versionen zu verwalten, statt die Kosten für die Aktualisierung ihrer stark angepassten Websites auf sich zu nehmen.
Als Hauptgründe für diese Inkompatibilitäten lassen sich folgende drei architektonische Probleme identifizieren:
- Master-Pages und Seitenlayouts: SharePoint und die entsprechenden Anpassungen teilen sich bestimmte Schlüsseldateien wie Master-Pages und Seitenlayouts, in denen individueller und bestehender Code vermischt sind. Aus diesem Grund lassen sich die originalen SharePoint-Teile nicht einfach separat aktualisieren, ohne dass dabei die enthaltenen Anpassungen verändert oder deaktiviert werden. Diese Problematik besteht bis heute bei den klassischen SharePoint-Online-Websites, und sie wird durch die fortlaufenden Upgrades von Office 365 sogar verstärkt, wie sie für Cloud-Dienste üblich sind.
- Server-seitiger Code: Viele der Anpassungsmethoden erforderten die Installation von Code direkt auf SharePoint-Servern. In einer Multi-Mandanten-Umgebung wie SharePoint Online ist das allerdings nicht möglich. Serverseitige Änderungen führen ebenfalls zu Problemen bei der Migration auf eine neue SharePoint-Version. Wenn nicht jede Anpassung perfekt auf den neuen Servern installiert ist, erhält man defekte Funktionen sowie die berüchtigte „correlation ID“.
- Client-seitiger Code: Viele Anpassungsmethoden wie JSLink und Display Templates sind so konzipiert, dass sie Clientseitig in den SharePoint-Sites ausgeführt werden. Daher eignen sie sich nicht gut für den Einsatz von Quellcodeverwaltung oder Tests außerhalb der Produktion. Das Gleiche gilt für Tools wie den SharePoint Designer.
[Die Fortsetzung mit dem 2. Teil folgt in Kürze]
(Dieser Artikel ist eine Zusammenfassung dieses englischen Originalbeitrags Branding SharePoint: The New Normal von Microsoft)
- Die Top-10-Limitierungen von Microsoft Teams: Beschränkte Kanäle, fehlende Apps und versteckte Gruppen - 1. Juni 2023
- Swoop-Studie 2023: "Teams wird kaum für die Zusammenarbeit genutzt, E-Mail bleibt dominierende Office-Anwendung" - 30. Mai 2023
- Microsoft peppt die Teams-Suche mit neuen Komfortfunktionen auf - 16. Mai 2023