Gou blog

L'idée n'est pas nouvelle, soit celle d'utiliser les bandes dessinées pour faire passer des messages ou bien donner de l'information. Smashing Mag a fait un article fort intéressant sur le sujet dernièrment.

J'ai alors pensé à un truc... Cette semaine, sur la liste des Webmestres, une collègue demandait:

[j'aimerais] savoir comment vous procédez pour faire connaître vos intranets à vos clients, plus précisément le personnel de vos organisations

Ok, où est le lien? ben... c'est peut-être un peu tordu, mais je crois que c'est le même problème dont il est question ici. Euh, un problème et une solution... mais bon, je ne dis pas qu'on devrait faire des BD dans les intranets, mais plutôt que... aarrggghhh! je vous explique.

Rendre le contenu intéressant et pertinent

Bon. Le nœud du problème, le cœur ou n'importe quel autre mot avec une ligature du genre (œ,je veux dire), c'est l'intérêt du contenu. Pas de contenu intéressant, personne ne va lire. Donc, si vous voulez que des gens lisent vos rapports long et fastidieux, assurez-vous de les rendre intéressants.

C'est là que la BD Intervient.

L'article de Smashing Mag présente comment faire une bande dessinée technique ou rendre un contenu lourd intéressant. La question de ma collègue est qu'elle veut que les gens aillent sur l'intranet ministériel et y reviennent. Pourquoi ne pas combiner les deux?

Donc, ce que je veux dire, c'est qu'il est possible de faire autrement que de diffuser de l'information lourde, textuelle, sans image, sans âme et de rendre le tout un peu plus ludique. Pourquoi pas?

Et oui, diffuser des bandes dessinées, ça peut donner un peu de vie à votre intranet. Un exemple tout simple, le soldat Chwinn, une BD qui paraissait dans le journal Adsum de la base de Valcartier. Je l'avoue bien candidement, c'était souvent pour cette raison que j'ouvrais le journal et le lisait... par la bande, je voyais aussi les autres articles.

La BD était l'élément accrocheur.

Un autre exemple. Combien parmi vous consultez régulièrement vos comics en ligne? Personnellement, j'en ai une série, que ce soit Dilbert, OOTS, XKCD ou d'autres que je vais lire dès que j'ai une notification dans mon agrégateur de RSS.

Pourquoi ne pas avoir quelque chose du genre dans nos intranets? Pas nécessairement une bande dessinée ou une carricature, mais plutôt un élément ludique, léger, qui nous donne envie d'y retourner et ainsi de voir des trucs nouveaux dans le site, par la bande (pas dessinée, celle-là).

Faire passer ses messages autrement

Bref, ce que je dis ici, c'est que je crois que, plutôt que de faire encore et encore du «push», de pousser l'information dans la gorge de nos utilisateurs d'intranets, en forçant des courriels de rappel ou en les obligeant à ouvrir Internet Explorer avec la page d'accueil de l'intranet par défaut, on devrait penser à l'élément accrocheur. Ce qui les fera revenir.

Certains la nomme la «Killer App», on pourrait dire aussi le «Killer Content». Et pour la loi 101, le «contenu tueur»... (ouf, pas le même effet...)

Aux détracteurs qui vont me dire que, dans le fond, un intranet, ce n'est pas ludique, c'est un outil de travail, bien je leur répond que c'est effectivement le cas. Je ne le nie pas, au contraire. Mais, généralement, une part de l'intranet est informationnelle, et on doit s'assurer que les employés y accèdent de temps en temps, au moins pour avoir un minimum d'infos. Rendez-leur la vie facile en rendant le contenu intéressant (et amusant?).

Vous verrez, il viendront d'eux même. Trouvez celui qui pourra faire la carricature de la semaine ou le Dilbert du ministère, vous allez voir la réaction!

La plus consultée d'un intranet est généralement le menu de la cafétéria... un peu triste, non? Faudrait changer ça...

Des fois, j'ai l'impression qu'on oublie de s'amuser au travail...

Comme vous le savez tous, bien entendu, il y a le GouvCamp la semaine prochaine, tout juste avant le Web à Québec, en partenariat avec celui-ci. Comme vous le savez encore, un camp, c'est un lieu d'échange, de discussion. Pas de conférencier, mais des participants. Ok, vous savez tout ça.

Donc, les gens arrivent et proposent des sujets divers, sujets dont certains ont été diffusés sur les profils Twitter et Google+ de l'événemnt. Étant l'organisateur, je n'ai pas été en mesure de proposer mon sujet, je me suis alors dit que je pourrais profiter de mon blogue pour en proposer un, et, pourquoi pas, étoffer un peu plus celui-ci...

Le partage d'information à l'intérieur de l'appareil gouvernemental

Bien que ce ne soit pas le sujet, mais que ça se rapproche, j'ai eu un petit sourire en coin lorsque j'ai vu le dernier billet d'Evollia ce matin, principalement parce que Nicolas a raison. Il est si difficile de se partager de l'information qu'il faut parfois faire des détours assez incroyables pour y arriver.

Comment arriver à échanger des informations entre-nous? Bien entendu, il existe, pour les gens oeuvrant dans le monde du Web, la liste des Webmestres, un outil datant de l'ère pré-numérique, alors que les iPad n'étaient encore que des tablettes d'argile. Mais ça marche, malgré ses limites. Je sais que certains ont des avis fort divergents sur cet outil, et je voudrais susciter le débat.

De plus, cette liste se fait régulièrement bombarder de questions du genre: « Avez-vous des exemples de politique éditoriale » ou « Je recherche des descriptions d'emploi de ... ». Bref, des sujets récurrents dont l'information gagnerait à être disponible à tous, en tout temps, et dans un lieu commun.

Ainsi, outre cette liste, plusieurs personnes ont créé des fichiers Google Docs publics ou privés, pour permettre de règler ce fameux problème. Des documents qui deviennent publics (avec de l'info publique, bien entendu) et qui sont maintenus tant bien que mal par tous. Des erreurs peuvent s'y glisser, l'information peut être modifiée par des personnes sans aucun rapport avec le sujet. Ce n'est pas toujours l'idéal, mais, encore une fois, ça marche malgré les lacunes.

On retrouve aussi des groupes publics ou privés, par exemple, sur Yammer ou LinkedIn pour faciliter les échanges. Encore une fois, ce sont des éléments pour pallier à un manque cruel d'outils internes, mais ça marche. Nous prenons des détours et utilisons ce qui est à notre portée pour arriver à échanger de l'information entre-nous.

Quelle est la solution?

J'en ai fichtre aucune idée. Il y a un besoin, et il est grand. Il peut se résumer ainsi:

Les employés de l'état ont besoin de se communiquer entre-eux, de façon horizontale, sans barrières.

La seule chose que je puisse dire, c'est que la solution n'est pas dans la censure ou le blocage.

Voilà. C'est le sujet que je veux apporter au GouvCamp 2013, en souhaitant une discussion intéressante sur le sujet.

Les intranets, rien de bien nouveau là dedans... En tant que stratège Web au gouvernement, on ne cesse de nous en demander et on en voit de toutes sortes. Or, on commence [enfin] à voir une certaine évolution dans la demande. Malgré tout, est-ce que les clients sont conscients de ce qu'ils demandent?

Le 7 janvier dernier, nos amis de Nielsen Norman Group ont publié leur rapport annuel sur les meilleurs intranets, mouture 2013 cette fois. Intéressant à regarder, je n'irai pas beaucoup plus loin, je vous laisse voir le résumé (je ne payerai pas pour la grosse version, ne vous déplaise).

Ce qui attire mon attention est principalement le constat sur le temps de réalisation. Faire des intranets efficaces requiert en moyenne 42 mois, soit 3 ans et demi! Vous comprendrez que les demandes que l'on reçoit sont souvent limitées par les années budgétaires, donc on a quelques mois pour faire un intranet. Le résultat peut s'en ressentir.

Augmentation de la taille des équipes intranet en pourcentage du nombre total d'employés (2001-2013)

Les équipes de travail pour les intranets ont aussi grossi. C'est la tendance la plus importante, selon moi. Les entreprises (et souhaitons, les organisations gouvernementales), commencent à comprendre qu'un intranet efficace, utile et pertinent, ça nécessite une équipe de travail. On calcule actuellement 1.4 membre de l'équipe intranet par 1000 employés. Faites le calcul pour votre organisation.

Et les tendances?

Maintenant, je vais vous faire mon propre petit constat, en lien direct avec ce que je vis au quotidien. Pas d'études, pas de chiffres, mais plutôt des impressions: on arrive enfin dans le 21^e siècle!

Les clients nous demandent de plus en plus des intranets collaboratifs, des lieux où on retrouvera des outils pour les employés et non plus des petits journaux internes en format électronique.

On va nous demander des «Facebook internes», du Web 2.0, du Entreprise 2.0 ou des outils collaboratifs. Ok, plein de beaux buzzwords, mais rares sont ceux qui savent vraiment ce que ça implique.

À cet effet, je me permet de mentionner que Yann Sadok fera justement une petite présentation sur le sujet au Web à Québec...

Revenons à nos moutons. Les clients sont-ils prêts? Dans la majorité des cas, non. Euh... ils ne sont jamais prêts en fait.

Faire du collabo-web-deux-zéro-facebooko-intra-entreprise-deux, c'est pas aussi facile qu'on le croit à priori. Le premier obstacle, c'est la croyance que tous vont participer et pousser du contenu et collaborer. La belle affaire.

Vous connaissez la règle du 90-9-1? 90% des membres de votre superbe réseau interne ne vont être que des spectateurs. 9% va contribuer de temps en temps et un gros 1% des utilisateurs seront vos leaders. Sur 300 employés, ça fait 3 personnes. Sur 3000, ça fait 30 (ouf! déjà mieux!).

Considérant qu'on me demande souvent des sites collaboratifs pour des organisations entre 50 et 1000 personnes, ça fait pas beaucoup. Oui, oui, je sais, il y a des exceptions, comme MEC qui s'en vante sur le site de ThoughFarmer., mais ça demeure des exceptions.

Il y a aussi l'ouverture à la critique, aux possibles dérapages et comment gérer ces éventuelles «crises» internes. L'organisation doit être en mesure d'accepter ces risques et le meilleur moyen, selon moi, est d'y aller par étape, soit de commencer avec un blog interne, par exemple, sur lequel les commentaires sont activés. On ajoutera une fonction de «like» dans les pages, puis on verra...

Bref, la partie est loin d'être gagnée pour ces intranets nouvelle version. Encore beaucoup de pain sur la planche, et je ne vous parle pas de technologies, là! Je ne veux même pas y penser!

Oui, mais, c'est quoi les tendances, à la fin!

Ah. C'est vrai, je voulais parler de tendances...

Dans les faits, je crois que la tendance principale, pour nos organisations, sera de tenter de mettre en place des outils collaboratifs, comme des groupes de travail, des systèmes de gestion documentaires et des outils d'aide à la tâche.

«Bah, que vous vous dites. Rien de bien nouveau là dedans». En fait, la nouveauté réside dans le fait que ça se réalisera. Contrairement aux tentatives infructueuses du passé, cette année, nous allons voir de véritables réalisations. Seront-elles des échecs? Je souhaite que non.

Il y a un besoin énorme, qui provient de la base, qui veut partager ses connaissances. On a vu des groupes LindedIn, Yammer ou autres se former en 2012 pour échanger, faute d'outils fournis par les organisations. Suite au rapport Gautrin, il y a eu une consultation en vue de créer un genre de LinkedIn interne au gouvernement. Le besoin est là, c'est la base qui le pousse. Reste à voir si les hautes instances vont aller dans le même sens.

Je le souhaite. Ardemment.

Eh oui, la version 6 de TYPO3 est sortie! On pourrait dire qu'il était temps ou bien... attendez, là... la version 6?? on était pas à la 4.7???

Oui, c'était bien la 4.7... et, pour nous, la 4.5, car c'est la LTS. Donc, avec la 6, on a sauté une version?

Non, justement, la version 5, c'est Phoenix... euh, non, Neos. La future version de TYPO3, qui ne sera plus TYPO3... ah... bon... donc, TYPO3 ne sera plus TYPO3... ben, pas tout à fait!

Si vous y perdez votre latin, bienvenue dans le club! TYPO3 est en train de vivre de gros changements, principalement avec sa [plus ou moins] nouvelle plateforme Flow. Ce que ça veut dire, en clair, c'est que nous, utilisateurs de cette plateforme, on doit faire une sérieuse réflexion sur l'avenir de nos sites!

Ainsi, voici ce que moi, pauvre petit utilisateur de TYPO3 je comprends de ce qui se passe (c'est ma compréhension, hein, soyez indulgents!):

• TYPO3 4.5, la version LTS du produit, celle qui devrait être supportée assez longtemps pour survivre... du moins, on l'espère, jusqu'en 2014 (quoi qu'aucune date ne soit indiquée) est celle qui est privilégiée par les organisations qui veulent de la stabilité;
• Les versions subséquentes de TYPO3 4.x, des versions améliorées qui incluent, entre autre, du support de HTML5; C'est l'évolution normale du produit et des améliorations continues, parfaite pour une évolution et profiter des nouveautés.
• La version (ou branche) 6, qui est une amélioration du produit 4.x et l'ajout de plein de trucs. Super. Présentement, pour les téméraires. Il semblerait que le passage 4.x vers 6 soit possible et faciliterait le passage vers le prochain.
• La version Neos, qui, elle est basée sur Flow, une toute autre façon de fonctionner et qui, si je comprends bien, n'est pas rétrocompatible avec les versions 4.x. La v6 semble faire le pont entre les deux mais devra probablement nécessiter du travail. Bref, un autre CMS, tout simplement...

Que faut-il en conclure?

Sacrée bonne question. Je travaille pour une organisation qui gère une vingtaine de sites TYPO3 4.5. Déjà, installer un TYPO3 6 et le tester risque de prendre un certain temps et faire une conversion n'est pas vraiment dans les cartons. On devra se positionner sur l'avenir de nos sites. Devrons-nous:

• Conserver nos sites en TYPO3 (4.x vers 6 ou rester avec une ancienne version)
• Passer à Flow - Neos et convertir nos sites (va-t-il y avoir des convertisseurs? Quel sera l'impact? le passage TYPO3 4.1 à 4.2 a déjà été assez pénible à l'époque...)
• Regarder un autre produit CMS...

Aucune décision n'est prise, trop peu d'information est encore disponible et il faut mesurer les impacts de ces trois options avant d'aller plus loin. Tout ce que je peux souhaiter, c'est que nos amis de TYPO3 s'empressent à nous expliquer ce qui se passe clairement.

On dénote déjà des efforts depuis quelques mois, et c'est apprécié. Malgré tout, il reste une confusion, principalement sur Neos, qui demeure un produit nébuleux.

Je n'ai nullement envie de vous faire paniquer ou vous dire de quitter le navire, mais je crois qu'un utilisateur de TYPO3 averti en vaut deux!

Aujourd'hui, je suis tombé sur ce billet qui décrie le Responsive Web design et ses problèmes. Je ne suis pas en accord complet avec ce texte, mais je dois dire que le commentaire de Raphael Goetter m'a au moins rassuré...

• si on veut une interface idéale pour chaque device (autant ergonomique que performante), il faut bien traiter un par un tous les devices. Si on en a le temps et les moyens, pourquoi pas. Et ensuite s'amuser à les maintenir. Et aussi ne pas oublier d'ajouter tous les nouveaux venus tels que l'iPad mini.
• dans tous les autres cas, le Responsive Web Design est une solution qui cumule de nombreux avantages (le premier étant "au moins c'est lisible"), sans atteindre la perfection en effet.

Tout d'abord, il faut savoir que le RWD n'est pas la panacée, ce n'est pas une fin en soi, mais bien un moyen pour permettre un affichage décent du contenu sur des écrans plus petits, du moins, en résolution. J'en conviens, ce n'est pas toujours l'idéal, mais ça fait le boulot pour bien des projets.

Dans le billet, on mentionne l'exemple du iPad mini, qui a une résolution semblable à celle du iPad régulier, et un écran plus petit. Ça peut effectivement causer problème, car l'ensemble sera plus petit, mais semblable. Je rappelle que l'on conçoit des sites pour que ça s'affiche convenablement, pas parfaitement.

Imaginez maintenant le même site affiché avec une approche de site dédié, alors cette fois, il sera semblable sur les deux appareils, mais vu comme sur un iPhone. La joie. Le RWD est un entre deux convenable. Faire une application? euh...

Problèmes de performance?

On mentionne le problème de performance, le fait de pousser des images haute résolution alors que le réseau peut être boiteux ou faible débit. Eh ben, on a le même problème peu importe que l'on soit en RWD ou non.

La performance, l'optimisation d'une page devrait se faire peu importe le type d'appareil utilisé. Trop souvent on prend pour acquis qu'une personne avec un ordinateur ou une tablette haute résolution peut accepter des pages plus lourdes... vous n'avez qu'à tester le réseau sans fil dans les autobus OrléansExpress pour désirer de la performance des pages, peu importe votre qualité de machine!

L'approche hybride du RESS est une partie de solution, mais de bien concevoir le site à la base en prenant encore la performance en considération dès le départ devrait demeurer un «must», quitte à offrir des images plus haute résolution à la demande, pourquoi pas?

Bref, je pense que l'on s'attaque à la mauvaise cible. Le RWD est un outil de plus dans notre arsenal de designers de sites Web. Il doit être utilisé selon les besoins et les objectifs du site et du client, au même titre que l'application native ou le site dédié.

Et le Mobile First...

J'ai aussi vu passer un commentaire au sujet du Mobile First, en opposition au RWD... et j'ai eu un désaccord avec Denis Boudreau (sans rancune, j'espère!) car, contrairement à lui, je perçois le Mobile First comme une philosophie plus qu'une technique...

Le fait d'aborder un site et d'orienter son développement en fonction de l'utilisation sur mobile en premier, de prendre ces besoins en considération va nous mener à faire des choix qui alors nous guideront des techniques appropriées.

Par exemple, en considérant les besoins de mobilité, les besoins de mes utilisateurs, les budget, les contraintes et tout ce qui suit, je ne vois pas comment une organisation gouvernementale pourrait arriver à proposer une application native au lieu d'un site en RWD bien conçu. J'ai même de la difficulté à considérer l'option d'un site dédié.

Le RWD n'est pas la solution ultime ou idéale, mais c'est souvent mieux que rien du tout. Et des sites en RWD mal faits, il y en a des tonnes, malheureusement.

En attendant que de nouvelles solutions encore plus poussées nous soient offertes (et accessibles dans nos outils), je crois que ça fait bien le boulot. Et non, le RWD ne convient pas à tous...

Chers lecteurs (si! si! au pluriel!), je ne vous néglige pas... du moins, j'essaie. La période estivale m'a légèrement éloigné de mon cher clavier, ce qui ne m'a pas empêché de pondre un nouveau billet sur le blogue de E-Gouv Québec!

Effectivement, aujourd'hui je signe «Faire des sites Web pour mobiles – Deuxième partie: Quelles sont les options techniques?». C'est la suite de mon premier billet sur le sujet, soit: Faire des sites pour mobiles – première partie: Pourquoi faire des sites pour mobiles?.

Et n'ayez crainte, le 3e volet suivra prochainement. Grâce au travail fait dans les dernières semaines, je pourrai agrémenter l'article de la réalisation d'un projet gouvernemental en responsive Web design. Yé!

De plus, l'automne s'annonce chargé, beaucoup de projets parallèles avec E-Gouv Québec. Il y a le 5 à 7 en octobre, mais d'autres trucs en gestation. J'ai bien hâte que ça avance un peu pour pouvoir vous en parler!

Bref, il s'en passe des choses au gouv à Québec... du moins sur le Web!

Dans le cadre d'un projet, j'en suis à créer une interface pour un site mobile. On fait le tout en responsive Web design, bien entendu (je ne pouvais pas me permettre de passer à côté, hein?), et voilà que j'ai un dilemme. Une interrogation majeure. Une question existentielle qui me turlupine:

De kossé je fais avec le cibole de lien «haut de page» en Responsive Web Design?

C'est une question qui peut, au premier abord, sembler assez simple à répondre, mais quand on creuse, on se rend vite compte que ce n'est pas le cas.

J'aime pas les «haut de page»

Tel le on-ne-peut-plus-sympathique Schtroumpf Grognon, je n'aime pas les liens «haut de page». J'ai toujours trouvé que c'était une nuisance inutile, un truc qui ne sert à rien dans une page. On infantilise l'utilisateur en lui simulant des fonctions qui, de toutes façons, sont déjà disponibles dans le fureteur (vive les scrollbars).

Ceux qui me connaissent savent ma réticence à prendre l'utilisateur par la main et lui offrir des béquilles lorsque des outils sont déjà en place. Prenons les fameux liens de grossissement de caractères dans certaines pages, ou un lien «imprimer». Même combat.

Bon, outre le fait que je ne les aime pas, que devrions-nous faire, finalement?

Les faits, s'il y en a...

Avez-vous déjà fait une recherche sur «back to top» dans Google? La joie. Je tiens à vous rappeler que moult sites possèdent de tels liens, alors, on n'y trouve rien. Des sites d'influence qui ont des liens «back to top» dans leurs pages. Génial.

J'ai tout de même réussi à dénicher quelques articles, dont un de Jakob Nielsen, un classique: il est contre (lui aussi). La raison est simple, c'est un comportement compris des utilisateurs qui vont plutôt référer à la bonne vieille barre de défilement pour remonter dans la page.

Il existe aussi des raccourcis clavier qui font le même travail, comme le bon vieux bouton «home». Pas besoin de cliquer quelque part. Les souris sont maintenant munies d'une roulette de façon généralisée, ce qui facilite la ballade verticale dans la page!

Ok, les articles datent un peu. Des design patterns? Welie en parle, mais j'ai trouvé cet article plus parlant, où on mentionne qu'on devrait dire «début de la page» à la place...

Tant qu'à y être, pourquoi ne pas en regarder de jolis modèles? À défaut d'être utiles, ils sont beaux!

En discutant avec un collègue, ce dernier m'a indiqué que, dans le fond, puisque ce n'est pas compliqué à mettre en place (un petit code et le tour est joué), ça ne coûte pas cher, on le met et c'est fait. Point. Mais on risque alors d'arriver à des aberrations, comme des textes remplis de «haut de page» qui se succèdent, dans un espace restreint...

Un exemple de proximité de plusieurs liens «haut de page» dans un site... et ça se répète tout au long de la page!

Maintenant, qu'en est-il sur mobile? iOS offre le «back to top» nativement. Je n'ai pas pu reproduire le comportement sur mon Nexus One avec Android 2.3... peut-être ICS a ajouté cette fonctionnalité. À confirmer.

Le dilemme...

Vous allez dire que je fais tout un plat de pas grand chose, et vous avez probablement raison. Qu'est-ce que ça peut bien changer de mettre un lien «haut de page» dans un site? dans le fond, j'ai même dit que ça ne coûtait pas cher!

Je tiens à rappeler que mon problème, c'est quand on transpose le site sur mobile:

• L'espace est limité (surtout sur un téléphone);
• Le lien se répète souvent, sur un petit écran, et risque de nuire visuellement;
• L'utilisateur peut facilement remonter en donnant un petit coup de doigt ou, sur iOS, taper sur la barre du haut;
• Il y a un risque de clic indésirable, ce qui ramènerait l'utilisateur au haut de la page et risque de créer une confusion inutile, déjà que la navigation mobile n'est pas toujours facile...

Alors, on fait quoi?

Voilà des propositions:

• On le garde pour de très très longues pages, sur un site régulier;
• On peut conserver les haut de page dans le bas de la page (mobile ou non), surtout lorsque l'on utilise une navigation de pied de page sur un site mobile;
• On élimine les liens haut de page, sur les visuels destinés aux mobiles puisque des fonctions de base des appareils permettent de remonter au haut de page et l'interaction au toucher facilite la navigation;
• Finalement, on installe des suivis d'événements (event tracker) sur les liens de haut de page et on mesure leur utilisation réelle sur les sites réguliers et mobiles.

Que pensez-vous de ça? est-ce une bonne idée? Ok, je sais, on s'en fout un peu, personne ne va taper sur des casseroles pour défendre le lien de haut de page, mais bon... je voulais tenter d'avoir une réponse à ma question...