Du renouveau pour mon blogue

Je profite d’une période de changement entre deux emplois (détails à venir prochainement) pour faire un peu de ménage dans mon blogue et je quitte la plateforme Blogger pour enfin aller sur un site auto-hébergé, en WordPress. Ça ne change pas grand chose pour les lecteurs, outre un bri des liens vers les anciens billets et un changement obligatoire du fil RSS.

J’étais limité par la plateforme Blogger et j’envisageais depuis longtemps de faire le déplacement. Manque de temps, de volonté ou simplement enfin la possibilité de le faire, voici que je viens de terminer le transfert. Que de maux de têtes. L’air de rien, jouer sur les DNS et les noms de domaines, les configurations de WordPress et tout le reste, ce n’est pas ma tasse de thé.

Malgré tout, je suis assez satisfait du résultat. C’est fait et je vous invite à me laisser des commentaires, si vous en avez!

Des outils pour créer votre première application Android

Édition: Mise à jour du 10 septembre 2014, de nouveaux outils ont été ajoutés suite à l’essai d’une nouvelle approche de développement

Nous commençons, dans mon équipe, à regarder la possibilité de développer des applications Android et iOS. C’est tout à fait logique, puisque nous avons déjà ciblé des besoins de certains clients. Ainsi, le premier travail que nous désirons faire est de créer une application qui encapsule un site Internet avec quelques fonctionnalités natives de l’appareil. Rien de bien compliqué en soi.

Ainsi, un collègue et moi travaillons à mettre en place des solutions de développements pour applications mobiles Android. Pas très stressant, vous pourriez dire. Après tout, on installe Android Studio et ce qui vient avec, on configure et hop! c’est parti! Eh bien, non, ce n’est pas toujours si simple…

nous travaillons dans une grosse organisation gouvernementale et nous n’avons pas toutes les latitudes que le possesseur d’un poste de travail personnel peut avoir. Ainsi, nous devons nous assurer que les outils que nous allons utiliser seront adaptés à nos environnements.

Un autre défi auquel nous faisons face est le manque criant à l’interne de développeurs pour iOS (objective C) ou Android (Java). Nous devons donc apprendre le fonctionnement des divers environnements et langages en même temps que les méthodes de développements d’applications. Je suis privilégié d’avoir eu, dans mon passé récent, une expérience assez bonne avec l’environnement de développement Java. Une chance, sinon je n’y comprendrais rien.

Note aux amateurs de la pomme: je ne parle ici que de développement d’applications Android, mais sachez que des situations semblables ont été rencontrés du côté de iOS et que mes collègues travaillent aussi à mettre en place des solutions de développement pour que nous puissions faire des apps pour vos appareils. Non, vous ne serez pas en reste, ok?

Autre petite note: Si je partage ici les informations recueillies, c’est parce que je crois que ça peut servir à des collègues qui, eux aussi, en sont à leurs premières armes en ce qui a trait au développement d’applications Android. J’espère ainsi pouvoir aider d’autres personnes en le faisant. En aucun cas mon opinion se veut pour ou contre quoi que ce soit, je tente de garder une certaine neutralité…

Le défi: faire une application qui affiche Hello World!

Mon collègue et moi avons donc regardé diverses avenues, et pour arriver à faire son Hello World, il a rapidement renoncé à utiliser les appareils du bureau et s’est rabattu sur une solution impliquant son ordinateur personnel. J’ai décidé de reprendre là où il avait dû s’arrêter pour réussir à faire, moi aussi, un Hello World, mais cette fois en utilisant les capacités et limitations du contexte de travail.

Il faut d’abord comprendre que je n’ai pas de droits d’administration sur mon appareil, comme n’importe quel employé d’une grosse organisation. On me fournit une machine viruelle (Windows XP) pour le développement, sur laquelle j’ai les droits… et des accès Internet un peu plus poussés. Une chance!

Je vais donc exposer ici mon parcours du combattant et présenter les diverses solutions qui sont offertes actuellement sur le marché pour développer des applications Android. Attachez votre tuque avec de la broche, c’est pas toujours facile!

Les contraintes

