donderdag 27 maart 2014

SharePoint's responsiveness: wat, hoe en waarom (deel 1)?

In een wereld waarin steeds meer verschillende apparaten (pc's, laptops, tablets, smartphones, smartwatches) door en naast elkaar worden gebruikt is het belangrijk om websites te ontwikkelen die op ieder apparaat goed te gebruiken zijn. Responsive design lijkt hiervoor een goede oplossing. Hiermee kunnen user interfaces worden ontwikkeld die zich automatisch aanpassen aan de mogelijkheden en beperkingen van de gebruikte apparaten.

In de komende blogposts zal ik aandacht besteden aan responsiveness, en met name aan de toepassing van responsive design op SharePoint web sites. Allereerst zal ik ingaan op veelgebruikte terminologie en redenen waarom responsive design van belang is. Daarna op het ontwerpen en implementeren van responsive web sites en tenslotte op de manier waarom SharePoint websites responsive gemaakt kunnen worden.

Van oude wijn en nieuwe zakken?

Laat ik beginnen met te zeggen dat termen als "responsiveness" niet nieuw zijn. Als veel concepten in de ICT worden ze zo eens in de 10 jaar afgestoft en opnieuw gebruikt, maar dan onder een andere naam. Al in 1994 werkte ik aan programmatuur waarin rekening gehouden moest worden met schermgrootten en andere specifieke mogelijkheden van de apparatuur waar onze programmatuur op moest draaien (Windows, Mac, AS400, DOS). Naast grafische user interfaces moest ook rekening gehouden worden met character interfaces waarmee de eindgebruiker op een heel andere wijze de programmatuur bediende. En dat alles moest ondersteund worden met 1 broncode versie, hetgeen garant stond voor een flinke hoeveelheid kb's aan programmatuur.

Er is dus niets nieuws onder de zon als we het hebben over moderne responsiveness... of toch wel?

Terminologie: alles op een rijtje

Laat ik beginnen met wat termen te noemen die ik in het kader van responsiveness vaak voorbij hoor komen:
fixed -, fluid - en elastic design, skinny design, scaleable design, adaptive (web) design en responsive (web) design en hybride design.
In dit kader worden daarbij ook vaak de termen: personalisatie, customer journey, single channel, multi(ple) channel, cross channel en omni channel genoemd.

Genoeg reden voor wat uitleg...

Layout, content en functionaliteit van web pagina's: fixed -, fluid -, elastic -, skinny, scalable -, adaptive en responsive design, hybride design

In een vaste website layout (fixed design) worden alle onderdelen in de web site pagina's weergegeven binnen een gebied met een vaste hoogte en breedte, ongeacht de resolutie van het gebruikte apparaat (device, b.v. smartphone, laptop, tablet) of browser. De layout van de onderdelen in web pagina's blijft dezelfde; een onderdeel dat zich rechtsonder bevindt, blijft voor ieder apparaat of browser en bij elke resolutie rechtsonder.

Een speciale vorm van fixed design is skinny design. Hierbij ook een vaste schermgrootte, maar nu wordt uitgegaan van het apparaat of browser met de kleinste resolutie, bijvoorbeeld een telefoonscherm. Onnodig te zeggen dat dergelijke ontwerpen op schermen met hoge resoluties een hoop onbenutte lege ruimte overlaten.

Bij scalable of fluid designs wordt uitgegaan van percentages; alle onderdelen in de web pagina's nemen hierbij een vast percentage van de hoogte en breedte van het scherm in beslag. Net zoals bij fixed designs blijft de layout van de web pagina's dezelfde voor ieder apparaat of browser en bij elke resolutie.

Een speciale vorm van scalable design is elastic design. Hierbij worden eveneens verhoudingen gebruikt (uitgedrukt in "em"), maar deze verhoudingen zijn gerelateerd aan de standaard fontgrootte die voor het betreffende device of browser is gekozen. En omdat de standaard fontgrootte is afgestemd op wat voor de gebruiker goed leesbaar is, kunnen middels  de "em" de layout van het scherm en schermonderdelen beter worden afgestemd op wat leesbaar is voor de gebruiker. Een "em" staat gelijk aan de grootte (in pixels) van het standaard font. Wanneer het standaard font bijvoorbeeld 12 pixels (px) of points (pt) is, dan is 1 em gedefinieerd als 12 px of 12 pt, en 2 em als 24 px of 24 pt.

Van web pagina's die volgens een adaptive design worden ontwerpen wordt de layout aangepast aan het schermformaat van het gebruikte device en browser. Voor een klein en smal scherm, bijvoorbeeld van een telefoon, kan de layout bijvoorbeeld zo veranderd worden dat de schermonderdelen onder elkaar in een kolom worden weergegeven. Deze designs kunnen zowel fixed als fluid/scalable zijn. In adaptive design wordt uitgegaan van een aantal vaste schermresolutie bandbreedten (b.v. 320px -480px, 480px - 620px) in tegenstelling tot fluid design, waarbij in principe iedere schermresolutie wordt ondersteund.

Van web pagina's die volgens responsive design principes worden ontwerpen wordt, net als in scalable design uitgegaan van percentages. Daarbij wordt, net als in adaptive design, de layout aangepast aan het schermformaat van het gebruikte device en browser. Dit gebeurt echter niet op basis van vaste schermresolutie bandbreedten, maar de user interface past zich aan aan elke mogelijke schermresolutie. Daarnaast kan in responsive design ook de content, functionaliteit en layout van de web onderdelen op de web pagina's worden afgestemd op de mogelijkheden van de gebruikte devices (desktop, smartphone, tablet, smart TV, et cetera) en browsers. Als voorbeeld van het laatste kan een telefoonnummer in een web pagina die wordt weergegeven in een mobiele telefoon worden weergegeven als een grote knop waarmee de gebruiker meteen het betreffende nummer kan bellen.

Bij een hybride (mixed) design wordt voor verschillende resolutie bandbreedten een andere aanpak gekozen:
  • Fixed width voor grote en medium schermgrootten;
  • Fluid width voor kleine schermen.
De bovenstaande ontwerp vormen hebben allen een doel, namelijk het optimaal ondersteunen van de gebruiker in alle denkbare scenario's. En hierbij komen de termen personalization, single channel, multi(ple) channel, cross channel en omni channel aan de orde.

Channels

Was vroeger een eenvoudige web site voldoende om klanten van informatie te voorzien, tegenwoordig stellen klanten verregaande eisen aan de dienstverlening die via internet geboden worden. Klanten willen ook steeds meer zelfs kunnen regelen via internet (self service), waarbij ze in sterk toenemende mate gebruik maken van verschillende apparaten met een toenemend aantal functies. Zo kunnen middels een smartphone bijvoorbeeld schademeldingen worden gedaan bij een verzekeringsmaatschappij door foto's te maken van de schade en deze foto's met een speciale app te uploaden in het schademeldingssysteem van de verzekeraar. Dit vereenvoudigt en vergemakkelijkt zowel het melden van de schade voor de klant als de verwerking ervan door de verzekeraar. Daarnaast delen klanten steeds meer informatie (ervaringen) online in onafhankelijke communities als Facebook, Twitter, consumenten en gebruikersfora, et cetera. Integratie van social media is tegenwoordig gemeengoed.

In het bovenstaande scenario worden verschillende kanalen (winkel, laptop, mobile, social media) gebruikt in de relatie tussen klanten en de leverancier. Dit in tegenstelling tot vroeger, toen je als klant alleen de winkel als "kanaal" had om met de leverancier te communiceren. Dit was single channel. In single channel scenario's ziet de klant 1 (verkoop)kanaal. Als het primaire kanaal een winkel of intermediair is, dan wordt de website vaak gebruikt als "brochure" of lead generator.

Channels: multi, cross en omni

Wanneer gebruik wordt gemaakt van meerdere kanalen, wordt gesproken van multi-, cross- of omni channel. In multi(ple) channel scenario's kan de klant kiezen tussen meerdere gescheiden kanalen, en ervaart hij geen consistentie tussen de verschillende kanalen. Er is hierbij nog weinig aandacht voor de customer journey over de kanalen heen. Wanneer de verschillende kanalen eenzelfde look and feel hebben, en de gebruiker een naadloze en consistente merkervaring krijgt over de verschillende kanalen heen, spreken we van cross channel. En wanneer de gebruiker zich niet meer realiseert dat hij met verschillende kanalen te maken heeft, spreken we van omni channel. De klant ervaart hierbij een merk en niet een kanaal dat een merk ondersteunt. De klant krijgt persoonlijke en relevante informatie aangeboden, en kan diensten afnemen, via alle beschikbare kanalen die naadloos op elkaar aansluiten.

Het moge duidelijk zijn dat een goed web design dat alle kanalen optimaal ondersteunt cruciaal is voor het succes van een multi -, cross - en omni channel aanpak. Dat ook de organisatie achter de web sites ook goed moet worden ongericht moge ook duidelijk zijn, maar dat valt buiten de scope van dit artikel. Laten we ons voor dit moment even concentreren op het "responsive" maken van web sites.

Eerst denken, dan doen

De implementatie van een responsive design kost tijd, behoorlijk veel tijd. Het is daarom belangrijk de juiste dingen te doen, in de juiste volgorde. Hierover meer in een volgende blogpost.


maandag 10 februari 2014

Aan de slag met Project Server 2013 en SharePoint 2013

Wie ervaring heeft met MS Project weet dat het lastig is om hiermee samen te werken. Wie Sharepoint kent weet dat alleen takenlijstjes Gantt chart views onvoldoende zijn om een project mee te besturen. Wie beide platformen combineert heeft een krachtige combi voor planning en bijhouden van voortgang, uren/budgetten, et cetera.

Praktisch aan de slag met Project Server 2013 en SharePoint 2013 is gemakkelijk. Download een evaluatieversie of probeer het online via een Virtual Lab.

Meer lezen en doen?

Microsoft Project Server 2013 Evaluation Resources: online lesmateriaal, online demoversie, documentatie, etc.
Project Server 2013 product website

zondag 15 december 2013

Twee issues bij SharePoint 2013 op Windows 8 afgespeeld in een VMWare Player op een server met Hyper-V...

Je zou het maar willen... SharePoint 2013 op Windows 8 afspelen in een VMWare Player op een server met Hyper-V.

Ja, dat kan gebeuren als je een voorbereid VMWare image zonder al te veel moeite wilt gebruiken.

Toch twee issues tegengekomen waarbij, na wat zoeken op internet, ik niet de enige ben die dit is tegengekomen (toch enigszins een geruststelling).

Voorbereiding bestond uit het kopiëren van het image naar mijn server en deze in de (gratis) VMWare Player proberen af te spelen.

Resultaat: fatal error waarin werd verwezen naar een probleem in het geheugen: "No-Execute Memory Protection option enabled on your motherboard". En dat mijn pc maar moest worden herstart. Niet doen, dat helpt niets, het probleem zit 'm in een instelling in je BIOS (de "No-Execute Memory Protection" van de host machine, niet van de virtuele machine). De instelling heette in mijn BIOS overigens anders, namelijk: "X-Bit".

Nieuwe poging: nu klaagt VMWare dat 't niet wil samenwerken met Hyper-V en dat ik de Hyper-V rol maar moet verwijderen van mijn server (kinderachtig hoor!). Nu was ik dat niet van plan, en in zo'n geval ga ik op zoek naar een truuk: het tijdelijk uitzetten van de Hyper-V rol:

// to disable hyper-v
bcdedit /set hypervisorlaunchtype off

En om 'm weer aan te zetten:

// to enable hyper-v
bcdedit /set hypervisorlaunchtype auto

dinsdag 12 november 2013

*Gratis* SharePoint 2013 training for IT pros

SharePoint 2013 training for IT pros...

Een cursus in 14 modules een goede inleiding op SharePoint 2013. Met presentaties en video materiaal.

Module 1: SharePoint 2013 IT pro introduction and overview
Module 2: SharePoint 2013 system requirements
Module 3: SharePoint 2013 architectural changes
Module 4: SharePoint 2013 server farms and site architecture planning
Module 5: Office Web Apps 2013 architecture and deployment
Module 6: SharePoint 2013 service application architecture and individual service applications
Module 7: SharePoint 2013 enterprise search overview
Module 8: SharePoint 2013 social features
Module 9: SharePoint 2013 enterprise content management and web content management considerations
Module 10: SharePoint 2013 customization options and management
Module 11: SharePoint 2013 authentication and authorization overview
Module 12: Overview of SharePoint 2013 business continuity management
Module 13: Upgrading to SharePoint 2013
Module 14: What’s new for IT pros in Project 2013

donderdag 20 juni 2013

5 Zaken die NIET in SharePoint architectuur documentatie thuis horen

Ik mijn werk kom ik regelmatig architectuur documenten tegen; ik maak ze zelf, ik gebruik ze en ik review ze. Hoewel iedere situatie weer anders is, kom ik vaak een aantal zaken tegen waarvan ik vind dat ze niet thuis horen in architectuur documentatie.

In deze blogpost de top 5...

1. Een beschrijving van de werking en het gebruik van SharePoint

Op eenzame hoogte: de "SharePoint handleiding" als onderdeel van de architectuur. Pagina's lange beschrijvingen hoe site collecties en site in elkaar zitten, hoe bibliotheken kunnen worden ingericht en welke "out-of-the-box" rollen bij welke rechten horen. Misschien interessant voor een beginnende SharePoint gebruiker, maar niet voor de doelgroep van de architectuur. Bovendien denk ik dat bij SharePoint architecturen juist niet de "standaard" van belang is te beschrijven, maar de wijzigingen die hierop zijn aangebracht.

2. Details, details, details

Er valt aan SharePoint veel in te stellen. En natuurlijk moet dat allemaal gedocumenteerd worden. Het is alleen de vraag waar dat moet gebeuren. Veel informatie hoort niet thuis in een architectuur document en kan verhuizen naar technische documentatie. Een architectuur document hoort de relevante hoofdlijnen te beschrijven en niet de details.

3. Project afhankelijke informatie

Projecten zijn veranderingen op de korte termijn, een architectuur beschrijft in het algemeen de richtlijnen voor de langere termijn. Voor een project relevante principes en richtlijnen (en afwijkingen hierop) horen thuis in een Project Start Architectuur (PSA). Project overstijgende zaken horen thuis in een referentie -, domain - of enterprise architectuur.

4. Architectuur als schetsboek van een eilandbewoner

Een architectuur is een communicatiemiddel; het geeft regels die in de praktijk gebruikt moeten worden. Daarvoor is 1) begrip en 2) draagvlak nodig. Veel architectuurdocumenten verdwijnen in de spreekwoordelijke lade omdat ze niet worden bijgehouden, daarom verouderen en onbruikbaar worden. Zonde van tijd en geld en uiterst frustrerend voor de architect en voor de CIO. Oorzaak hiervan ligt vaak bij de betrokkenheid van de organisatie bij het opstellen van de architectuur en door het type architect. Organisaties hebben veelal de neiging om "het maken van een architectuur ergens te beleggen" en vervolgens het resultaat af te wachten. Daarnaast zie ik dat architecten vaak de neiging hebben om "het beter te weten", "de hele wereld volgens eigen inzicht te willen modelleren" en dit "in hun eigen taal" te willen doen. Met dat laatste doel ik op de bonte verzameling PowerPoint plaatjes waarmee architectuurdocumenten regelmatig worden opgefleurd.

