Mijn Leven Als Blogger (In 2014)

“Sociale media” zijn in de loop van de voorbije jaren deel gaan uitmaken van processen en structuren binnen heel wat bedrijven. Hopelijk is dat niet gebeurd vooraleer één en ander duidelijk was voor de hele organisatie: Welke rol spelen FB, Twitter, blogs, etc. binnen uw bedrijf? Hoe belangrijk zijn ze? Hoe worden ze ingezet?

Om het personeel duidelijk te maken wat het belang is van die sociale media kan het nooit kwaad om ze duidelijk te omschrijven en te positioneren. In december 2014 werd mij gevraagd om het onderwerp “bloggen” toe te lichten. Dit is het verhaal dat ik toen vertelde: “My life as a blogger” (PDF), en dat verhaal is nog steeds actueel.

So tell me about yourself: where do you blog?

Klik op deze afbeelding voor
meer cartoons van Quirit.

(Oorspronkelijk gepubliceerd op mijn Engelstalige blog, op 6 augustus 2016)

Content Management: Even De Puntjes Op De I Zetten

Knowledge Management” (KM) en “Content Management” (CM): het zijn beide termen die de laatste jaren erg populair zijn geworden, maar waar tegelijkertijd heel wat vragen worden bij gesteld. Waarover gaat het juist? Wat moet u er zich bij voorstellen in uw specifieke situatie? Wat gaat het me opbrengen? Heb ik het wel nodig? Hoe doe ik dat dan?

Het is in dit artikeltje niet de bedoeling om al die vragen uitgebreid te behandelen. Laat ik om te beginnen de beide termen toch even verduidelijken.

De engelstalige Wikipedia definieert “content management” als volgt: “Content management (CM) is a set of processes and technologies that supports the collection, managing, and publishing of information in any form or medium“.  “Knowledge management” wordt omschreven als “the process of capturing, developing, sharing, and effectively using organizational knowledge“. Wie meer wil weten over KM (Kennisbeheer) verwijs ik graag door naar Steven Warmoes.

Ik wil hier vandaag een paar essentiële punten te maken over CM. Ik doe dat aan de hand van een artikeltje dat enkele mythes over KM doet sneuvelen: “5 Knowledge Management Myths Debunked“. Het is zeker niet het enige lijstje dat dit doet, en niet noodzakelijk het beste lijstje van die aard. Maar als je de term “KM” vervangt door “CM” blijft het even correct, en is het nog steeds toepasselijk! Kijk maar:

  • CM heeft dure technologie nodig“. Welnee! In hun meest eenvoudige vorm kan je zowel KM als CM bedrijven met enkel een kast, papier en pen… maar het spreekt vanzelf dat moderne IT zich snel rendabel maakt eens de volumes groter worden. En zoals het artikel ook zegt: de kost van geen CM (of KM) is waarschijnlijk groter dan die van een goed gekozen oplossing.
  • CM is mijn probleem niet“. Toch wel, want CM gaat iedereen in de organisatie helpen om sneller de juiste informatie te vinden. Of wordt u graag van het kastje naar de muur gestuurd in een zoektocht naar de juiste info, procedure of persoon?
  • If You Build It, They Will Come” is een (foute) quote uit een bioscoopfilm. U mag het interpreteren als: “Dit product is zo geweldig, dat iedereen het meteen gaat willen kopen/gebruiken“. Misschien, maar in de realiteit is de kans daarop klein, zeker als het gaat over de invoering van nieuwe processen en nieuwe tools. Immers: de meeste mensen houden niet van verandering, en elke grote wijziging in het dagelijks werk roept weerstand op. Het is dus belangrijk om eventuele vernieuwing zoveel mogelijk te laten aansluiten bij wat al gekend of in gebruik is, en om de noodzakelijke veranderingen te omkaderen met begeleidende maatregelen die de overgang verantwoorden, verduidelijken en inpassen in de globale organisatie.
  • CM heeft dure consultants nodig“. Ook deze uitspraak is niet correct. CM gaat in de eerste plaats over een manier van werken, op basis van strategische keuzes, regels en praktische afspraken. Dat is belangrijker dan de tools en hun implementatie, en is zeer afhankelijk van de specifieke kenmerken van uw organisatie of bedrijf. Het gaat dan immers over wie en wat en waar, en pas daarna over hoe. Een consultant kan helpen bij het zoeken naar de juiste antwoorden, maar u moet de antwoorden nog wel zelf leveren.
  • CM is een modeverschijnsel“. Als het dat al zou zijn, dan is het intussen een modeverschijnsel dat al meer dan een decennium meegaat, en nog niet meteen uitgeteld is. Dus neen, het is geen modeverschijnsel. De toename van de hoeveelheid gegevens in de maatschappij en in organisaties en bedrijven is van die aard dat het beheer van die informatie steeds belangrijker wordt in het overleven van diezelfde organisaties en bedrijven. Wat er intern in een organisatie met die informatie gebeurt is dus van levensbelang voor die organisatie. En laten we wel wezen: mode is zelden van levensbelang.
"What if we don't change at all ... and something magical just happens?"

Source: vmcnotes.net

Betekent dit alles nu dat het invoeren van een CM-systeem vanzelf gaat? Nee, zeker niet. Een succesvol CM-systeem heb je pas als je de juiste, strategische keuzes hebt gemaakt, na een goede behoefteanalyse en na een doordachte implementatie. Vergeet vooral niet dat de zwaarste uitdagingen op menselijk vlak liggen, niet op het technische. Want als we spreken over het bijsturen, vernieuwen, of zelfs vervangen van processen binnen een organisatie, dan moet er heel veel aandacht gaan naar het begeleiden van dat veranderingsproces bij de deelnemers aan het proces. “Change Management” dus, en toevallig ook af te korten met dezelfde twee letters als Content Management!

Wikibru Vier Jaar Later: Een Schamel Beestje

Bijna vier jaar geleden schreef ik kort over Wikibru, de toen pas gelanceerde wiki van de gemeente Brussel. Ik heb deze wiki niet intensief gevolgd, maar zelfs een enkel jaarlijks bezoekje maakt duidelijk dat er relatief weinig leven zit in de drie wiki’s (eentje per taal: Nederlands, Frans en Engels). Om maar een voorbeeld te geven: de voorlaatste toevoeging aan de nederlandstalige versie dateert van 29 november 2014, en de laatste van september 2015 (als we spamberichten niet meerekenen).

Inhoudelijk is de opbrengst ook maar mager: heel wat pagina’s zijn wel aangemaakt, maar bevatten geen echte “content”. Dat gebrek aan inhoud is misschien nog wel erger dan het gebrek aan updates. Zelfs de links in de voet van elke pagina wijzen naar… blanco inhoud. Op die manier heb je er als bezoeker niets te zoeken en zeker niets te vinden.

wikibru.png

Wat mij betreft is dit dus een voorbeeld van een “mislukte” wiki. Dat heeft in mijn ogen meer te maken met een gebrek aan “governance” van de wiki dan aan het gebruikte tool. De Mediawiki software heeft zijn sporen al verdiend en hoeft niks meer te bewijzen. Maar deze site is verwaarloosd. Kijk maar even mee:

  • Ze draait op een Mediawiki-versie uit 2014, terwijl er al verschillende nieuwere versies verschenen zijn. De gebruikte versie 1.24 wordt bovendien niet meer ondersteund door mediawiki.org.
  • Haar beheerders gooien er occasioneel een blik op, maar zijn blijkbaar niet geïnteresseerd in de inhoud, ongeacht door wie die wordt aangeleverd. Enkel spam wordt opgekuist, maar zelfs spammers hebben weinig belangstelling voor een site die niet bezocht wordt.
  • Er is duidelijk ook nooit moeite gedaan om te proberen om een “community” samen te brengen van mensen die bereid zijn om een deel van het werk rond aanleveren en editeren van die inhoud op zich te nemen. Wachten op spontane inbreng van toevallige passanten is geen bruikbare aanpak om kwaliteitsvolle content te garanderen!
  • De drie taalversies hebben geen onderlinge band: ze vermelden andere items, zonder dat er aan een vertaling of zelfs maar gewoon een verwijzing naar de andere talen gedacht is.