Tel que mentionné plus haut, je travaille dans un environnement sécurisé avec beaucoup de contraintes techniques: postes barrés, Internet contrôlé, accès limités… Bref, le cas typique du travailleur du gouvernement ou de la grosse entreprise. Ces contraintes sont majeurs pour les équipes de développement car plus souvent qu’autrement, notre travail nécessite d’avoir un contrôle total sur la machine et un accès complet à Internet.

C’est pourquoi on nous fournit des machines virtuelles normalisées. Celles-ci ont un accès quasi complet à Internet et j’ai les droits d’administration. Ceci dit, ce n’est pas rose non plus. Ce sont des machines virtuelles, pas des machines physiques. On retrouve donc plusieurs limitations, outre celles des performances (on pourrait probablement allouer plus de puissance, mais dans le cas présent j’ai une machine standard) et on a de la difficulté à configurer certains trucs, comme le USB (j’en parle plus tard).

Bref, c’est le topo. Maintenant, comment arriver à développer des applications Android dans ce contexte? Voici trois options qui ont été regardées…

Les solutions testées

Mon collègue avait déjà essayé Android Studio sur sa machine virtuelle du bureau et ça avait été un échec. J’ai donc commencé à regarder d’autres alternatives qui pourraient nous servir et c’est pourquoi je commence avec deux solutions différentes…

Codenvy

Codenvy.com est un site Internet qui comporte un IDE en ligne (SaaS) pour le développement sur diverses plateformes ou technologies. Il existe un module spécifique pour Android.

J’ai fait le premier test tout simple, la version publique disponible sur leur site. En 30 secondes (j’ai un témoin), j’ai réussi à faire un Hello World! J’ai pu télécharger le fichier APK, l’installer sur mon téléphone. Un succès sur toute la ligne!

La preuve que j’ai réussi! J’ai seulement changé le texte de l’application de base, l’ai téléchargée et installée sur mon téléphone. Voilà!

Ça a commencé à se gâter quand j’ai créé mon compte sur le site (l’utilisation de Codenvy est gratuite) et que j’ai fait mes premiers projets. J’ai essayé de configurer un «repository» autre que celui de base (je me suis créé un GitHub), j’ai voulu m’assurer que mon code ne serait pas «buildé» dans l’environnement public de Codenvy… sans grand succès. Mais ce n’est pas tout. Quand vient le temps de tester l’application, il faut faire affaire avec un outil externe d’émulateur Android, Manymo.

Le produit semble excellent et fort pratique, mais il n’est pas gratuit, il faut payer…

Finalement, en consultant le tutoriel Google pour la création d’applications Android, j’ai vite déchanté. On retouve des fonctions dans Android Studio qui ne sont pas offertes dans le IDE de Codenvy. Bien que tout soit possible de façon manuelle (comme le «add activity»), c’est beaucoup plus complexe et, vu notre niveau de connaissances dans le domaine, un peu d’aide de l’interface n’est pas de refus….

Bref, bien qu’une solution fort pratique, efficace et adaptée pour certaines organisation, dans notre contexte, elle perd de son charme. On se rend bien compte que Codenvy ne permettra pas de répondre à nos besoins internes. Peut-être que la solution plus étoffée, ultérieurement, pourra être à envisager, mais malheureusement pas à court terme.

J’ai donc dû continuer à investiguer pour d’autres solutions…

PhoneGap

Avant d’aller plus loin, je tiens à rappeler que notre principal objectif, pour nos premières applications, est de créer une coquille qui encapsule un site Internet mobile et qui permet d’utiliser certaines fonctions natives de l’appareil. J’ai donc fait des recherches en ce sens. Ce qui m’a mené vers Phonegap.

Le fonctionnement de Phonegap est complètement différent de Android Studio ou autres. C’est en fait un serveur Web qui roule dans un application et qui permet de faire fonctionner un site HTML-CSS-JS local. Bref, exactement ce que je voulais (ou à peu près). J’ai donc commencé à regarder de ce côté.