5. Her-her-her-herhaling


Copy and paste is makkelijk en staat garant voor lijvige documenten. Nadelen zijn: verminderde leesbaarheid en verminderde onderhoudbaarheid (wijzigingen moeten op meerdere plaatsen worden doorgevoerd). Ook hier geldt: "less is more".

Om de bovenstaande valkuilen te vermijden, de volgende tips voor SharePoint architecten:

1. Schrijf een architectuur document met het doel ervan in gedachten. Stem het document hierop af en beperk je daarbij. Aanvullende informatie wordt niet gebruikt en ontmoedigt het lezen en gebruiken ervan. Beperk je tot het niveau (waarom, wat, hoe en waarmee) en tot de aspecten (Business, Informatie, Informatie systemen, Infrastructuur, Security, Governance, et cetera) die echt relevant zijn.

2. Voortbouwend op het vorige punt: baken de scope van de te beschrijven architectuur duidelijk af. Bepaal hiervoor vantevoren duidelijk hoe het architectuur landschap wordt ingedeeld en welke delen in het de betreffende architectuur document worden beschreven. Geef ook expliciet aan welke delen buiten scope vallen.

3. Schrijf je architectuur document met de gebruikstermijn in gedachten. Legt een architectuur document richtlijnen vast voor de gehele organisatie (zoals een enterprise -, referentie of domain architectuur), dan mag dit slechts zeer beperkt aan verandering onderhevig zijn.