In de loop van 2008 heb ik samen met Bruno Peeters WikiPodium opgericht. WikiPodium moest een permanente community voor professionele wiki-gebruikers in België worden. Na een drietal jaar en een achttal bijeenkomsten met concrete cases bleek de interesse te beperkt om ermee door te gaan – jammer genoeg zijn de beschrijvingen van de bijeenkomsten verloren gegaan op de WIkiSpaces website. Was de “wiki-hype” toen al over?

“Wikibru” had nochtans heel wat kunnen leren uit wat er bij WikiPodium verteld is. Ook de Wiki-workshop die Bruno en ik kunnen brengen gaat (veel) dieper in op wat er komt kijken bij het “beheren” van een Wiki. Wie de fouten van “Wikibru” wil vermijden mag ons steeds contacteren. Wij kunnen niet garanderen dat uw wiki een denderend succes wordt, maar we kunnen u alvast helpen om de meest essentiële fouten te vermijden.

Ignite: De Toekomst Van Microsoft Office 365

Samen met een vijftiental anderen ben ik vorige week bij U2U gaan luisteren naar een samenvatting van wat Microsoft te vertellen had op de Ignite conferentie in Chicago enkele weken geleden.

Heel wat organisaties bouwen nu – in SharePoint en in Office 365 – eigen oplossingen voor zaken die in feite redelijk algemeen zijn: een nieuwskanaal, een smoelenboek, een video-verzameling, etc. Els vertelde ons oa. over de nieuwe “portals” die eraan komen voor gebruik in Office 365, zoals een Video Portal en een Knowledge Management Portal. Het standaard gedrag van deze portals zal aanpasbaar blijven, maar dan zonder dat er code aan te pas komt. Microsoft gaat ervoor trouwens zorgen dat de “slimme” Office Graph steeds meer en meer nieuwe onderdelen van het Office 365 universum gaat voeden, waaronder die “Next Generation Portals”.

Lieven had een uurtje gereserveerd om ons niet alleen te vertellen hoe we in de toekomst applicaties zullen bouwen die binnen de Office 365-omgeving werken, maar om het ook te laten zien aan de hand van enkele demo’s. Zo werd de geplande Office 365 Unified API een heel stuk concreter.

Bedankt, Els en Lieven, voor een mooi werkje.

Eén bedenking moet me toch van het hart, niet over de samenvatting, maar over de marketing speak van Microsoft. Het “Knowledge Management Portal” waarvan hoger even sprake was is (wordt) in feite niks anders dan een container voor hoofdzakelijk documenten en “microsites” (zeg maar artikel-achtige pagina’s die sterk lijken op de publishing pages uit SharePoint). Natuurlijk gaat ook hier de Office Graph een woordje meespreken.

knowledge-portal.jpg

Ik ga niet ontkennen dat je al die data en informatie uit de documenten nodig hebt om kennis op te bouwen, maar voor echt knowledge management is er toch heel wat meer nodig. Kennis opbouwen is een werkje voor mensen, waarvan het resultaat dan inderdaad zijn neerslag kan vinden in allerhande documenten. Maar alleen met een tool ga je de kennis in je organisatie niet bijeen krijgen, ook al heet dat tool dan “InfoPedia”. OK, het is maar een codenaam, maar het zegt veel over hoe Microsoft dit prototype nu al in de markt plaatst. Of dit kennisportaal een onderdeel is/wordt van het nieuwe intranet-product van Microsoft, zoals hier op CMSWire geschreven wordt, is voorlopig nog een open vraag… en stof voor discussie!

PS. Wie een goede indruk wil krijgen van wat kennisbeheer inhoudt, moet maar eens gaan rondneuzen op de blog van Steven Warmoes

WikiWand Moderniseert De “Look And Feel” Van De Wikipedia

Iedereen maakt wel eens gebruik van de Wikipedia, wanneer we een betrouwbaar stukje informatie over een thema willen consulteren. Het is u misschien niet opgevallen, maar de “look and feel” van de Wikipedia is in de loop van zijn dertienjarig bestaan haast niet gewijzigd. Als encyclopedie focust de Wikipedia op inhoud (“content”) en op de bereikbaarheid van die inhoud in termen van zoeken en navigatie. “Content” is tevens de focus van de meeste Wiki-software, en Wiki-software genaamd MediaWiki is het platform waarop de Wikipedia draait.

Tien jaar is lang in de geschiedenis van het Web, en er is al wel één en ander veranderd sinds het ontstaan van Wikipedia. Tien jaar geleden waren PC’s de enige toegang tot het Web; vandaag gebruikt een steeds toenemend aantal gebruikers smartphones, tablets, PC’s en slimme TV’s on te surfen. Tien jaar geleden was het voor Wikipedia essentieel om zoveel mogelijk inhoud te verzamelen en als brede encyclopedie erkend te worden; vandaag zijn er vermoedelijk in verhouding veel meer consumenten van Wikipedia-inhoud dan auteurs. Tien jaar geleden was er enkel een browser-gebaseerde interactie met de Wikipedia mogelijk; dezer dagen zijn er op alle platformen allerhande apps en toepassingen die de inhoud van Wikipedia geheel of gedeeltelijk op een specifieke manier presenteren.

Het mag dus niet als een verrassing komen dat iemand besliste om de “user interface”-lessen uit die decade toe te passen op de Wikipedia, en dat is met name WikiWand.

"Thee" in Google Chrome op de Mac

“Thee” in Google Chrome op de Mac

Er zijn twee manieren om WikiWand te gebruiken: je kan in de eerste plaats de WikiWand-website gebruiken via de zoekfunctie rechts bovenaan, of je kan het WikiWand-plugin (voor Chrome, Firefox of Safari) installeren in je browser en daarvan de default manier maken om de Wikipedia te consulteren. Ik test momenteel de website, en het moet gezegd: het ziet er gelikt uit, zowel op mijn Mac als op mijn smartphone. De smartphone-versie is een tikkeltje te sterk visueel gericht, want ze toont alle afbeeldingen vooraleer ze de tekst van een lemma afficheert. Het navigatiemenu links laat je echter toe om snel naar om het even waar in de tekst te springen, dus vele afbeeldingen zijn enkel een probleem wanneer je een trage (en mogelijks dure) netwerkverbinding gebruikt voor het mobiele surfen.

"Thee" in Google Chrome op een Android smartphone

“Thee” in Google Chrome
op een Android smartphone

Allemaal goed en wel, maar er blijft toch wel één vraag open. WikiWand is een commercieel bedrijf. Hoe gaan zij geld verdienen, zonder de Wikimedia Stichting te kort te doen? WikiWand zegt nu wel zich te zullen beperken tot “contextually-relevant ads for textbooks, articles and courses”, en belooft 30 percent van zijn winst aan de Wikimedia Stichting te zullen overmaken – maar enkel de toekomst zal uitwijzen of zij instaat zijn om die “education only” advertentiepolitiek vol te houden…

(Oorspronkelijk gepubliceerd op mijn Engelstalige blog, op 23 augustus 2014)

Wensen Voor Een Mobiel 2014 !

Op de Sitepoint website schrijft Craig Buckler: “Average Page Weights Increase by 32% in 2013“.

Totale transfer grootte en Totaal aantal requests
voor de periode 2012-12-15 tot 2013-12-15
(Bron: HTTP Archive – Trends)

Craig is verontrust door deze cijfers, en probeert de stijging te verklaren door ‘vette’ CMS templates en een zekere onverschilligheid bij de ontwikkelaars. Die twee fenomenen spelen waarschijnlijk wel mee, maar zijn m.i. toch een onvoldoende verklaring – we hebben natuurlijk ook meer onderzoek nodig dan alleen maar gemiddelden (en geen medianen, Craig!) om de zaak te doorgronden.

Wie nog even verder kijkt naar de broncijfers (de Trends pagina op de HTTP Archive site) kan nog erger ontwaren. Als ik de “Doc Size & DOM Elements” statistiek juist interpreteer, dan is er op dit moment nog minder echte ‘content’ op een gemiddelde pagina dan een jaar geleden. Web sites gebruiken dus blijkbaar meer bits om nog minder te vertellen? Misschien speelt een andere trend mee: het zou best kunnen dat er steeds meer advertenties en reklame op een pagina terechtkomen, die dan de ‘echte’ inhoud wegdrukken.

De cijfers zijn in elk geval ontnuchterend voor web developers. Zoals Craig terecht opmerkt: “Mobile connectivity and bandwidth continues to improve but it rarely jumps 30% in one year“. Dat betekent dat web ontwikelaars nog steeds veel te weinig “mobiel” denken, ondanks het sukses van smartphones en tablets!

Kortom: wie een web site laat bouwen of vernieuwen moet er zich van vergewissen dat de ontwikkelaars deze statistieken kennen – uw (mobiele) gebruikers zouden wel eens teleurgesteld kunnen zijn als de ontwikkelaars er niet de juiste lessen uit getrokken hebben…

En dus wens ik u voor het nieuwe jaar persoonlijke voorspoed en geluk, en hoop ik met u dat iedereen die bij de ontwikkeling van websites en apps betrokken is zich rekenschap geeft van het specifieke karakter van mobiele toepassingen!

(Oorspronkelijk gepubliceerd op mijn Engelstalige blog, op 30 december 2013)

Beter Versiebeheer Voor Content Management Systems?

Voor de meeste ontwikkelaars is de zaak duidelijk: je hebt een versiebeheersysteem (VCS = Version Control System) voor broncode en bijbehorende bestanden nodig, en dat VCS moet bij voorkeur worden geïntegreerd in je editor. Versiebeheer voor artikelen, blog posts, technische documenten, wetten, persberichten, romans, poëzie, handleidingen, etc. is vaak beperkt tot het opslaan van een versie van de tekst met een nieuwe naam waarin een tijdstempel of een volgnummer zijn opgenomen.

In ‘The Meta-Story: How Wired Published Its GitHub Story on GitHub‘ schrijven de Wired-redacteuren over hun eigen ervaringen met Git en GitHub. Voor een ontwikkelaar is hun conclusie niet zo verrassend: samen-schrijven is niet altijd eenvoudig, of het nu gaat om een tijdschriftartikel of een stukje programmacode. Je zou zelfs kunnen zeggen: “hoe meer (medewerkers), hoe rommeliger“! Vergis je niet: gedistribueerde versiebeheersystemen (DVCS) zoals Git en Mercurial maken het werk al makkelijker dan de oudere gecentraliseerde tools, maar zelfs dan zal het niet eenvoudig zijn – samenwerken gaat over mensen, en gereedschap kan het proces soms eerder belemmeren dat het te helpen.

Hoe dan ook, ik heb het hier over dit onderwerp omdat ik er sinds vele jaren van overtuigd ben dat een goed content management systeem (CMS) uitgebreide faciliteiten voor versiebeheer moet omvatten. Ik denk niet dat ik met woorden speel als ik zeg dat programmeurs hun source code (onder versiebeheer, natuurlijk) “publiceren” in een andere vorm. Die andere vorm  kan een gecompileerd programma of een code library zijn, of ondersteunende bestanden voor hun toepassingen. We zien hier enkele opeenvolgende fasen: opslag van de invoer onder versiebeheer, transformatie van de invoer, en publicatie. Merk op hoe die fasen zijn vrij gelijkaardig aan wat er gebeurt in veel content management systemen, met uitzondering van de woorden “onder versiebeheer”?