La beauté de cette solution, c’est que les applications sont développées en HTML-CSS-JS, des technologies maitrisées par notre équipe, et on ne fait que les encapsuler dans PhoneGap. Encore mieux, l’outil est hybride et permet la création d’applications iOS ou Android! Bref, une belle idée. Elle existe en plusieurs «déclinaisons», dont une version, disons, lignes de commandes, et une autre qui a été mise en place par Adobe. J’ai essayé les deux.

PhoneGap installé sur ma machine virtuelle

Tout d’abord, je dois dire que c’est assez… aride, comme outil. Le retour de la bonne vieille ligne de commande! Il faut commencer par installer Node.js, puis on lui passe des commandes pour installer PhoneGap. Ça se passe généralement bien, en autant que nous ayons les droits d’administration sur le poste. J’ai donc tout fait sur ma machine virtuelle.

L’installation se fait relativement simplement, c’est à l’utilisation que ça se complique…

Une fois la commande intstall complétée et create faite, ça commence à se gâter. Je n’ai jamais réussi à faire le run android, la fonction qui me permettrait de créer l’application Android. Pourquoi? j’obtiens une erreur avec Ant, un outil qui permet de «builder» des applications.

Oh, je vous vois venir, petits coquins… vous allez me dire: «Ben voyons! c’est parce que tu n’as pas configuré tes variables système, pauvre cloche!». Ce à quoi je répond: «Non, mais, vous me prenez pour qui, hein?». Bien entendu que j’ai configuré les variables d’environnement, tsé. Hein. (Me semble, ouais! pfff! Sans blagues… continuez comme ça et je m’en vais!)

Euh.. bon… ok. J’en étais aux variables d’environnement, hein… Donc, Ant ne fonctionne pas. J’ai configuré les variables d’environnement comme il se doit, mais je suis incapable de faire fonctionner le tout sur la machine distante. Pour fin de comparaison, j’ai fait le même exercice sur ma machine physique et, cette fois, la commande s’exécute sans problème et me donne une erreur, qui était attendue (puisque c’était seulement un test, Ant répond en me signalant une erreur – sur la machine virtuelle, Ant n’est même pas reconnu).

Dans la portion du haut, on voit que la commande ant n’est pas reconnue par le système, or, sur ma machine physique, qui possède les mêmes configurations de variables d’environnements, la commande s’exécute et donne l’erreur attendue.

J’ai cessé les recherche à ce moment, un peu découragé. Je me suis tourné vers la version Adobe.

PhoneGap Build version Adobe

Adobe offre une solution de création d’applications encapsulées par Phonegap build. Je me suis donc branché, j’ai créé un fichier HTML tout simple avec un «Hello world» en H1, «uploadé» et, zou! j’avais une application Android (j’aurais pu la faire iOS ou BlackBerry ou même Windows si je voulais… Il ne me manquait que les clés nécessaires).

J’ai eu plus de succès avec la version Adobe, puisque j’ai réussi à créer une «application» en quelques secondes. Un fichier HTML avec un H1 qui dit «Hello World», encapsulé dans l’application.

Ouah! ça c’est efficace! Une minute à peu près et j’avais fait mon Hello World! Mais il devait y avoir un petit quelque chose de travers, non? Eh bien oui. L’application, à l’installation, me demande TOUTES les permissions. Il faut accepter qu’elle puisse accéder au micro, appareil photo, GPS… Bref, un peu exagéré…

Quelle ne fut pas ma surprise de voir le nombre d’autorisations requises, pour un simple fichier HTML encapsulé! Et ça va plus bas en plus!!

Ok, probablement que ça se change, via une configuration ou autre, j’ai pas poussé plus loin. Une autre raison c’est que ça ne satisfaisait pas le besoin initial, soit d’encapsuler un site Internet qui, lui, ne serait pas local. Il ne m’était pas possible de prendre le site et l’envoyer dans le truc Adobe. Bref, encore un dead end.

Ça peut tout de même servir pour certains trucs, ça reste à voir!

Android Studio sur une machine virtuelle

Bon, eh bien, me voici revenu à la case départ. Je devais reprendre là où mon collègue avait jeté la serviette et essayer de faire fonctionner Android Studio sur ma machine virtuelle.