4. Kom van je eiland af en betrek de doelgroep!
Gebruik architectuur als een echt communicatiemiddel; stem het al op de doelgroep, gebruik raamwerken, talen en technieken (b.v. Archimate, IAF) die open en vrij verkrijgbaar zijn en betrek de doelgroep actief vanaf het begin. Zodoende kan voldoende getest worden of de doelgroep de architectuur nog begrijpt (b.v. door regelmatige reviews, inspraak sessies en informele gesprekken) en of de architectuur nog "gedragen" wordt.

vrijdag 14 juni 2013

Maatwerk, configuratie en out of the box: waarom en hoe onderscheid maken?

Ik hoor de discussie overal; waar ik ook kom, altijd wordt dezelfde discussie gevoerd: wat is precies maatwerk? En hierbij wordt maatwerk ook altijd angstvallig vermeden.

Tijd om eens wat dieper in te gaan op dit vraagstuk, om duidelijkheid te scheppen en handvatten te geven hoe hiermee om te gaan.

Waarom onderscheid tussen out of the box en maatwerk?
Maatwerk wordt in het algemeen geassocieerd met dure software ontwikkeling in een programmeertaal als C#, lange trajecten, duur in onderhoud en lastig overdraagbaar. Out of the box, daarentegen, wordt geassocieerd met goedkope en snelle ontwikkeling.

