Office 365

Publieke website in Office 365: wat handige tips

22 oktober 2014

Office 365 is booming! Microsoft heeft met Office 365 een geweldig platform, de one-stop-shop voor jou als persoon en als organisatie. De verkoop cijfers liegen er niet om. Als organisatie kan je er gewoon niet meer om heen. Office 365 is volwassen. En Office 365 wordt alleen maar beter.

Microsoft heeft sinds de SharePoint 2007 versie, content management een prominente rol gegeven binnen het SharePoint platform. Als vervanger van MCMS, zou SharePoint het platform zijn voor het beheren van content pagina’s zowel intern als op publieke websites. Echter, al snel bleek dat dit makkelijker gezegd dan gedaan was; SharePoint blinkt niet uit in het uitspugen van nette, compliant en vooral begrijpelijke HTML. Laten we het netjes houden: ze maken er een zooitje van!

In SharePoint 2007 en SharePoint 2010 moesten daarom tenenkrommende fratsen uitgehaald worden om een publieke site enigszins netjes te krijgen. Zeker een aantal jaar geleden was ik een klant zeer dankbaar als een site niet XHTML compliant hoefde te zijn, laat staan te moeten voldoen aan web richtlijnen van de overheid.

SharePoint 2013 daarentegen biedt weer wat meer mogelijkheden, maar desondanks, de (negatieve) reputatie van Microsoft onder front-end developers wordt consistent in stand gehouden. Maar toch, achter die ene knop in het Office 365 beheerders dashboard, tussen al die overweldigende functionaliteiten, daar is de optie. De ‘Openbare Website’ optie.

De vraag naar Office 365 is enorm, en daarmee ook de wens een publieke website te hosten in Office 365. En terecht: hoe mooi is het dat dit allemaal kan binnen hetzelfde platform! En omdat ik wel van een uitdaging hou, ben ook ik inmiddels live met mijn eerste publieke website in Office 365 voor een klant. En omdat ik het leuk vind, deel ik ook graag mijn lessons learned. Stiekem hoop ik dat ze bij Microsoft meelezen en de paar tips die ik heb daadwerkelijk in overweging willen nemen…
Daar gaan we:

Client Side Object Model? Helaas…
Bij de eerste gesprekken en het maken van een offerte heb ik vaak de oplossingsrichting al in mijn hoofd zitten. Zo nu ook bij het maken van een publieke website. In SharePoint 2007 en SharePoint 2010 waren mij de valkuilen en mogelijkheden bekend. En met de voorkennis van beperkingen voor ontwikkelaars van Office 365, had ik een redelijk inzicht de oplossing ook dit keer weer snel voor ogen te hebben: we gaan alles lekker client-side oplossen met het client side object model.

En ja hoor, dat werkt: Inhoud van lijstjes en andere site data zijn eenvoudig met wat scripting uit SharePoint te trekken en te tonen op je site. Tot dat je voor het eerst echt goed gaat testen en de site ook anoniem gaat benaderen…
De REST API van SharePoint werkt niet anoniem. Punt. En aangezien het client side object model daarop leunt…