Ironiquement, c’est relativement simple à faire. On installe Android Studio, on le démarre, pour se rendre compte qu’il manque le JDK, qu’on va aussi installer… On redémarre Android Studio, pour apprendre à nouveau qu’il faut installer le Visual C++ 2010 service pack 1 parce qu’une DLL est absente. Joie. Bon, on peut commencer maintenant?

Oui, c’est possible. Enfin. Donc on configure le SDK, on ajoute des émulateurs via le Android Virtual Device manager et, là, on est prêt à se lancer dans le vide en suivant le tutoriel.

Oui, ça fonctionne. Je suis capable de faire des trucs, rouler une application et jouer sur les configurations, mais c’est d’une lenteur exécrable. Les émulateurs sont instables, quand ils fonctionnent… Il faudrait allouer beaucoup plus de ressources à la machine virtuelle pour que ce soit fonctionnel, mais bon, ça peut marcher… jusqu’au moment où on veut gérer un appareil physique…

Basic4Android (basic for android)

Une nouvelle famille d’outils se sont joints à l’arsenal du développeur pour nous permettre de rapidement mettre en place des solutions mobiles, soit Basic4Android, un outil de développement sur Windows qui utilise le SDK Android et qui traduit les commandes Basic en éléments propriétaires pour la plateforme mobile.

Je dois dire que je ne suis pas un spécialiste, ni de Java, ni de Basic (ça va mal, hein?), mais il semblerait que ce soit une solution prometteuse. Surtout qu’il existe le pendant pour Java, B4J, qui fonctionne sur le même principe et qu’une solution pour iOS est dans les cartons. Bref, une idée qui a un certain charme, surtout lorsque le personnel de l’équipe connaît Basic et .Net, mais pas Java!

Des premières preuves de concept ont été faites et ça semble fort prometteur. Nous n’avons utilisé que la version gratuite (démo) pour l’instant, ce qui ne nous permet pas de pousser à fond l’utilisation de certaines librairies qui ne sont pas disponibles pour cette version (ex. Google Maps), mais on a déjà des éléments de Back-end et de Front-end qui fonctionnent.

Les écueuils

On a vu, tout au long de mes expérimentations, que j’ai vécu des désagréments à plusieurs niveaux. À certains moments, c’était purement technologique, d’autres fois, presqu’idéologique (comme les permissions). Aucune solution ne semble meilleure qu’une autre jusqu’à maintenant.

«Oh, mais la solution avec Android Studio sur la machine virtuelle, c’est correct, non?» vous entends-je dire. En fait, j’y viens à l’instant.

Brancher un appareil en USB

Une des particularités du SDK Android, c’est qu’il nous permet de gérer un appareil physique (téléphone ou tablette) par le biais du port USB de notre ordinateur. C’est via les commandes ADB qu’on peut le faire. C’est d’ailleurs grâce au SDK que j’ai déjà réussi, il y a quelque temps déjà, à installer CyanogenMod sur mon Nexus One. Pas facile au premier abord, mais franchement utile (surtout que le bouton on/off de mon appareil venait de rendre l’âme…).

L’autre utilité est de pouvoir tester une application en développement sur l’appareil physique plutôt que sur un émulateur. Ça peut donner des résultats surprenants (on l’a bien vu lors de tests d’utilisabilité).

Voilà donc que le problème se pose avec une machine virtuelle. Celle-ci n’est pas en mesure d’accéder au port USB de l’appareil qui appelle la machine distante (car elle est sur un serveur distant, hein, je ne vous l’avais pas dit celle-là!). Ça règle la question: pas de ADB sur USB.

Quand vient le temps d’installer le SDK sur mon poste physique, ça fonctionne après plusieurs étapes dont je vais vous faire grâce, mais impossible d’installer le pilote de la tablette ou du téléphone… je ne suis pas administrateur du poste.

Je tourne donc en rond. Encore.

C’est là que Basic4Android vient ouvrir une porte intéressante, soit l’opportunité d’utiliser une connexion Wifi pour communiquer avec un appareil physique, soit une solution ADB over Wifi. Ok, ça nécessite que les deux appareils soient sur le même réseau Wifi, on devrait être capable… reste qu’avec une machine virtuelle, il va falloir faire quelques tests encore.

Conservation du code source