Het laatste is voor klanten (management, business) natuurlijk veel aantrekkelijker dan maatwerk, terwijl voor de gebruiker (business) en voor de programmeur (techniek) maatwerk interessanter is.

Voorkeur wordt voor een belangrijk deel gekleurd door emoties (ja, zelfs bij technici) en de gevolgen daarvan kunnen voor een project of programma het verschil betekenen tussen succes of falen.

Voorbeelden hiervan te over, bijvoorbeeld op aanbestedingsgebied. Hierin wordt door de klant vaak "out of the box" geëist waaraan in eerste instantie ook door de leverancier wordt voldaan. Gedurende de implementatie blijft dat maatwerk toch de voorkeur geniet (of zelfs noodzakelijk is), waarna zowel de implementatie doorloop tijd als de bijbehorende kosten door het dak gaan.

Resultaat: klant ontevreden en de leverancier en/of de gekozen technologie (of het platform) krijgen de schuld.

Jammer en niet nodig, als vantevoren maar nagedacht was geweest over de verschillende "smaakjes" en de gevolgen daarvan. In het woord "nadenken" zit het woordje "na", maar dat wil niet zeggen dat je pas ergens na moet gaan denken.

Maar waar gaat het eigenlijk mis?

De beloften van platforms en tooling
De laatste jaren bieden (webportal)platforms (dms,ecm, collaboration), veel beter dan vroeger, mogelijkheden om snel tot resultaat te komen door standaard (out of the box) basis functionaliteit te bieden waarmee de eindgebruiker relatief snel aan de slag kan. Ook tooling biedt steeds meer mogelijkheden voor niet software "gurus" om de functionaliteit van platformen aan te passen en uit te breiden.

Allemaal mooie ontwikkelingen, maar ontwikkelingen die hoge verwachtingen kunnen veroorzaken... en zelfs te hoge verwachtingen...

In de praktijk blijkt namelijk het volgende:
1. Out of the box functionaliteit is vaak te generiek om specifieke business processen te ondersteunen.
2. De eindgebruiker (en de business in het algemeen) weten te weinig af van de standaard mogelijkheden van platforms.
3. De eindgebruikers (en de business in het algemeen) zijn onvoldoende bereid zich neer te leggen bij de discrepanties tussen de eigen werkwijze en de werkwijze die het betreffende platform oplegt.
4. Projectmanagers (ICT, business) bieden onvoldoende weerstand aan de eis van de business om het platform te veranderen, hebben te weinig inhoudelijke bagage om te weten waar de grenzen van een platform liggen en geven specialisten te weinig inspraak bij belangrijke beslissingen die hierover worden gemaakt.

Om juiste beslissingen (lees: waar de klant tevreden mee is en waarvoor hij een redelijke prijs/doorlooptijd voor betaalt) is het nodig om zicht te hebben op de volgende zaken:

Wat wordt (in termen van het platform waaraan gesleuteld wordt) verstaan onder maatwerk? Zijn er gradaties hierin? Welke zijn dit, wat bieden ze aan mogelijkheden, beperkingen?

Wat zijn de gevolgen van de keuze voor een bepaalde gradatie? Wat is hiervoor nodig in termen van kosten en doorlooptijd?

Van out-of-the-box tot maatwerk: definities

Laat ik beginnen met een aantal definities die ik al een tijdje gebruik, en kijken of we die kunnen verbeteren (let wel: het gaat hier om SharePoint):

Out-of-the-box (OOTB): the supporting platform supports the recommended solution by default;
Configuration: the configuration of the supporting platform needs to be changed to support the recommended solution;
Limited Customization: adaptations by means of configuration, browser supported or SharePoint related tooling (e.g. Designer, InfoPath , XSLT);
Customization: software components of the supporting platform need to be changed / extended to support the recommended solution;
Extension: new, independent, software components need to be added to the supporting platform to support the recommended solution.


Van out-of-the-box tot maatwerk: definities
De volgende stap is even terug te gaan naar de vraag achter de vraag, namelijk waarom onderscheid gemaakt wordt tussen de verschillende categorieën. Deze vraag komt vaak neer op het willen beoordelen of een bepaalde oplossing te veel "pijn" gaat doen of niet. Ik heb expres de term "pijn" gebruikt, want in iedere situatie is deze pijn weer anders en wordt deze pijn andere gevoeld. "Pijn" kan betekenen dat een bepaalde oplossing duur is om te ontwikkelen, te veel onderhoud kost of lastig te migreren is naar een ander platform en daarom toekomstige pijn in de portemonnee (lees: budgetten) kost. Pijn kan ook betekenen dat de eindgebruikers (de business) onvoldoende worden ondersteund door de betreffende oplossing omdat deze bijvoorbeeld te weinig mogelijkheden biedt of te ver afstaat van de bestaande werkprocessen.

Bij de afweging tussen maatwerk en het gebruik van out-of-the-box functionaliteit moet dus gekeken worden  waar de "pijn" gelegd moet worden.

Projectmanager en opdrachtgever: kijk verder dan jullie neuzen lang zijn
Bovenstaande voorbeelden illustreren dat pijn voorkomt binnen en buiten het project waarin de oplossing ontwikkeld wordt. Een projectmanager is aangeleerd om zijn zaken binnen het project tijdig, binnen budget en kwaliteitseisen te realiseren, hetgeen natuurlijk op zich goed is, maar in de praktijk vaak niet voldoende blijkt te zijn. De "pijn" die binnen het project wordt vermeden kan buiten het project des te harder aankomen. Een goed voorbeeld hiervan is migratie; in migratieprojecten moeten gevolgen van beslissingen in eerder projecten vaak worden gecorrigeerd. Met name ongecontroleerd toestaan van maatwerk komt tijdens een migratietraject een organisatie duur te staan.

Het is daarom een goede zaak om verder te kijken dan het project zelf, bijvoorbeeld naar het overkoepelende programma of zelfs naar het overkoepelende informatieplan of de enterprise roadmap.

Ee doeltreffend denkraam hierbij is de software life cycle. Hierin wordt grofweg weeggegeven in welke levensfasen software zich kan bevinden en vormt daarmee een denkraam vanwaaruit bepaald kan worden welke gevolgen de keuze van maatwerk of out-of-the-box (of een variant hierop) heeft.

Samenvatting en conclusie
Een platform biedt (potentieel) een middel om snel een oplossing te bieden aan de business. Keuzes bij het aanpassen van het platform aan de wensen en eisen van de business dienen vantevoren goed te worden doordacht, waarbij verder gekeken moet worden dan de eerste op te leveren versie.

Vantevoren (samen met experts) nadenken is hierbij een betere investering dan achteraf de gevolgen van slechte beslissingen te moeten corrigeren.









zondag 24 maart 2013

Aanpassen van SharePoint lijst weergaven met JavaScript


Een tijdje geleden heb ik blogposts gemaakt over het aanpassen van de SharePoint user interface middels JavaScript (zie links onderaan deze blog post onder "Verder lezen"). Het ging toen over edit pages van lijst items waarin ik velden manipuleerde door er JavaScripts op los te laten waarmee ik, na het laden van de pagina, veldwaarden, gedragingen en opmaak kon wijzigen.

Onlangs vroeg een klant mij om een soort dashboard te maken waarin bij taken werd vermeld of ze op tijd danwel te laat waren afgerond. Iets dat je gemakkelijk met de juiste tools kunt maken. Helaas had ik ook in dit geval weer niet de beschikking over deze tools (en ook niet de juiste rechten), zodat ik weer moest terugvallen op de "dirty JavaScript tricks" die ik eerder had gebruikt.

Reden om na de opdracht maar weer eens een blog post te schrijven... hieronder het recept van mijn oplossing...

Ingredienten
- Een lege web part pagina.
- Een takenlijst met "due date" (datum/tijd) waarop een taak afgerond moet zijn.
- Een stukje JavaScript waarvan ik de werking hieronder zal toelichten.
- Een Image library met daarin de plaatjes voor de LED's.

Doel
Een lijst met daarin voor iedere taak, waarvan de "due date" datum/tijd kleiner is dan de huidige datum/tijd (today), een indicatie dat de taak niet op tijd is afgerond. In dit geval heb ik gekozen voor een rood LEDje (lampje).

Probleem
In SharePoint is het niet mogelijk om de huidige datum/tijd (Today) te gebruiken in een berekende kolom. Het is dus helaas niet mogelijk om in een berekend veld aan te geven of een taak te laat is afgerond.

Oplossing

Stap 1: Uitbreiden van de takenlijst met een extra kolom met een gemakkelijk te herkennen berekende waarde
Oplossing die ik hiervoor heb gekozen is om een aparte kolom toe te voegen waarin ik de "due date" in een eigen formaat weergeef. Dit formaat heb ik gekozen om er zeker van te zijn dat de datum - en tijd delen (jaar, maand, dag etc.) in een vaste volgorde worden weergegeven. Afhankelijk van instellingen kan het datum formaat namelijk anders zijn dan gewenst. Verder wil ik dat de kolomwaarden van de "due date" gemakkelijk door JavaScript zijn te herkennen zodat ik deze gemakkelijk kan inlezen en gebruiken. Hiervoor heb ik een berekende kolom gemaakt met de volgende formule:

=TEXT(DueDate,"~yyyy~m~d~h~m~s~")

Hierin wordt de DueDate omgezet in een string waarde met daarin het jaar in 4 karakters, de maand in minimaal 1 karakter, et cetera.

Dit resulteert in kolomwaarden zoals: <TD Class="ms-vb2">~2013~3~22~8~30~0~</TD>

In een SharePoint lijst zijn deze velden dus gemakkelijk te herkennen:
<TD Class="ms-vb2">~2013~3~22~8~30~0~</TD>

Stap 2: Aanmaken van een web part pagina met daarin de lijst en een Content Editor Web Part
De lijst moet zichtbaar zijn in een web pagina. Gezien de lijst moet worden aangepast met JavaScript is een Content Editor Web Part nodig waarin we het JavaScript plaatsen waarmee de lijst wordt aangepast. Van belang is dat het Content Editor Web Part onder de lijst wordt geplaatst. Reden hiervoor is dat de DOM nodes in de lijst beschikbaar moeten zijn voor het JavaScript.

Het JavaScript dat ik het Content Editor Web Part wordt geplaatst heeft de volgende functionaliteit:
- GetAllListFields: functie die de speciale lijstvelden opneemt in een array (vIconListFields). Zo kunnen we ze gemakkelijk gebruiken. Leuke extra uitdaging hierbij is dat je hiervoor de getElementsByClassName functie nodig hebt die in IE niet voorhanden is. Daarvoor heb ik een aparte functie gemaakt.
- ConvertFieldsToIcons: functie die de objecten in de vIconListFields array uitleest, bepaalt of de data/tijden daarin eerder of later vallen dan de huidige datum/tijd, en de HTML code in de objecten vervangt door een rood of groen plaatje (LED).

