Pilvi-intran rakentajan kuusi teesiä


Pilvi-intran rakentajan kuusi teesiä



Yhä useampi yritys valitsee pilvipalvelut intranetinsa alustaksi. Office 365 ja SharePoint Online tarjoavat ylläpidollisesti omaa palvelinfarmia kevyemmän ratkaisun, joka on riittää paljoon. Se on myös erityisen kätevä paljon liikkuville ja matkustaville, kun intra ei vaadi pääsyä yrityksen omaan verkkoon.

Oman ympäristön hyviin puoliin kuuluu tietenkin laajempi valta, ja mahdollisuus räätälöityihin ratkaisuihin esim. ulkoasun ja erityistoiminnallisuuksien osalta. Pilvi-SharePointkaan ei kuitenkaan ole vallan vailla tuota kaikkea. Ulkoasulle voi tehdä paljon sielläkin, SharePointin sovelluskaupassa alkaa olla jo paljon hyviä appejä, joita hyödyntää, ja SharePoint Designer on myös mahdollisuus.

Pääsääntöisesti se mitä voidaan tehdä SharePoint-ympäristössä pilvessä, voidaan tehdä myös on-premises-ympäristössä. Sama ei kuitenkaan kaikilta osin päde toisinpäin, ja omilla palvelimilla toimivilla on suurempi valinnanvara. Tämän artikkelin vinkkejä voi hyödyntää toki kummassakin ympäristössä.

1. Logo

Logosta on hyvä aloittaa, sillä se on se vähin, millä saadaan intra heti näyttämään vähän kotoisemmalta kuin se perus-SharePoint. Logon vaihtaminen ei ole vaikeaa, eikä siihen tarvita räätälöintiä, omaa masterpagea, puhumattakaan sovelluskehityspaketeista. Logo vaihdetaan sivuston asetuksista. Ja kun sen tekee sivustokokoelman päätason asetuksista, se pääsääntöisesti periytyy läpi koko intran, jollei jossain toisin määritetä.

Logo

2. Oikeat sivustotyypit oikeisiin tarpeisiin

Monesti kuulee sanottavan, että sivustokokoelman luominen kannattaa aloittaa työryhmäsivustosta; siitä saa sitten helposti tehtyä julkaisusivuston jos haluaa. Väitän toisin. Jos tiedät olevasi luomassa informatiivista intraa, aloita julkaisusivustosta. Siihenkin saa tarvittaessa työryhmäominaisuudet käyttöön (valitettavasti esimerkiksi kalenterin luominen jo pelkästään vaatii työryhmäluettelot-ominaisuuden käyttöön), ja sen alisivustoiksi voi luoda niitä työtiloja tarpeen mukaan (kunhan ne on ensin sallittu sivuston asetuksista).

Miksikö väitän näin? Siksi, että työryhmäsivuston muuntaminen julkaisusivustoksi ei ole täydellinen. Julkaisuinfrastruktuuri kyllä ottaa ulos- ja sisäänkuittaukset käyttöön, Sivut-kirjaston jopa, mutta sivuista tulee kummia hybridejä, jotka herkästi jäävät uloskuitatuiksi, kun julkaisutoiminnallisuudet eivät ”hypi silmille” edes senkään vertaa kuin aidolla julkaisusivustolla.

3. Omat sivustomallit

Tästäpä päästäänkin kätevästi omiin sivustomalleihin. Kun halutaan etukäteen määrittää, että jokainen meidän intramme tiimityötila sisältää nämä-ja-nämä luettelot ja etusivulta pitää löytyä ne-ja-ne luettelo-osat, ja vasemman laidan navigoinnin linkkien pitäisi olla niin eikä noin, on kymmensivuisen ohjeistuksen kirjoittamisen sijaan (ohjeistukset kunniaan toki, muutoin!) parempi tehdä ensin yksi sivusto, jossa kaikki on kohdillaan, ja tallentaa se sitten sivuston asetuksista malliksi. Malli tallentuu sivustokokoelman Ratkaisut (Solutions) –kokoelmaan ja on läpi sivustokokoelman käytettävissä sivustoja luotaessa, Mukautettu (Custom) –välilehdellä. Huomaa, että voit sisällyttää sivustomalliin myös kuvia, ohjedokumentteja, mallitapahtumia jne. Mallin luontivaiheessa valitaan, sisällytetäänkö luetteloiden ja kirjastojen sisältö malliin vai ei.

Sivustomalli

Huomaa, että julkaisusivustoa, tai työryhmäsivustoa, jossa on julkaisuominaisuudet käytössä, ei voi tallentaa malliksi!

4. Sisällöntuotannon ja ilmeen pelisäännöt

Tyypillisesti työryhmäsivustoilla sivuston omistajan luovuus saa kukoistaa ja sivusto mukautuu sujuvasti käyttäjiensä tarpeisiin. Tiimin työtila on luultavasti erilainen sisällöltään ja rakenteeltaan ja rakennuspalikoiltaan kuin vaikkapa projektityöryhmän projektinhallintasivusto. Niin on tarkoituksenmukaistakin, aivan kuten on tarkoituksenmukaista valita sivustomalli sivuston tarkoituksen mukaan.

