Waarom deze blogpost?

Zo nu en dan kom ik een SharePoint omgeving tegen waarin er op een “verkeerde” manier een structuur voor content types is opgezet. De “fout” die gemaakt wordt is dat het type content wordt opgeslagen in een metadata kolom, hoewel dit op het eerste oog wellicht een goed idee lijkt, zorgt het ervoor dat je in de toekomst beperkt bent in de mogelijkheden.

Aan de hand van voorbeelden zal ik in deze blogpost uitleggen wat (m.i.) altijd aanpak zou moeten zijn.

Een kleine introductie

Content Types (Inhoudstypen) zijn entiteiten in SharePoint die ons de mogelijkheid bieden om bepaalde typen content te classificeren. Content types kunnen gebruikt worden voor page layouts, lijst items en document typen. Een content type bestaat uit metadata velden, kan een (document) sjabloon bevatten, een workflow en policies. In deze blogpost richten we ons op het gebruik van de metadata velden. Deze velden gebruiken we om content te classificeren en van extra informatie te voorzien. Op basis van deze informatie kunnen we content terugvinden en weergeven.

Voordat we de mogelijkheid tot het gebruik van metadata (en SharePoint) hadden probeerden eindgebruikers deze meta informatie te verwerken in folder structuren en bestandsnamen. Laten we als voorbeeld een Word document met notulen van een meeting binnen de afdeling consultancy nemen.

In de folder oplossing zou dit er als volgt uit kunnen zien:

Portiva\Consultancy\Meetings\notulen meeting 20160203.doc

Waar gaat het fout?

In de voorbeelden die ik ben tegengekomen werd de volgende vertaling naar Content Types gemaakt:

Content Type: Portiva document

Name notulen meeting 20160203.doc
Title notulen meeting 20160203
Department Consultancy
Document Type Notulen

Twee andere documenten in dezelfde omgeving betreffen een brochure over de digitale werkplek propositie en een CV van een potentiele kandidaat.

Content Type: Portiva document

Name Brochure DWP Office365.pdf
Title Digitale Werkplek Office365
Department Marketing
Document Type Brochure

Content Type: Portiva document

Name CV Aad van der Naad.pdf
Title CV Aad van der Naad
Department Recruitment
Document Type CV

Wat we zien is dat we een content type hebben dat Portiva document heet. Dit content type heeft vier metadata velden:

  • Name
  • Title
  • Department
  • Document Type

Op basis van department en document type worden document gegroepeerd en gefilterd. Alles goed en wel en een half jaar lang worden documenten op deze manier geclassificeerd en iedereen is blij met de oplossing, maar nu doet het volgende zich voor:

  • Vanuit de afdeling Recruitment komt het verzoek om bij CV’s ook vast te leggen wie de interviewer is
  • Vanuit de afdeling Marketing komt het verzoek om bij brochures ook vast te leggen om welke campagne het gaat.

Nu kunnen we deze metadata gaan toevoegen door het content type uit te breiden, maar dan ontstaat de volgende situatie:

Content Type: Portiva document

Name
Title
Department
Document Type
Interviewer
Campaign

Als we daarna de metadata gaan opvoeren zien we al vrij snel dat we overbodige velden te zien krijgen…

Content Type: Portiva document

Name Brochure DWP Office365.pdf
Title Digitale Werkplek Office365
Department Marketing
Document Type Brochure
Interviewer
Campaign A B Cloud

Content Type: Portiva document

Name CV Aad van der Naad.pdf
Title CV Aad van der Naad
Department Recruitment
Document Type CV
Interviewer Maarten Eekels
Campaign

De situatie is ontstaan dat de eindgebruiker wordt geconfronteerd met compleet irrelevante metadata velden, immers het veld interviewer is voor een Brochure niet van belang en het veld Campaign voegt bij een CV ook niet veel toe. Dat moeten we dus niet willen!

 Hoe dan wel?

Een content type zou moeten gaan over het type content (de naam zegt het eigenlijk al). Dus in plaats van een algemeen content type als Portiva document, Afdelingsdocument of Projectdocument moet een content type altijd specifiek zijn.

In bovenstaand voorbeeld zouden we dan ook drie content types moeten aanmaken:

  • Notulen
  • Brochure
  • CV

SharePoint voorziet in een hiërarchisch model voor content types. Als blijkt dat deze drie typen content gedeelde metadata velden hebben dan kan er gebruik worden gemaakt van een zogenaamd “parent” content type. Door de benodigde content types af te leiden van deze parent hoeven de gedeelde velden slechts 1 keer te worden ingevoerd en te worden onderhouden. Dit parent content type dient echter niet gebruikt te worden in de document bibliotheken en lijsten!

Dus:

(Parent) Content Type: Portiva Base Document

Name
Title
Department

(Child) Content Type: Notulen

Name
Title
Department
Meeting Date

(Child) Content Type: Brochure

Name
Title
Department
Campaign

(Child) Content Type: CV

Name
Title
Department
Interviewer

Wat opvalt is dat het metadata veld Document Type is komen te vervallen en dat dit het Content Type zelf is geworden. Op deze manier ben je flexibel naar de toekomst toe en classificeer je documenten op de juiste wijze.

Tot slot…

Er zijn scenario’s denkbaar waarbij een organisatie over heel veel soorten content types beschikt en deze allemaal beschikbaar wil stellen binnen 1 bibliotheek. Op het moment dat het er zoveel zijn dat deze niet meer op een normale manier via de gebruikers interface kunnen worden aangeboden is de keuze voor 1 generiek content type met een Document Type metadata veld wellicht toch de beste oplossing. Dit moet dan echter wel een hele bewuste keuze zijn waarbij het duidelijk moet zijn dat de mogelijkheden tot uitbreiding naar de toekomst toe beperkt zullen zijn.

Neem contact op

Coltbaan 4E
3439 NG Nieuwegein

+31 (0)85 - 489 1008

Meer informatie?

%d bloggers like this: