Handig (voor bijvoorbeeld Twitter): verkleinen van een lange URL

Soms is het handig een lange URL te kunnen inkorten. Neem nu als voorbeeld Twitter: een zeer beperkte ruimte voor je berichtje (140 tekens) en dan ook nog eens een lange URL moeten toevoegen? Verklein 'm in de website TinyURL...

Zie http://tinyurl.com/.

Handig: URL encoder

Sommige karakters kun je maar beter niet hebben in een webadres (URL). Deze karakters worden het best vervangen door speciale "woorden". Een handige tool om de te vermijden karakters in een webadres te vervangen kun je vinden in http://blooberry.com/indexdot/html/topics/urlencoding.htm. Vul het webadres in, klik op de knop de encoding wordt gedaan.

Voorbeeld:
http://portal/TestLijst1/NewForm.aspx?DefaultCategorie="Categorie 3"

wordt encoded naar:

http://portal/TestLijst1/NewForm.aspx?DefaultCategorie=%22Categorie%203%22

Hierin zijn de aanhalingstekens vervangen door %22 en de spaties door %20.

Handige teksteditors: NoteTab en Notepad++

Voor de die hards en diegenen die gewoon HTML/JavaScript code willen bekijken is NoteTab een aanrader: een *gratis* (light versie) teksteditor (ja, die bestaan nog, uit een ver verleden) met leuke mogelijkheden.

Info en downloaden? Zie: http://www.notetab.com.

De IE Developer Toolbar: handige tool voor het analyseren van web pagina's

Wat bij de analyse van SharePoint web pagina's enorm helpt is de IE Developer Toolbar, een add-on op Internet Explorer waarin je de DOM objectstructuur van een webpagina kunt bekijken en doorzoeken. Het verdeelt het browser window in twee delen: een bovenliggend deel met de opgemaakte HTML pagina, en een onderliggend deel waarin de eigenschappen van de DOM-elementen worden weergegeven. De IE Developer Toolbar is te downloaden op de volgende lokatie: http://www.microsoft.com/download/en/details.aspx?id=18359.

Een praktische toepassing
Voor een praktische toepassing van de IE Developer Toolbar, zie mijn artikel Aanpassen van lijst- en bibliotheekformulieren zonder SharePoint Designer of InfoPath.

Aanpassen van lijst- en bibliotheekformulieren zonder SharePoint Designer of InfoPath

Kent u de frustratie? Geen InfoPath voorhanden, geen SharePoint Designer voorhanden, en toch een vriendelijk doch dringend verzoek om het invullen van een formulier (b.v. voor een lijst- of bibliotheek-item) aan te passen. Valide redenen voor dit soort verzoeken zat; vooringevulde velden, speciale checks op de veldwaarden (b.v. een ELF check voor bankrekeningnummers), waarschuwingen, extra hulp voor gebruikers, et cetera.
En met InfoPath kun je zulke functionaliteit redelijk simpel implementeren in formulieren, en middels SharePoint designer kun je de standaard lijst- en bibliotheek invulformulieren relatief simpel aanpassen. Maar zonder deze tools... tsja... het Edit page - menu (onder het Site actions - menu ontbreekt nueenmaal bij deze standaard lijst- en bibliotheek invulformulieren. En wat doe je dan?

Gelukkig bestaat er een manier om toch, zonder InfoPath en Designer, en gewoon "met de browser" de standaard lijst- en bibliotheek invulformulieren kunt wijzigen.

De truuk bestaat eruit om de URL van het betreffende invulformulier te voorzien van de parameter ToolPaneView=2.

ToolPaneView en andere parameters
Voor de volledigheid: de parameter ToolPaneView kent de volgende waarden:
- ToolPaneView=2: Toevoegen van Webparts (browse)
- ToolPaneView=3: Add Web Parts (zoeken)

Naast de ToolPaneView zijn de volgende parameters beschikbaar:
- mode=view: View Mode
- mode=edit: Edit Mode

- PageView=Shared: Shared Mode, voor iedere gebruiker zichtbaar
- PageView=Personal: Personal Mode, voor de huidge gebruiker zichtbaar

Terug naar onze casus: ToolPaneView=2...
Wat we willen bereiken is dat we meer controle hebben over de invoer van gegevens in bijvoorbeeld een lijst. Hiertoe zijn twee standaard webpagina's beschikbaar:
NewForm.aspx: voor het aanmaken van een nieuw item in een lijst
EditForm.aspx: voor het wijzigen van een item in een lijst

Voorbeeld:
Stel, we willen het standaard formulier voor het aanmaken van een nieuw item in de lijst "Taken" wijzigen. We gebruiken dan de URL:

http://portal.demo.intra/DigitaalLoket/Lists/Taken/NewForm.aspx?ToolPaneView=2

Aanpassingen aan het standaard formulier
Zoals ik in mijn artikel JavaScript in Inhoudseditor webonderdelen: eenvoudige uitbreidingen op webpagina's heb beschreven kan de inhoud van een webpagina worden gewijzigd door gebruik te maken van JavaScript dat in het Inhoudseditor webonderdeel (Content Editor webpart) kan worden ondergebracht. Hiermee kan extra functionaliteit (lees: controles, wijzigingen in veldwaarden) worden geimplementeerd.

Gewenste aanpassingen
Wat in een formulier aangepast zou kunnen worden zijn, bijvoorbeeld, de volgende zaken:
- Controles op veldwaarden
- Invullen van standaard waarden, immers: deze kunnen via de standaard mogelijkheden van SharePoint slechts 1 maar ingesteld worden en dat is vaak onvoldoende, zelfs met het gebruik van berekende velden (Calculated fields).
- Geven van extra toelichting bij de invoer van gegevens (als een soort online hulp).

Middels JavaScript kunnen bovenstaande aanpassingen uitgevoerd worden. Dit kan gebeuren door triggers te definieren op velden en waarden van velden aan te passen door deze direct in het DOM object model aan te passen. Wat hierbij natuurlijk van belang is is het terugvinden van de velden in het DOM object model. Dat kan door de HTML broncode te analyseren, maar ook door het bekijken van het DOM object model achter de betreffende webpagina middels een tool: de IE Developer Toolbar.

IE Developer Toolbar
Wat in dergelijk generd enorm helpt is de IE Developer Toolbar, een add-on op Internet Explorer waarin je de DOM objectstructuur van een webpagina kunt bekijken en doorzoeken. Het verdeelt het browser window in twee delen: een bovenliggend deel met de opgemaakte HTML pagina, en een onderliggend deel waarin de eigenschappen van de DOM-elementen worden weergegeven. De IE Developer Toolbar is te downloaden op de volgende lokatie: http://www.microsoft.com/download/en/details.aspx?id=18359.

Wat hierin natuurlijk van belang is dat dit soort aanpassingen niet lastig onderhoudbaar worden en dat het niet ten koste gaat van de stabiliteit van de webformulieren. Wat dat laatste betreft: een webpagina kan door een slecht functionerend JavaScript de browser "ophangen". Neem als voorbeelden hiervan een JavaScript dat bestaande functionaliteit vervangt of zo lang duurt dat het laden van een pagina een eeuwigheid laat duren. En dat kan niet de bedoeling zijn. Wees er dus voorzichtig mee. Mocht een pagina toch slecht gaan functioneren, kan het web onderdeel dat het JavaScript bevat altijd middels een speciale view (zie hiervoor mijn artikelen: Handige URL's en Help, ik heb wat fout gedaan! Eerste hulp bij SharePoint problemen... (onderdeel "Herstel van web pagina's die niet correct worden weergegeven") uit de pagina worden verwijderd.

Een praktisch voorbeeld
Stel: we willen bij het aanmaken van een lijst-item de volgende zaken realiseren:
- Bepaalde velden een standaard waarde meegeven
- Op bepaalde velden controles uitvoeren

Allereerst moeten we ervoor zorgen dat deze velden in JavaScript te benaderen zijn. Dit kan door een JavaScript toe te voegen in een Content Editor webpart onderaan de pagina (onderaan omdat dan de bovenliggende velden beschikbaar en dus ook benaderbaar zijn in het DOM object model). Dat script zoekt de velden op in het DOM model van de betreffende webpagina. De velden zijn in de HTML code van de pagina terug te vinden door te zoeken op de HTML tag en de title van het veld (zoals die bekend is als column naam in de SharePoint lijst), bijvoorbeeld een input veld met als title "Achternaam". Voorbeeld: input ... title="Achternaam".
Het JavaScript zoekt deze velden op en houdt verwijzingen ernaar bij zodat ze te gebruiken zijn als objecten en derhalve bewerkt kunnen worden.

Hiervoor kan de volgende JavaScript functie worden gebruikt:

   function GetFieldObject( iTagName, iTitle ) {
      var vObject;
      var vObjects = document.getElementsByTagName( iTagName );
      var i = 0;

      for ( i = 0; i < vObjects.length; ++i ) {

         if ( vObjects[i].getAttribute("title") == iTitle ) {
            vObject = vObjects[i];
         }

      }

      return( vObject );
   }

Deze functie kan als volgt worden gebruikt:

   var vFieldTitle = GetFieldObject( "input", "Title" );

Als we van ieder veld een verwijzing (variabele) beschikbaar hebben kunnen we daar verschillende dingen mee:
- Veldwaarden uitlezen en instellen (standaard waarden).
- Functies aan toewijzen, die bijvoorbeeld worden uitgevoerd als een veld wordt gewijzigd.
- Velden verbergen en zichtbaar maken
- Veldkleur veranderen, als een veld bijvoorbeeld een verkeerde waarde heeft

Enkele voorbeelden:

Uitvoeren van de functie EvaluateForm nadat een veld is ingevuld:

vFieldTitle.onblur = EvaluateForm;

Houd er rekening mee dat andere veldtypen ook andere event triggers gebruiken. Wanneer een combo box van waarde verandert, moet je onchange gebruiken in plaats van onblur.

Instellen van een veldwaarde:

vFieldTitle.value = vGeselecteerdFormulier;

Veranderen van kleur van een veld:

vFieldTitle.style.color = "#00ff00";

Sommige velden zijn wat lastiger...
Datum/tijd velden bestaan in Sharepoint uit meerdere delen: een datum-, uren- en minuten veld. Bovendien zijn de waarden van deze velden ook nog eens beperkt:
Uren velden (combobox) kunnen alleen waarden bevatten als "10 AM" en "12 PM", terwijl minuten velden (combobox) alleen waarden bevatten als "00", "05", .. "55". En deze waarden zijn ook nog eens afhankelijk van de versie van SharePoint en instellingen (reden te meer om voorzichtig te zijn met dit soort oplossingen). Om deze velden te kunnen manipuleren en dit ook nog eens in leesbare JavaScript code te implementeren, kun je gebruik maken van JavaScript objecten die de betreffende veldverwijzingen bevatten. Heb je zo'n object nueenmaal aangemaakt kun je de data/tijden manipuleren. Wat daarbij ook handig is is een functie waarmee je JavaScript data/tijden kunt converteren naar waarden in je JavaScript object. Al met al een hele klus.

Zichtbaar maken of verbergen van velden
Hiertoe moet een gehele rij in de tabel (TR) worden verborgen of zichtbaar worden gemaakt (style.display = "none" of "").

Dit kan gebeuren door een functie te maken die als volgt wordt aangeroepen:

HideViewFieldRow( "WorkflowStatus_Timestamp_Ingevoerd", true );

De eerste parameter is de naam die voor het betreffende veld in de webpagina staat, bijvoorbeeld "Title".
De tweede parameter geeft de zichtbaarheid aan van het betreffende veld:
- true: zichtbaar
- false: onzichtbaar

Onderstaande functies realiseren dit:

   function HideViewFieldRow( iLabel, iVisible ) {
      var vFieldRow = GetFieldRow( iLabel );

      if ( iVisible )
         vFieldRow.style.display = "";
      else
         vFieldRow.style.display = "none";

   }

   function GetFieldRow( iLabel ) {

      // Scan op 

      var vObjects = document.getElementsByTagName( "TD" );
      var i = 0;

      for ( i = 0; i < vObjects.length; ++i ) {
  
         if ( vObjects[i].className == "ms-formlabel" &&
              vObjects[i].innerHTML.indexOf( iLabel ) != -1 ) {
            // Return parent node ()
            return( vObjects[i].parentNode );
         }

      }

      // iLabel Niet gevonden
      return( null );

   }

Instellen van standaard waarden / instellingen a.d.h.v. URL parameters
De default waarde van een veld of andere instellingen kunnen eenvoudig worden gerealiseerd door parameters aan de URL van de webpagina toe te voegen die in het JavaScript worden opgevangen. Hiermee kunnen velden worden ingevuld, aan- en uit worden gezet, et cetera.

Voorbeeld:
Een URL met parameters:

http://portal.demo.intra/DL2/Lists/TestLijst1/NewForm.aspx?iFormulierNaam=Categorie%203

Hierin wordt voor de parameter iFormulierNaam de waarde "Categorie 3" meegegeven.

En middels het onderstaande JavaScript worden de parameters ingelezen en gebruikt; de parameter iFormulierNaam wordt gebruikt om de waarde van de combobox vFieldCategorie in te stellen.

   function GetParm (testing) {

     testing = testing.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");
     var regexS = "[\\?&]"+testing+"=([^&#]*)";
     var regex = new RegExp( regexS );

     var vURL = window.location.href;
     vURL = vURL.replace("%20", " ");

     var results = regex.exec( vURL );
     if( results == null )
        return "";
     else
        return results[1];
   }

   function GetAndSetDefaults () {

      var vGeselecteerdFormulier = GetParm( "iFormulierNaam" );
      vFieldCategorie.value = vGeselecteerdFormulier;

   }

Let op: in het bovenstaande script moet de URL encoding (zie ook: Handig: URL encoder) ook worden uitgefilterd. Dit is in het voorbeeld deels gedaan; de %20 wordt vervangen door een spatie.

Bewerken van meerdere velden tegelijk
Door gebruik te maken van arrays (van objecten) kunnen meerdere velden tegelijk worden bewerkt:

var vFormulierDeel1 = [ vFieldCategorie, vFieldTitle, vFieldAchternaam ];

Deze array kan als parameter worden doorgespeeld aan functies die deze velden tegelijk bijvoorbeeld verbergen of zichtbaar maken. Dit is bruikbaar wanneer verschillende personen verschillende delen van een formulier moeten invullen en de rest van het formulier niet mogen zien en/of bewerken.

Een stapje verder: een primitieve workflow met JavaScript
SharePoint ondersteunt standaard maar een beperkt aantal workflow typen. Vaak bieden deze mogelijkheden net wat te veel beperkingen. Goed alternatief is natuurlijk gebruik te maken van SharePoint Designer waarin je zelf workflows kunt definieren, of InfoPath waarin je workflow kunt simuleren door een formulier een bepaalde status mee te geven. Echter: deze tools zijn niet altijd voorhanden.
In die gevallen kun je overwegen om workflow te simuleren door de status van een formulier als veld (lijstkolom) op te nemen en op basis hiervan middels JavaScript delen van het formulier te tonen of te verbergen voor personen die in deze workflow betrokken worden. Ook is het mogelijk om aan de verschillende stappen in de workflow een timestamp toe te voegen (voor iedere stap een aparte kolom/veld) die automatisch gevuld wordt wanneer het formulier in een bepaalde status wordt ingevuld.

Een stap verder: gebruik JQuery
JQuery is een JavaScript bibliotheek waarmee relatief simpel het DOM object model van een HTML pagina kan worden bewerkt. De bovenstaande voorbeelden kunnen hiermee gemakkelijker worden gemplementeerd. Het is het zeker waard je eens te verdiepen in de mogelijkheden ervan. In een komende blogpost zal ik hier wat voorbeelden van geven. De JQuery JavaScript bibliotheek kan aan SharePoint Masterpages worden toegevoegd, of opgenomen worden in een SharePoint bibliotheek (als dat is toegestaan), waarna de JQuery functies in Web pagina's (Content Editor Web onderdelen) kunnen worden gebruikt. Voor een eerste kennismaking met JQuery, zie http://jquery.com/.

Kanttekeningen
Ofschoon het aanpassen van de "standaard" gebruikersinterface technisch mogelijk is, is het niet altijd wenselijk. In het algemeen geldt voor SharePoint (maar ook alle andere standaard platformen die door niet ICT specialisten kunnen worden aangepast en uitgebreid) dat zoveel mogelijk gestreefd moet worden naar een "standaard", dat wil zeggen: uitzonderingen zoveel mogelijk vermijden. Reden hiervan is dat uitzonderingen moeite (en dus: geld en doorlooptijd) kosten. En die moeite komt meestal ongelegen, bijvoorbeeld tijdens migratie naar een nieuwe versie van het platform of tijdens een upgrade waarin over het hele platform wijzigingen worden doorgevoerd. Ook kunnen versieverschillen (talen, regionale instellingen) roet in het eten gooien. Tijdens dergelijke acties moeten voor iedere uitzondering op de standaard voorzieningen getroffen worden om de uitzondering nog te laten functioneren na de wijziging. En als iedereen ongecontroleerd uitzonderingen kan doorvoeren kan dit tot veel onvoorzien werk leiden.

Een voorbeeld:
In een platform zijn door eindgebruikers een aantal functies aangepast, zonder overleg met de ICT afdeling. Tijdens de migratie lijkt alles goed te gaan, de ICT afdeling voert een automatische upgrade uit en de nieuwe versie van het platform gaat live. Tijdens het gebruik van de nieuwe versie van het platform blijkt al gauw dat sommige functies niet naar behoren functioneren. Hiervan worden meldingen gedaan ("de nieuwe versie doet het niet") en na analyse komen de aanpassingen aan het licht. Vervolgens moet bekeken worden hoe de aanpassingen weer functioneel gemaakt kunnen worden en er ontstaat een discussie of deze wijzigingen nog wel wenselijk zijn. De gebruikers zien de aanpassingen als "vervorven rechten" en de ICT afdeling zal onder druk gezet worden deze wijzigingen als maatwerk te implementeren. En intussen is de functionaliteit voor de eindgebruiker niet te gebruiken.
Een onwenselijke situatie dus.

Om dit soort situaties te voorkomen zullen, voordat aanpassingen uitgevoerd worden, de volgende overwegingen gemaakt moeten worden:
- Is de aanpassing echt noodzakelijk? Kan de functionaliteit echt niet op een geaccepteerde "SharePoint standaard" wijze worden geimplementeerd?
- Als aanpassing noodzakelijk is, is er meer vraag naar deze functionaliteit zodat voor iedere vraag een standaard oplossing (aanpassing) kan worden geimplementeerd? Kijk hiervoor ook verder dan SharePoint sites, zie hiervoor ook mijn artikel Gebruik je hele gereedschapskist (dus niet alleen SharePoint websites)!
- Hoe moet met deze wijziging worden omgegaan wanneer platform brede wijzigingen (b.v. upgrade, migratie) worden doorgevoerd? Zie hiervoor ook mijn artikel over maatwerk Out-of-box of maatwerk, that's the question (HansR on Architecture).

In het algemeen geldt: eerst nadenken, dan doen. Da's een stuk goedkoper dan andersom.

(een collega was het ten dele eens met de bovenstaande stelling. Zijn punt: "fouten maken kunnen inderdaad kostbaar zijn maar kunnen ook heel veel extra (nuttige) kennis opleveren.". Daarmee kan ik het helemaal eens zijn: van fouten maken leer je. Een kleine kanttekening hierbij: bij het ondernemen heb je ruimte nodig om te experimenteren, maar om levensvatbaar te blijven moet deze ruimte wel gemanaged (lees: beperkt) worden.)

En nu in SharePoint 2010, met een betere opzet
Intussen heb ik een vervolg blogpost op deze post gepubliceerd met daarin bescheven hoe de bovenstaande truuks in SharePoint 2010 kunnen worden toegepast. Ik heb daarin een wat betere opzet gebruikt waarin de SharePoint velden in een JavaScript object model worden gezet. Dit als een soort tussenlaag tussen het DOM objectmodel en de intelligentie in de web pagina. Dit is te lezen in Aanpassen van lijst- en bibliotheekformulieren in SharePoint 2010, zonder SharePoint Designer of InfoPath.

Gebruik je hele gereedschapskist (dus niet alleen SharePoint websites)!

Soms kan ik wel van de daken roepen. Dit is niet iets dat ik vaak bij klanten doe, tenzij ik te vroeg mijn koffie uit de automaat tracht te halen, het blijkt dat ik eerst een bekertje had moeten plaatsen en de automaat de hete koffie plichtsgetrouw maar niet gebruiksvriendelijk over mijn hand giet. De reden waarom ik dit soms figuurlijk wil doen is dat SharePoint weer een keer als Steen der wijzen wordt gebruikt. Nogmaals: het is een mooi, veelomvattend platform, maar soms zijn er handiger oplossingen waarin SharePoint een onderdeel is, en niet de totale oplossing. Dit vergt echter een kritische blik en vantevoren nadenken.

Maar wat is het geval?
SharePoint wordt vaak inzet als portal (in de vorm van en website), als (web) toegangsdeur en bewaarplaats voor documenten, andere informatie en functionaliteit. Dat is op zich terecht, want SharePoint leent zich daar uitstekend voor. Maar bij het doen van "dagelijks werk" hebben eindgebruikers nueenmaal indivuele eisen en wensen. En gezien eindgebruikers zowel de beschikking hebben over een ruime hoeveelheid aan gereedschappen (lees: applicaties en apparatuur) en ze de laatste decennia veel ruimte hebben gekregen hun eigen informatiewerkplek (lees: pc, desktop, "windows" of andere omgeving) zelf in te richten, is het opleggen van een nieuwe werkwijze (lees: een website waarin ineens (samen)gewerkt moet worden), een uitdaging.

Een concreet voorbeeld: de "startpagina"
Een voorbeeld van wat ik in de praktijk tegenkom is de zogenaamde startpagina; een pagina die als verplichte toegangspoort wordt gebruik voor functionaliteit die ook (of beter) via andere wegen kan worden benaderd. Neem nu een startpagina voor het maken van vergadersites. Een vergadersite is een SharePoint website waarin informatie over een vergadering en documentatie bij een vergadering wordt opgeslagen. Aanmaken ervan wordt verplicht gesteld via de startpagina terwijl vergaderverzoeken door eindgebruikers worden gemaakt in Outlook. De eindgebruiker moet dan twee handelingen uitvoeren in twee verschillende applicaties: namelijk aanmaken van een nieuwe vergadering in Outlook en de bijbehorende website aanmaken via de startpagina in SharePoint. En tot overmaat van ramp moet de eindgebruiker de vergadersite ook nog op de een of andere manier laten gebruiken door de deelnemers aan de vergadering. Dat kan hij doen door de een mail te sturen of door de link in de vergadersite op te nemen. Dit legt de eindgebruiker dus een omslachtige manier van werken op die in de praktijk natuurlijk slecht zal worden gebruikt en zal worden omzeild.
Een betere oplossing voor de bovenstaande casus is de vergadersites via Outlook te kunnen aanmaken en beheren en de startpagina te gebruiken als "een handig overzicht van alle vergaderingen". Zo sluit de SharePoint vergaderruimte aan op de vertrouwde en handige werkwijze van de eindgebruiker. Gevolg: de eindgebruiker is eerder geneigd vergadersites te gebruiken en informatie wordt beter en op een handiger manier gedeeld; deelnemers aan de vergadering hebben bijvoorbeeld allemaal dezelfde versies van agenda's, notulen en andere documentatie.

In het bovenstaande voorbeeld is duidelijk is dat de inzet van alleen SharePoint (websites) onvoldoende (en zelfs onhandig) is.

Wat hier verkeerd gaat is dat uitsluitend wordt uitgegaan van de website functie van SharePoint, niet van het totaal aan gereedschappen (lees: apparatuur en applicaties) die de gebruiker ter beschiking heeft. Daarmee wordt SharePoint, en niet de eindgebruiker, als uitgangspunt genomen. En dat is fundamenteel fout.

Uitgangspunt: de eindgebruiker
Uitgangspunt zal altijd moeten zijn: de eindgebruiker. In dit geval natuurlijk gemodelleerd in een persona (of meerdere persona's). Een persona, een archetype van een gebruiker, ofwel een karakterisering van een bepaald type van gebruiker (zie: http://nl.wikipedia.org/wiki/Persona_(IT)), geeft de analist, ontwerper, bouwer inzicht in de doelstellingen, omstandigheden en voorkeuren van een eindgebruiker(stype). Daarmee kan de te bouwen oplossing beter afgestemd worden op de behoeften van de eindgebruiker. Wat hierin, mijnsinziens, nogal eens over het hoofd gezien wordt, maar toch belangrijk is, zijn de gereedschappen die de eindgebruiker tot zijn beschikking heeft en het gebruik ervan voor zijn taken in de diverse omstandigheden waarin deze eindgebruiker terecht kan komen. Klinkt misschien cryptisch? Laat ik een concreet voorbeeld geven...

Maak kennis met de Accountmanager
Persona Accountmanager heeft als taak om produkten bij klanten te verkopen, klanten voor te lichten en klanten te vragen hoe ze de producten ervaren. 't Is een drukke baan waarvoor hij veel onderweg is en onder hoge druk moet presteren. Hij werkt dagelijks in de ochtend op kantoor en tegen de middag gaat hij naar zijn afspraken. Als hij de afspraken heeft gehad gaat hij naar huis en werkt hij daar op zijn laptop verder. Hij heeft daarbij toegang tot het netwerk van zijn werkgever.

De accountmanager werkt onder drie verschillende omstandigheden:
- Op kantoor
- Onderweg, in de auto
- Bij de klant
- Thuis

De accountmanager heeft de beschikking over de volgende gereedschappen:
- Zijn laptop, met daarop MS-Office (Word, Excel, Outlook, Access en PowerPoint ('t blijft een accountmanager), VPN applicatie voor toegang tot het netwerk van zijn werkgever, een WiFi zender/ontvanger, een synchronisatie applicatie om mail met zijn smartphone uit te wisselen.
- SharePoint: de verzamelplaats voor alle documenten van zijn verkoopafdeling, waarvoor een speciale site is ingericht. Hierin zijn offertes, documentatie over de procedures, klantinformatie et cetera opgeslagen. De omgeving wordt door alle accountmanagers gebruikt.
- Zijn smartphone, met daarop een e-mail "App", een "App" voor navigatie, een WiFi zender/ontvanger en GPS (voor zijn navigatie)
- Een WiFi thuisnetwerk voor thuisgebruik van zijn laptop.

In de bovenstaande omstandigheden kunnen niet alle gereedschappen gebruikt worden. En daarbij heeft de accountmanager onder verschillende omstandigheden een voorkeur voor bepaalde gereedschappen.

Voorbeelden
Enkele voorbeelden:
- Op werk mailt de accountmanager met Outlook vanaf zijn laptop. Gebruik van zijn SmartPhone is voor hem minder gebruiksvriendelijk, tenzij hij natuurlijk in een vergadering zit.
- De accountmanager werkt veel in Outlook, Excel en PowerPoint. De documenten slaat hij voornamelijk op op zijn lokale harde schijf. Definitieve versies en versies die door anderen beoordeeld of gebruikt worden, upload hij naar SharePoint (als hij op dat moment tenminste toeganbg heeft tot het netwerk van zijn werkgever). Vanwege de drukte schiet het "delen" van documenten via SharePoint er in de praktijk weleens bij in.
- Onderweg mail de accountmanager via zijn SmartPhone (even aangenomen dat de auto dan stil staat).
- Bij de klant heeft de accountmanager geen toegang tot internet en daarmee ook niet tot het netwerk van zijn werkgever (dit is een aanname voor deze casus, in de praktijk kan toegang technisch mogelijk zijn). Zodoende kan hij niet mailen, en niet bij documenten (SharePoint). Hij kan alleen offline werken.- Thuis heeft de accountmanager via zijn laptop toegang tot dezelfde informatie en applicaties als op werk.

Uit het bovenstaande blijkt dat de accountmanager de beschikking heeft over een aantal gereedschappen die hij onder verschillende omstandigheden wel, liever niet of helemaal niet kan gebruiken. Wat al grote verbeteringen zouden zijn in de gereedschapset van deze accountmanager zijn:
- Kunnen mailen van documenten naar dde gezamenlijke SharePoint site.
- Documenten beschikbaar stellen via een Outlook folder zodat de accountmanager voor de meest recente documenten niet naar de SharePoint web site hoeft te navigeren.
- Automatische synchronisatie van lokaal (laptop) opgeslagen documenten met de documenten in de SharePoint site.

En wat daar natuurlijk bij hoort is een instructie / training om de gereedschappen doeltreffend en doelmatig te gebruiken.

De juiste communicatiemix
Bovenstaande verbeteringen kunnen natuurlijk verder worden aangevuld, maar wat ik ermee wil zeggen is dat hierin verder wordt gekeken dan SharePoint zelf. Er wordt rekening gehouden met (bijna) alle gereedschappen en (bijna) alle omstandigheden waarin de persona zijn taken uitvoert. In andere woorden: de "communicatiemix" (zie voor een aardige definitie hiervan: http://pensioen-wiki.wikidot.com/communicatiemix) wordt zoveel mogelijk afgestemd op de taken en omstandigheden van deze persona.

Te veel focus op websites
In SharePoint implementaties zie ik in de praktijk echter een te grote focus op de website functie van SharePoint en daarmee wordt de eindgebruiker verplicht om alle functionaliteit en informatie via de webbrowser te benaderen. En dat legt de gebruiker beperkingen op, bijvoorbeeld:
- De website is lastiger te gebruiken op apparatuur met een kleiner beeldscherm als SmartPhones
- De gebruiker moet op dat moment toegang hebben tot de SharePoint omgeving, online zijn en b.v. via VPN toegang hebben
- De gebruiker moet zijn voorkeur werkwijze aanpassen. Nu moet hij documenten vanuit een website ophalen en, na aanpassen, hierin weer uploaden.

De makkelijkste weg kan leiden tot ondoelmatig (samen)werken
En in de praktijk zal de eindgebruiker (en zeker eindgebruikers die het druk hebben, zoals onze Accountmanager) de makkelijkste weg kiezen en de beste manier van werken wellicht omzeilen. Dit heeft gevolgen voor het doelmatig uitvoeren van taken (ergens omheen werken kost nueenmaal meer tijd dan nodig), en voor het doelmatig kunnen samenwerken (delen van informatie gebeurt nu minder en meer op ad hoc basis).

Conclusie en aanbevelingen
Bij het bedenken van gebruikersondersteuning wordt vaak uitsluitend uitgegaan van slechts 1 stuk gereedschap, vaak alleen de website functie van SharePoint, niet van het totaal aan de voor de eindgebruiker beschikbare gereedschappen (lees: apparatuur en applicaties). Daarmee worden oplossingen bedacht die niet aansluiten op de behoeften en mogelijkheden van de eindgebruiker, hetgeen het doelmatig uitvoeren van taken en samenwerking niet ten goede komt.
Denk dus breder dan websites en inventariseer eerst de beschikbare gereedschappen en de omstandigheden waarin deze gebruikt kunnen worden.
't Is weer een kwestie van (durven) nadenken voordat de weg van de implementatie wordt bewandeld, en het risico nemen dat dat niet altijd in dank wordt afgenomen.

Meer lezen?
Gebruik van Excel voor het ophalen en verwerken van gegevens vanaf het web (en dus ook SharePoint lijsten): Management rapportage in Excel.

Berekeningen in SharePoint: berekende velden

Waarom een artikel schrijven als je al een aantal mooie stukken documentatie hebt gevonden?

Formules kunnen gebruikt worden voor de bepaling van de standaard (default) waarde in een kolom maar ook voor de berekende waarde van een kolom en in filters (views, weergaven).

Formules en functies

Calculate data in lists or libraries

Date Functions in Calculated Fields

Datum berekeningen

Calculate data in lists or libraries:

• Add a calculated column to a list or library


• Make a calculated column available to other lists or libraries


• Add a calculated site column to a list or library

Functions for use in a MOSS 2007 column
Today] en [Me] zijn alom bekend, maar er zijn veel meer functies.

Voorbeelden van veel gebruikte formules

Veelgebruikte Datum/Tijd functies

Let op: De waarde van een berekende kolom kan alleen van het type:
- Single line of text
- Number (1, 1.0, 100)
- Currency ($, ¥, €)
- Date and Time
- Yes/No
zijn.

Let op: Alleen in kolommen van het type "Calculated (calculation based on other columns)" kunnen verwijzingen gebruikt worden naar andere kolommen. Als je een verwijzing probeert te gebruiken in een formule voor de standaard (default) waarden van een kolom (Calculated Value), krijg je de melding: "The formula contains reference(s) to field(s).".

Let op: De waarde van een berekende kolom wordt pas aangepast (berekend) als het betreffende (lijst) item wordt aangepast (bewaard).

Let op: Berekende kolommen kunnen geen functies bevatten als [Today] of [Me]. Dit geeft de foutmelding: "Calculated columns cannot contain volatile functions like [Today] and [Me].".
Om dergelijke functies toch te gebruiken, kun je de truuk gebruiken die in dit artikel wordt beschreven. Hierin wordt een extra kolom (b.v. "MyToday") aangemaakt waarnaar je wel in een formule kunt verwijzen. Deze truuk, echter, werkt in veel gevallen niet zoals je zou verwachten (zie dit artikel). De extra kolom (b.v. "MyToday") is namelijk statisch, deze verandert niet van waarde en blijft dus altijd de initiele waarde hebben.
In situaties waarin je items wilt tonen die b.v. ouder zijn dan een bepaalde datum kun je wel gebruik maken van [Today], namelijk in een filter in een view.

Let op: Spaties in filter formules zijn niet toegestaan: b.v. [Today] – 7 is fout, [Today]-7 is goed.

Let op: De Nederlandse versie van SharePoint (zoals dat ook in Excel het geval is) kent wat verschillen ten opzichte van de Engelstalige versie van SharePoint wat betreft formules, b.v. functienamen.

(‘t Artikel komt later. Echt.)