Informatiivisilla julkaisusivuilla ei villi ja vapaa kuitenkaan yleisesti ottaen toimi. Tai voihan se toimia, mutta ei se kaunista ja harmonista ja helposti lähestyttävää kuvaa intrasta anna. Siksi yrityksessä olisi hyvä olla selkeät pelisäännöt siitä, mitä sivupohjia voidaan käyttää intran julkaisusivuilla – toisille yrityksille on tärkeää, että jokainen sivu on rakenteeltaan samanlainen, jossain toisessa yrityksessä voi sivupohjia valita vapaammin – ja saako fontteja, värejä, fonttikokoja jne. muutella. Yleisen miellyttävyyden kannalta on yleensä suotavaa, ettei sivuilla käytettäisi villisti värejä ja eri fontteja, ja että otsikointi hoidettaisiin otsikkotyylein tai muulla sovitulla yhteisellä tavalla (esim. suurempi fonttikoko ja lihavointi).

5. Ulkoasu? CSS-tyylitiedosto riittää pitkälle!

Aina ei tarvitse aloittaa intran ulkoasumuutoksia A:sta. Omilla palvelimilla pyörivään intraan voidaan hyvin asentaa kokonainen ulkoasupaketti, joka sisältää täysin kustomoidut masterpaget, tyylit, sivupohjat, edellisten käyttöönoton automatisoinnin ja mahdollisesti räätälöityjä uutisnostopalikoita ja mitä kaikkea. Pilvi-intraan ei sellaisia asennella. Täysin kustomoidut masterpaget, tyylit ja sivupohjat (mutta ei automatisoituina) voidaan toki toteuttaa pilveenkin, Design Packagena eli suunnittelupakettina, mutta aina ei tarvita omaa tyylitiedostoa kummempaa.

Siinä missä vanhemmat SharePoint-masterpaget oli rakennettu taulukoin (lue: elementtien sijainti on vakio), 2013-versiossa oletuksena rakenne on pääsääntöisesti div-elementtejä. Ihan kaikki kikka-kolmoset eivät ole mahdollisia, eli elementtejä ei aivan voi myllätä pelkin CSS-tyylien keinoin, mutta aika pitkälle pääsee jo silläkin. Tyypillisiä tällaisia tarpeita, joihin riittävät pelkät CSS-keinot on esimerkiksi:

–        Navigointipalkkien ja –linkkien ulkoasu

–        Oletusfontti, tekstikoko, otsikointityylit, värit

–        Sivun otsikon tai navigointipalkin asemointi

–        Yläpalkkien värit

Tyylitiedoston voi ottaa sivustokokoelmassa käyttöön päätason sivuston asetuksissa, kohdassa Perustyylisivu > Vaihtoehtoinen CSS-Url (Master page > Alternate CSS Url) ja sieltä periyttää kaikille sivustoille. Valitettavasti uudet työryhmäsivustot eivät tätä peri jälkikäteen.

Oma tyylitiedosto

6. SharePoint Designer

SharePoint Designer on vähän mörkö. Se on perinteisesti ollut pahamaineinen sivustojen hajottaja. Se voi olla sitäkin, mutta jos tietää, mitä tekee, se on väline paikallaan. Se on käytettävissä myös SharePoint Online –ympäristössä, joten se on varsin varteenotettava vaihtoehto, kun pitäisi saada tehtyä vähän sellaista, mitä ei selaimessa saa tehtyä.

Ensinnäkin, sillä voi tehdä omia työnkulkuja. Pitäisi lomalistasta saada automaattinen sähköposti henkilöstöosastolle ja esimiehille, hyväksyntä lomalle ja siitä vielä ilmoitus henkilölle itselleen? Designerissa sen voi tehdä. Sivustolle ei koidu haittaa siitä, että sen ottaa Designeriin auki, ja luo sinne työnkulun.

Toiseksi, sillä voi näppärästi luoda sivustosarakkeita ja sisältötyyppejä. Voihan niitä luoda selaimessakin, mutta Designerin käyttöliittymä on paljon jouhevampi, kun lähtee nollasta rakentamaan intran metadatajärjestelmää.

Kolmanneksi, sillä voi tehdä mukautettuja listalomakkeita. Vaikkapa, kun käyttäjälle halutaan tarjota vain osajoukko kaikista luettelon kentistä täytettäväksi.

Neljänneksi, sillä voi paikata aiemmin mainitun vaihtoehtoisen tyylitiedoston periytymisongelman avaamalla malliksi tallennettavan työryhmäsivuston ensin SharePoint Designeriin, linkittämällä sitten oman tyylitiedostonsa sivuston oletusmasterpageen, ja tallentamalla sivuston malliksi vasta tämän toimenpiteen jälkeen.

SharePoint Designerin kanssa tulee aina muistaa, että se on täysin versioriippuvainen. Ja sen kanssa tulee olla varovainen, sillä kyllä sillä myös voi rikkoa paljon, jos ei tiedä mitä tekee. Siksipä meilläkin on tarjolla SharePoint Designer –kursseja, joilla opetetaan mitä ja miten sillä voi sivustojaan muokata.



Sanna on pitkän linjan Microsoft-osaaja ja taustaltaan kouluttaja. Viime vuosina hän on ollut mukana lukuisissa asiakasprojekteissa konsulttina ja kouluttajana osaamisalueinaan SharePoint, Office 365 ja Dynamics 365.