Dans les solutions en ligne, telles que Codenvy et Adobe PhoneGap, un problème assez important est la propriété du code source, là où sont déposés les builds, ce qui se passe avec… bref, encore des problèmes à régler.

Nous avons un GIT interne pour nos développements, mais il n’est pas accessible de l’externe… et est-ce une bonne idée? Une passerelle? une autre solution? Ça reste à explorer… nonobstant les autres problèmes rencontrés.

Lenteur de la VM

Bien que la solution de la VM soit à peu près viable si on exclut l’accès au USB, il n’en demeure pas moins qu’elle présente un gros problème de lenteur. Au point où chaque clic de souris prend de une à trois secondes avant que l’action se passe. Ça empire dès lors où je commence à entrer des commandes ADB.

Un test avec une VM plus puissante donne des résultats semblables. Peut-être est-ce simplement lié au fait que ce ne sont pas des machines physiques. Nous avons d’ailleurs eu un problème avec les émulateurs, qui nécessitent des accélérateurs ou des accès au processeur, ce qui n’était pas possible sur la VM. Bref, des performances à valider.

En conclusion

Note: suite au test de Basic4Android, j’ai dû revoir ma conclusion 😉

Quelle est la meilleure solution? Actuellement, aucune. Il n’est pas possible de développer des applications Android présentement avec les ressources actuelles. Nous avons mis en place des solutions alternatives grâce aux équipes sur le plancher, mais elles sont embryonnaires et nécessitent plus de tests. je dois dire que nous regardons très fort du côté de Basic4Android et de B4J. Il devient donc possible d’envisager la création d’applications Android avec une équipe qui n’est pas spécialiste Java et avec des machines virtuelles.

Bien entendu, une telle solution a tout de même de grosses limites. Nous devrons tout de même nous assurer de développer des connaissances internes dans les divers langages utilisés, ne seraita-ce que pour régler des bugs et nous assurer d’une performance des applications développées.

Donc, à court terme, nous allons pousser plus loin de ce côté, nous verrons pour du plus long terme.

Je tiens à rappeler que c’était une preuve de concept. Je partage dans ce bloque les résultats car je crois que mon expérience vécue pourra fort probablement aider d’autres personnes dans des organisations, gouvernementales ou non, à avancer dans la mise en place d’environnements de développement pour Android.

Si vous avez d’autres pistes de solutions à me proposer, je suis preneur!

Refondre un site gouvernemental en tenant compte du UX

Le nouveau site du CSPQ arbore un tout nouveau visuel.

Aujourd’hui est lancé le tout nouveau site du Centre des services partagés du Québec(CSPQ), un organisme central dédié à rendre des services aux ministères, organismes et autres entités publiques du Québec. J’étais le stratège Web sur le dossier, et chargé de projet par interim pour un bon bout aussi. Bref, je suis pas mal impliqué dans le dossier. Bon, maintenant que les présentations sont faites, on va parler UX!

Je vous fais part ici de mon expérience personnelle comme stratège Web sur le dossier de refonte du site du CSPQ. C’est mon point de vue personnel et j’espère que les informations que vous retrouverez dans mon billet pourra vous aider dans votre propre organisation à faire avancer la cause du UX!

Pourquoi nous parler de ce site?

Bonne question. C’est un site gouvernemental, le genre de site, quand on le regarde, on se dit: «Booooooring!». Oui, j’en conviens, rien d’extravagant. Très corporatif, bleu (ben quoi?), identification obligatoire (le fameux PIV), deux colonnes navigation à gauche… euh… minute, là… Elle est où la navigation de gauche?

Voilà.

C’est un site corpo et tout, mais l’équipe de réalisation s’est permise d’aller un peu plus loin que d’habitude. Nous avons poussé la machine (et, croyez-moi, c’est pas toujours facile) pour oser des trucs qui, dans le monde du Web en général, sont assez bien acceptés. Alors, comment fait-on pour faire des choix et les appuyer? On utilise des processus de UX pour démontrer que ça fonctionne!

L’ancien site du CSPQ arborait une mise en page classique du Web pour un site corporatif d’il y a quelques années. Il avait été modifié au cours des ans pour répondre aux besoins, mais nécessitait une révision complète pour y intégrer de tout nouveaux contenus.

Mon présent billet va donc vous présenter les aspects du projet qui nous ont permis de réaliser le site que vous avez devant vous. J’en conviens, il n’est pas parfait (qui l’est?), il fera l’objet d’une amélioration continue, mais je dois dire que je suis assez content du résultat final… surtout qu’il a été réalisé avec un budget limité et un délai très court (4 mois – incluant les vacances des fêtes!).

Quelles sont donc les caractéristiques de ce projet? En voici une petite liste:

  • Approche de conception «Mobile first»;
  • Réalisation d’un tri de cartes
  • Réalisation de deux tests d’utilisabilité;
  • Évaluation heuristique;
  • Processus de développement SCRUM avec itérations de 3 semaines.

Bien qu’aucun de ces points ne soit une nouveauté ou révolutionnaire, le simple fait de les impliquer dans un tel projet, tous ensemble, est une révolution. Rares sont les fois où nous pouvons mettre à profit les méthodes agiles de développement, des approches UX et Mobile First ensemble. L’équipe du Centre de compétences Web (CCW) espère bien pouvoir faire profiter tous les prochains projets de cette expérience.

Le site utilise une navigation supérieure sous forme de menu expansible (est-ce la bonne traduction?). Bien que ce ne soit pas toujours l’idéal (j’en parle plus tard), nous avons fait ce choix pour la version mobile.

Mobile First

Dans le cadre du projet, nous avons eu la chance de travailler avec Stéphane L’Écuyer, un stratège Web UX qui avait une bonne expérience de design multiplateformes, mais surtout avec les approches de développement Mobile First, c’est à dire: développer pour le mobile, le reste suivra. Bon, c’est pas tout à fait ça, mais ça résume, ok?

Une particularité de notre clientèle, c’est l’environnement technologique qui est utilisé. Puisque nous nous adressons à des gens du secteur public, la majorité de nos utilisateurs sont sur des postes de travail fixes, avec Windows XP et Internet Explorer 8. Si. Malgré tout, nous devons nous ouvrir vers le futur, soit éventuellement Windows 8 et IE 11, mais aussi satisfaire notre clientèle qui peut utiliser tablettes et téléphones pour accéder au site. Tout un casse tête pour faire un site Mobile First qui passe bien en IE8…

Un casse tête? oui et non. La philosophie du Mobile First est de concevoir de façon optimale pour le mobile, on augmente ou ajuste pour les autres supports. Ça nous a obligé à simplifier le contenu, la navigation, la structure de l’affichage. Un impact assez important a été l’abandon complet du menu de navigation latéral dans les pages de contenu.

Cet abandon a été, selon moi, un effet positif majeur. Nous avons dû créer une arborescence de contenu la plus claire possible, pour permettre à un utilisateur de naviguer facilement dans le site. Nous avions tout de même des apréhensions… vite dissipées!

Des tests d’utilisabilité et un tri de cartes

Puisque nous avions des éléments qui nous causaient un petit, disons, inconfort, nous devions tester nos hypothèses, histoire de s’assurer de, comme dirait l’autre, ne pas être dans le champ. C’est pourquoi nous avons réalisé deux séances de tests d’utilisabilité avec 11 utilisateurs potentiels du site, externes à l’organisation.

La première séance a été réalisée dans un prototype Axure de moyenne fidélité (un prototype fil de fer avec quelques éléments visuels du site). Ce premier test nous a permis de valider la navigation.

De façon surprenante, aucun utilisateur n’avait remarqué l’absence de menu latéral de gauche. Le fil d’ariane et le menu de navigation ont été tous deux très bien utilisés. Bref, le concept tenait la route.

Une seconde volée de tests a cette fois été effectuée sur le site en acceptation (le site avec contenu réel partiel). Cette fois, nous voulions tester encore la navigation, mais aussi l’utilisation du site sur appareil mobile. J’en ai d’ailleurs parlé un peu ici… Encore une fois, les utilisateurs n’ont même pas remarqué l’absence du menu latéral. Bref, aucune crainte de ce côté.

Nous avons aussi voulu nous assurer de répondre le mieux possible à notre clientèle. Pour ce faire, nous devions utiliser des termes qui sont compris dans un classement logique. Nous avons donc procédé à un tri de cartes pour classer des services offerts au CSPQ. Les résultats ont été parfois surprenants. Nous nous sommes basés sur cette structure pour créer l’arborescence des services. Malgré tout, certains impondérables organisationnels n’ont pas permis de respecter toutes les recommandations du tri par les utilisateurs.

Une dernière évaluation, heuristique cette fois

Vient la dernière étape, le dernier droit pour la livraison… Cette fois, au lieu de procéder à des tests d’utilisabilité, nous décidons de faire faire une évaluation par un expert en UX, une évaluation heuristique du site, par Daniel Lafrenière, de la firme Sigmund. Pourquoi une évaluation heuristique? Plusieurs raisons. Manque de temps pour organiser des tests, charge de travail élevée et plein de trucs de dernière minute à régler.

Ça nous prenait une évaluation indépendante. Certains éléments du site restaient à valider et, faute de tests d’utilisabilité, nous aurions pu oublier des choses. Daniel a donc procédé à son évaluation, dans le cadre de ce que nous lui avons demandé (pas une évaluation exhaustive). Plusieurs recommandations ont été appliquées dès la réception de son rapport, d’autres devront malheureusement attendre. Malgré tout, cet exercice de regard extérieur sur un projet est fort instructif. Nous avons pu profiter d’une expertise et d’un point de vue nouveau rafraîchissant!

Des choix qui peuvent déranger…

Outre la disparition du menu latéral, qui, en soit, n’est rien de bien nouveau sur le Web, nous avons dû faire des choix qui, parfois, peuvent paraître dérangeants ou non conventionnels. Ces choix ont parfois été dictés par la technologie, les fonctionnalités déjà disponibles dans notre catalogue d’extensions TYPO3, les limites de temps ou de capacités de l’équipe… bref, plein de choses…

Le menu sur mobile

Le choix d’un menu qui prend la portion supérieure de l’écran n’est peut-être pas optimal, un développement ultérieur pourrait permettre une bonification du menu…

Nous aurions préféré pouvoir exploiter les volets latéraux dans la navigation mobile, ou nous reposer sur le fameux hamburger déjà présent dans le PIV mobile, pour afficher le menu de contenu du site, mais le manque de temps et nos contraintes budgétaires faisaient en sorte que nous devions optimiser la réalisation et utilisant des modules existants. Nous avons donc minimisé au maximum le développement en réutilisant des éléments déjà disponibles dans notre bibliothèque de composants…

Il n’est pas exclus qu’une version ultérieure pourrait disposer d’un menu mobile plus performant.

Le carrousel est imposant en page d’accueil, mais il sert une fonction de communication importante pour mettre en valeur des gens du CSPQ et les services offerts.

Il est gros, votre carrousel!

Oui. Et c’est voulu.

Nous avions des objectifs précis au niveau du positionnement du CSPQ. Des messages clairs à passer… Bref, outre les besoins utilisateurs, nous avions aussi des demandes et besoins organisationnels à prendre en considération. Ainsi, nous avons consciemment fait le choix d’avoir un carrousel imposant qui permette d’afficher un message clair.

Ok, ok… je vous vois venir avec vos critiques sur les carrousels. Il y a une multitude de billets sur le sujet. C’est mal, c’est méchant et ça pue. Ok, on le sait. Celui du site devrait bien remplir sa fonction, car il en a une – pas de UX, mais plutôt de communication.

De plus, outre le UX, il faut aussi prendre en considération le contexte opérationnel… Il existe fort probablement de meilleures solutions, mais elle ne sont pas nécessairement applicables dans le «day to day»…

Conrairement à ce que l’on voit de façon traditionnelle, l’ouverture du menu de navigation supérieur repousse le contenu vers le bas, tout comme le menu le fait sur la version mobile, un pattern de conception fréquent que nous avons transposé sur le site «régulier».

Le menu supérieur qui repousse le contenu

Avec ça, on a suscité des conversations!

Dans la version mobile du site, lorsque l’on ouvre un élément du menu supérieur, le contenu est repoussé vers le bas plutôt que de demeurer en dessous du menu. C’est un comportement habituel en mobile. Ce dernier a été reproduit pour la version desktop. Ce que certains peuvent ne pas aimer!

Je crois que c’est une fonctionnalité qui se verra de façon plus fréquente sur toutes les plateformes. Pour les plus anciens du Web, vous souvenez-vous de ces menus qui ouvraient et qui ne pouvaient passer devant des boîtes déroulantes dans IE? Si on avait pu repousser le contenu comme nous le faisons ici, le problème aurait été vite réglé! Mais ce n’est pas la raison de ce choix. Nous voulions une expérience cohérente en mobile et desktop. Le menu étant pleine grandeur, cachant une bonne partie du contenu de la page, le fait de le repousser n’avait pas d’incidence négative, au contraire, car au défilement, on peut avoir accès à ce contenu.

Sans vouloir dire que nous sommes avant-gardistes ou que nous voulons partir une mode, je crois que ce petit effet, quoi que négligeable, présente un certain intérêt. Daniel a mentionné son inconfort, nous le recevons, mais avons décidé de conserver cette petite fonction sans trop de malices. Est-ce une bonne idée? Personnellement, je pense que le pattern que l’on voit souvent sur mobile va se transférer éventuellement sur toutes les plateformes.

L’avenir me dira si je me suis trompé.

Le site est en ligne, vive le site!

Maintenant que c’est en ligne, on pourrait se frotter les mains et passer à autre chose, non? Eh bien, c’est tout le contraire. Le tout nouveau site doit maintenant faire l’objet d’évaluations au niveau statistique pour s’assurer que nos choix soient cohérents et aident les utilisateurs. De plus, des recommandations de l’évaluation heuristique nécessitent que nous prenions des mesures pour évaluer les changements à apporter.

J’espère que nous pourrons commencer à faire de l’optimisation du taux de conversion, ou CRO avec le site. Faire des tests A/B ou utiliser d’autres techniques de mesure pour en améliorer l’utilisabilité.

Les conditions sont là, la volonté aussi. Ne reste plus qu’à le faire.

Séance de tri de cartes

Les cartes sont prêtes, 155 par piles. Les cartes bleues sont celles qui seront utilisées par les participants pour séparer et nommer les regroupements.

Aujourd’hui nous procédons à une séance de tri de cartes pour le bureau. Rien de bien extraordinaire, allez-vous dire, mais tout de même assez exceptionnel dans le cadre de certains projets. Ainsi, nous avons une douzaine d’utilisateurs potentiels d’un site Web gouvernemental qui devront classer plus de 150 fiches d’informations de façon logique. J’ai bien hâte de voir ce que ça va donner en bout de ligne.

Comment ça se passe? Rien de bien compliqué. On doit imprimer une série de fiches et les découper (le plus long, selon moi) et on demande à l’utilisateur de les classer. Nous aurions pu utiliser des systèmes informatiques ou des sites Web nous permettant de le faire, même à distance, mais les budget étant ce qu’ils sont, nous avons dû nous rabattre sur des solutions, disons… analogiques!

Je dois parler d’un outil qui nous a grandement aidé pour la conception des cartes et qui devrait nous être très utile pour l’analyse des résultats, je parle du fichier excel développé il y a maintenant un sacré bout de temps, par Louis Rosenfeld.

Le fichier excel nous permet de saisir la série de cartes et, surtout, à l’aide de la publipostage dans Word (et d’un peu de magie noire, à ce que j’ai compris) on peut produire l,ensemble des fiches de façon presque instantanée (en autant que, pour vous, l’instantanéité ne soit pas trop rapide!). Bref, ça fonctionne bien et je désirais partager mon expérience avec l’outil.

J’ai déjà utilisé d’autres outils, plus complexe, comme, il y a fort longtemps, IBM EZSort, qui était probablement aussi stable qu’un unijambiste sur un fil de fer en plein ouragan. Bref, à déconseiller…

Ça commence cet après-midi. On verra bien ce que ça donnera!

Informer par la bande dessinée?

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…