Gelukkig bestaat er een Codeplex project genaamd SPServices. (http://spservices.codeplex.com/) SPServices is een jQuery library gemaakt om data uit SharePoint te halen via de ‘oude’ web services. Deze web services zijn vreemd genoeg wel anoniem beschikbaar en het ophalen van data uit lijstjes is hiermee dan ook eenvoudig te realiseren.

Tip voor Microsoft: stel (een gedeelte) van de REST API ook anoniem naar buiten open voor het uitlezen van (bepaalde) SharePoint data.

Anoniem lezen? Ja. Bewerken? Nee.
Binnen Office 365 is het niet mogelijk server side code te deployen. Dit is logisch: je zou immers veel impact kunnen uitoefenen op de (gedeelde) tenants waarbij andere last hebben van jou (slecht) geschreven code. Dit betekent echter ook dat het niet mogelijk is om onder zogenaamde ‘elevated privileges’ code uit te voeren, bijvoorbeeld voor het wegschrijven van een contact formulier entry in een SharePoint lijst.

Je moet je sowieso afvragen of dit een handige constructie is, maar het is een veel geziene oplossing voor dit soort scenario’s. Ook begrijp ik dat dit een dilemma is voor Microsoft: hoe gaan we hiermee om? Voor het geval van een contact formulier is inmiddels een App in de Store beschikbaar: http://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/add-a-contact-us-form-app-to-your-website-HA102845395.aspx#_Toc354573189 Maar het blijft een zorgenkindje.

Staging? Nee.
“En hoe gaan we straks live?” was mijn vraag. Suggesties? In het geval van een nieuwe site in Office 365 is het geen probleem: zet alles klaar en zet als laatste de DNS om naar je Office 365 omgeving en je bent live. In mijn geval had de klant een eerdere versie draaien van hun website op deze Office 365 omgeving. In Office 365 is het maar mogelijk om één publieke site aan te maken, zonder sub sites. Een nieuwe site kan uiteraard deels worden klaargezet (masterpages, page layouts, pagina’s in concept), maar de daadwerkelijk switch van de masterpage neemt toch nog wel wat werk met zich mee: pagina’s publiceren, menu aanpassen, oude content offline halen, etc. De enige optie is een big bang implementatie, waarbij de site desgewenst een periode offline gehaald moet worden. Verre van ideaal dus!

Een testomgeving is een ander verhaal. Hiervoor kan eenvoudig een tweede (proef)abonnement afgesloten worden. Maar ideaal is het zeker niet.
Tip voor Microsoft: Waarom krijgt een klant niet gewoon twee publieke sites tot zijn beschikking en komt er geen knop om de DNS in 1x om te schakelen?

PowerShell? Soms.
Als SharePoint ontwikkelaar heb ik al jarenlang een ‘strijd’ met personen die van mening zijn dat SharePoint een blokkendoos is en waarbij je je dus uit de voeten kan met ‘Out Of The Box’ functionaliteit. Ja. En nee dus. Wat is OOTB? Een design implementatie is niet OOTB. Een custom workflow net zo min. SharePoint is een platform waarop je kan bouwen. En klikken.

Als SharePoint ontwikkelaar heb ik een hekel aan klikken. Klikken is voor consultants om te laten zien dat iets werkt. In een serieus ontwikkel traject kan je niet uit de voeten met klikwerk. Daarom is er PowerShell. Hiermee kan, in combinatie met de applicaties die ontwikkeld worden, een gecontroleerde OTAP gerealiseerd worden. Waarbij vanaf een ontwikkelomgeving al een zo realistisch mogelijk situatie wordt gesimuleerd. Die identiek naar T, A en uiteindelijk P kan worden uitgerold.

Ook Office 365 ondersteunt (remote) PowerShell. Een zucht van verlichting voor de SharePoint ontwikkelaar! Echter, als je het juiste abonnement hebt.

Tip voor Microsoft: Doe niet zo flauw en geef de gemiddelde MKB’er ook PowerShell!

Willekeurige HTML editor gebruiken? Ja, maar.
Ja, je kan met Dreamweaver aan de slag voor je design (masterpages, page layouts). Ja je kan een HTML bestand uploaden en converteren naar een masterpage en een page layout. Super leuk. Ervaring leert dat je uiteindelijk toch SharePoint Designer opent. Alleen al om te doorgronden wat er nu precies gebeurt met je aan een aspx gekoppelde html file. En het feit dat er naast masterpages, ook page layouts in je masterpage library staan. En CSS files, en afbeeldingen, en themes.

Tip voor Microsoft: maak onderscheid in waar wat staat in welke hidden libraries. En hou het schoon: het blijkt onmogelijk te zijn andere masterpages (lees: zooi) te verwijderen.

Search? Ja, maar.
Er is een zoekresultaten pagina met daarop een web part. En een link in de Site instellingen op een nieuwe crawl te doen. Veel meer dan dat ook niet.
Let er ook op dat de searchresults.aspx pagina een vreemde eend in de bijt is. Je kan de pagina niet bewerken (of toch wel via een omweg). Maar je kan hem wel downloaden en uploaden. Je kan wel een page layout koppelen, maar dat doet niets. En je krijgt een hoop javascript in de source cadeau.

Ook zijn er voorbeelden van omgevingen waarin de search index niet up-to-date is. Search werkt, maar steek het niet te zwaar in.

Tip voor Microsoft: Maak het zoekding gewoon inzichtelijk. Een search results web part is prima, maar geef iets meer controle op een consistente manier.

Online documentatie? Oud.
Het Office 365 concept is simpelweg geweldig! Er wordt met grote regelmaat nieuwe features geïntroduceerd die het leven makkelijker maken. Het platform evolueert hiermee snel en kan eindelijk de markt bijhouden, dit in tegenstelling tot de ‘On Premises’ versie van SharePoint, waarbij de release cycle 3 jaar is. En je dus altijd 3,5 jaar achter loopt. En je gemiddelde klant 5 jaar.

Keerzijde van dit verhaal is dat online documentatie (lees: fora, blog artikelen) in 80% van de gevallen niet meer relevant is. Opties die verdwijnen en toegevoegd worden. Het zoeken naar informatie naar een specifieke SharePoint versie is een eitje. Naar juiste SharePoint Online informatie een drama.

Tip voor Microsoft: Developer documentatie is nogal gebrekkig voor Office 365 publieke web sites. Vooral als je je als ontwikkelaar begeeft op de grenzen van wat mogelijk is en niet. Het zou prettig zijn een duidelijk overzicht te hebben wat wel en niet kan, waar je wel en geen rekening mee hoeft te houden.

Nette HTML? Nee.
SharePoint heeft een eigen wil. Dat wil zeggen dat een SharePoint masterpage een grote hoeveelheid SharePoint specifieke controls bevat. En deze controls spugen ladingen HTML, javascript en verwijzingen naar andere bestanden uit. Voor een interne omgeving wellicht acceptabel. Voor een publieke site niet. Gelukkig is er de mogelijkheid bepaalde controls wel of niet te renderen afhankelijk van wat voor type gebruiker hem bezoekt (anoniem, geauthentiseerd) en in welke modus je zit in de pagina (edit mode, display mode). Hiermee is een gedeelte van deze extra code weg te halen.

Met SharePoint 2013 (on premises) is het tevens mogelijk om server side code te deployen om zo de output van de site te optimaliseren. In Office 365 niet, waarmee je altijd met een stuk ongewilde gerenderde code zit.
De extra code is in het geval van ingelogde gebruikers nodig voor de vele functionaliteit bij het bewerken. In anonieme weergave is dit natuurlijk een ander verhaal.

Tip voor Microsoft: Maak in het renderen van controls een onderscheid tussen anonieme en publieke weergave. Op deze manier zou veel overbodige code vermeden worden met als gevolg een snelle schone pagina en daarmee ook (veel) minder load op de tenants.

Subsites? Nee.
Je kan maar een publieke website aanmaken. En je kan daarin geen subsites maken. Via SharePoint Designer is de optie er wel, maar dit resulteert in ongewenst gedrag; de site wordt aangemaakt maar toch niet. Of weer verwijderd.
Hou hiermee dus rekening bij het ontwerpen van de site en leesbaarheid van verschillende niveaus. Zo ook met het koppelen van masterpages. Door deze beperking is het maar mogelijk om één masterpage per site te gebruiken. Logica met javascript o.i.d. is dus nodig om verschillen te realiseren tussen verschillende ontwerpen binnen je pagina’s.

Tip voor Microsoft: Maar de optie beschikbaar om per page layout aan te geven welke masterpage(s) gekoppeld kan worden.

Bugs? Ja.
Er zijn nog wat bugjes. Zo lijkt (op dit moment) search niet altijd optimaal te indexeren en is er een probleem met het bewerken en inzien van eigenschappen van items in de Pagina’s lijst. Het accepteren is het enige wat je kan doen. Groot voordeel is dat er zeer regelmatig updates worden uitgerold. De kans dat problemen dus snel worden opgelost is dus aanwezig.

Tip voor Microsoft: Geef meer inzicht in de problemen en bugs en de planning wat ermee gedaan gaat worden. Het Message Center is hiervoor een prima plek.

Bezint eer u begint!
Office 365 heeft de optie een publieke website aan te maken. Met een paar klikken ben je voorzien van een voor gedefinieerde theme genaamd ‘Oslo’ of ‘Dublin’ en kan je pagina’s gaan aanmaken. Het lijkt redelijk eenvoudig je eigen design te implementeren in masterpages en page layouts. De publieke site optie in Office 365 leent zich prima om een simpele content web site op te zetten. Javascript is je vriend, waarmee je desgewenst ook nog functionaliteit kan toevoegen. Maar op dit moment is dat het. De optie is leuk, maar nog niet volwassen.

You Might Also Like

Geen reacties

Plaats een reactie