Jawel, tools zoals WordPress houden de historiek bij van de opeenvolgende versies van een bericht. Dat is OK voor een bericht op een blog – meestal verander je een blog post niet meer eens hij is gepubliceerd. Maar hoe zit dat met een document dat wordt geschreven door meerdere auteurs binnen een onderneming? In zijn bestaanscyclus kan een dergelijk document worden onderworpen aan een reeks bewerkingen die niet als een eenvoudige, lineaire lijst van opeenvolgende versies kan beschreven worden. Het antwoord op de vraag “Welke versie van het document diende als basis voor deze bewerking?” hoeft niet noodzakelijk de laatst bewaarde versie te zijn. Een DVCS kan alle informatie over parallelle en weer samenvloeiende versies op een compacte en veilige manier opslaan.

Wat ik voorstel is dus een samengaan van CMS en DVCS. Vraag me alleen niet hoe dergelijke tool er moet gaan uitzien in termen van de gebruikersinterface – CMS en DVCS zijn apart al ingewikkelde toepassingen, zodat hun samenvoeging wel eens een monster zou kunnen creëren dat niemand wil gebruiken!

Hebben alle huidige en toekomstige CMS deze injectie van DVCS nodig? Niet per se, want zoals wel meer gebeurt luidt het juiste antwoord: “het hangt ervan af” .

Neem blogging tools , bijvoorbeeld. Een blog is per definitie de uitdrukking van een (persoonlijke of groeps-) kijk op de wereld, en de commentaren op een blog post zijn een vorm van gesprek, en niet één enkel document. Voor blogs is de te volgen weg beschreven door Dave Winer (natuurlijk!) In zijn post “What kind of blogging do we want?: iedere schrijver heeft zijn of haar eigen gereedschap-met-repository, en een blogpagina met commentaar wordt dan opgebouwd door de ‘blog engine’ die de nodige stukken tekst ophaalt uit de repositories die deelnamen aan de specifieke discussie. Elk tool kan dan zelf beslissen of (en welk) versiebeheer het toepast, volgens de eisen of wensen van elke deelnemer.

Enterprise Content Management (ECM) systemen, aan de andere kant van het spectrum, hebben absoluut versiebeheer-voorzieningen nodig, en de bestaande ECM systemen bieden dan ook een vorm van versiebeheer aan. Maar de aangeboden functionaliteiten zijn meestal heel eenvoudig. Neem Microsoft SharePoint, bijvoorbeeld: het kent kladversies en finale versies, en het kan vele opeenvolgende versies opslaan, indien het daartoe geconfigureerd wordt. Maar SharePoint kent geen vertakkingen en geen samenvoegingen van versies, om maar die twee aspecten te noemen die elke doorgewinterde ontwikkelaar vaak gebruikt. Hier kan meer versiebeheer een zeer welkome aanvulling zijn.

Zullen ECM-leveranciers betere versiecontrolesystemen in hun produkten opnemen? We zullen zien…

Maar ik ben zeker niet de enige die de voordelen ziet van (gedistribueerd) versiebeheer in andere authoring tools dan software- ontwikkelomgevingen.

Lees bijvoorbeeld deze “Wish List for a Powerful Collaborative Writing Platform“, waarin auteur Konrad Lawson begint bij Github om te eindigen met een platform dat “.…would allow us to incorporate a variety of rich content hopefully without destroying our ability to work offline with most of our local materials when we have to“. En kijk ook naar Wired’s artikel “Donglegate Controversy Yields Only One Winner: GitHub“, dat erop lijkt te wijzen dat GitHub het niet erg zou vinden om deel uit te maken van een ECM-oplossing met veel meer versiebeheerfuncties dan er vandaag beschikbaar zijn.

Het zal interessant zijn om te zien hoe dit verhaal zich in de komende jaren verder ontwikkelt; sommige van de nieuwe “authoring tools” die ik een paar dagen geleden opsomde zouden zich wel eens heel goed kunnen ontwikkelen tot een instrument zoals Konrad Lawson het zich voorstelt.

(Oorspronkelijk gepubliceerd op mijn Engelstalige blog, op 4 november 2013)