Omdat ik het niet kon laten moest ik de LED's ook laten animeren. Een rode LED wordt geanimeerd zodat het gaat flikkeren. Hiertoe laat ik het plaatje middels een setInterval JavaScript call varieren.

De volledige JavaScript code hieronder, happy coding!

<script language="JavaScript">

// ----------------------------------------
    // Global constants and variables
var vIconListFields = new Array();

// ----------------------------------------
// Functions
    function GetAllListFields(ioIconListFields) {

        // Look for nodes like &lt;TD Class="ms-vb2"&gt;~2013~3~22~8~30~0~&lt;/TD&gt;
 
   vAllMsVb2Nodes = document.getElementsByClassName("ms-vb2");

for (var vIndex = 0; vIndex &lt; vAllMsVb2Nodes.length; ++vIndex ) {

if ( 
   vAllMsVb2Nodes[vIndex].innerText.substring(0,1) == "~" &&
vAllMsVb2Nodes[vIndex].innerText.substring(vAllMsVb2Nodes[vIndex].innerText.length-1, vAllMsVb2Nodes[vIndex].innerText.length) == "~"
) {
   // Add node to Fields array
ioIconListFields[ioIconListFields.length] = vAllMsVb2Nodes[vIndex];
}

}

    }

function ConvertFieldsToIcons(ioIconListFields) {

   var vCurrentDateTime = new Date();
var vTimeDifference;

for (var vIndex = 0; vIndex &lt; ioIconListFields.length; ++vIndex ) {

// Get date in DOM field into Date object to compare with current date/time
var vDateTimeArray = ioIconListFields[vIndex].innerText.split("~");
   var vDateTime = new Date(vDateTimeArray[1], vDateTimeArray[2], vDateTimeArray[3], vDateTimeArray[4], vDateTimeArray[5], vDateTimeArray[6], 0);

vTimeDifference = vDateTime.getTime() - vCurrentDateTime.getTime();

// Change contents off DateTime cell according to TimeDifference
if (vTimeDifference&gt;=0) {
   ioIconListFields[vIndex].innerHTML = "&lt;img src='http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_green.png'/&gt;";
}
else {
  ioIconListFields[vIndex].innerHTML = "&lt;img class='AnimatedLED' src='http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_red.png'/&gt;";
}

// Dispose
delete vDateTime;
}

}

function changeImage()
{

if ( vCurrentImageFileIndex &lt; vImageFiles.length - 1 )
++vCurrentImageFileIndex;
else
vCurrentImageFileIndex = 0;

for ( var i = 0, len = vImageObjects.length; i &lt; len; i++ ) {
vImageObjects[i].src = vImageFiles[vCurrentImageFileIndex];
}

}
   
// ----------------------------------------
   // Helper functions

   // Implement getElementsByClassName because IE does not support this natively

if (!document.getElementsByClassName) {

document.getElementsByClassName = function(classname) {
var elArray = [];
var tmp = document.getElementsByTagName("*");
var regex = new RegExp("(^|\\s)" + classname + "(\\s|$)");
for (var i = 0; i &lt; tmp.length; i++) {

if (regex.test(tmp[i].className)) {
elArray.push(tmp[i]);
}
}

return elArray;
};
}

// ----------------------------------------
// Main procedure

    GetAllListFields(vIconListFields);
ConvertFieldsToIcons(vIconListFields);

// Initialize animation function

var vImageFiles = new Array();
vImageFiles[0] = "http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_clear.png";
vImageFiles[1] = "http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_red.png";

var vCurrentImageFileIndex = 0;
var vImageObjects = document.getElementsByClassName("AnimatedLED");

setInterval("changeImage()", 500);

</script>

Verder lezen
SharePoint 2010 Content Editor Web part maakt rommel van mijn JavaScriptjes
Aanpassen van lijst- en bibliotheekformulieren in SharePoint 2010, zonder SharePoint Designer of InfoPath
Aanpassen van standaard webpagina's voor nieuwe items en bewerken van items: een generieke aanpak