Gou blog

Dans le cadre de mon travail, il m'arrive d'avoir à travailler avec des gens de plusieurs organisations. Trop souvent, nous devons produire un document, peu importe sa forme, et le mettre en commun.

La méthode traditionnelle est de faire un document, puis de l'envoyer par courriel, recevoir des commentaires, les apporter, l'envoyer de nouveau... bref, vous connaissez. Cette méthode a changé, il existe maintenant un fabuleux outil: Google Docs.

Je n'irai pas jusqu'à dire que c'est magique, ou que c'est parfait, mais disons que ça simplifie grandement le travail entre intervenants éparpillés. C'est aussi le cas lorsque nous sommes de la même organisation mais dans des bureaux physiquement distancés de quelques kilomètres, le travail en commun sur Google Docs simplifie la vie de tous.

Le hic, c'est que certaines organisations dotées d'un niveau de paranoïa très élevé et d'un manque total de confiance envers ses employés barrent l'accès à cette merveilleuse fonctionnalité du Web!

Louis Naugès parle souvent de ce problème de blocage des autorités face à divers outils sur le Web et donne généralement des arguments de poids pour l'ouverture.

Ce que j'ai à dire à ces organisations: Bloquez si vous le voulez, mais offrez-nous un équivalent accessible par tous (fournisseurs, M/O et simples citoyens) et fiable. Ce sont des outils de travail qui améliorent notre productivité!! Pas des jouets! À défaut d'un équivalent interministériel, au moins un outil à l'interne de l'organisation serait un minimum!

Facebook, je peux comprendre que ce soit bloqué. Google docs, non. L'excuse donnée? peur des fuites, la sécurité des données. Mais qui empêche un employé de sortir avec un document sous le bras? Et les fax? il n'y a pas de fuites possibles avec ça? Et des employés, ça se sensibilise, non? Personnellement, je ne mettrais pas de données sensibles, si j'avais à en gérer, dans Google Docs... par logique.

Je ne nommerai pas les quelques organismes dont je sais les vues très limitées qui bloquent l'accès à Google Docs, mais vous pouvez vous en douter. Personnellement, ça me cause un problème. Ça ralentit mon travail, complexifie la gestion documentaire et ne me permet pas d'utiliser Google Docs avec certains collègues, alors qu'avec d'autres, c'est possible.

Vivement une meilleure compréhension des technologies par nos décideurs...

Libellés : google, gouvernement

Eh ben! En v'là une! Connaissiez-vous le World Graphic Day? Pas moi!

Il semblerait que cette «célébration» se déroule le 27 avril de chaque année, et ce, depuis 1995 (soit 13 ans cette année). C'est l'ICOGRADA qui a lancé le bal à l'époque.

Quelques événements ont eu lieu, mais il faut croire que le design graphique n'a pas la reconnaissance qui lui est due, étant donné le silence radio sur le sujet. Même InfoPresse n'en souffle mot.

Silence radio aussi chez la SDGQ ou sur leur blogue, Oeil pour oeil

Il n'y a que la Société des designers graphiques du Canada qui en parle. C'est décevant...

Je sais bien que notre métier n'est pas reconnu à sa juste valeur. Des «graphistes» de sous-sol, il y en a pas mal. Combien de fois on se fait dire par un client que ce dernier le ferait lui-même s'il connaissait les logiciels? Comme si être designer c'est juste une histoire de logiciels!

M'enfin. À tous les designers graphiques (Web ou non) de ce monde, bon WGD 2008

Libellés : design, graphisme, web design

Hier j'ai évalué les volets 1 et 2 de la compétition de conception de sites Web dans le cadre des olympiades avec Patrice Caron et j'ai beaucoup apprécié l'expérience.

Comme je l'avais déjà mentionné, l'épreuve est costaude. Aucun participant n'a été en mesure de compléter tout ce qui était demandé dans les délais prescrits, et c'est compréhensible.

Pour le premier module, ils devaient compléter, en 4h, la conception graphique, les gabarits HTML, les CSS, intégrer des notions d'accessibilité, produire une animation Flash et avoir un site avec navigation fonctionnelle.

Dans le second module (un autre 4h), il fallait intégrer une notion d'inscription au site, faire valider un formulaire en ligne (côté client), permettre la recherche, l'affichage et le tri de résultats et la visualisation du détail d'un élément, permettre une authentification comme administrateur et avoir des fonctions d'édition de contenu en ligne, en plus du changement complet de langue de l'anglais au français.

Patrice et moi avons constaté que ce qui ressort le plus dans l'évaluation, ce ne sont pas tant les compétences et les connaissances, mais plutôt la capacité qu'ont les participants à s'organiser dans le temps et à planifier le travail à faire.

Ils avaient depuis plusieurs semaines le devis et ont reçu les grilles quelques jours avant l'évaluation. L'approche idéale était de faire le tour de la grille et de faire ce que me disait un patron: «Go where the money is!»... quitte à mettre de côté certains éléments du site, pour focuser sur les plus importants.

Malgré tout, ils s'en sont généralement bien tirés. La compétition se termine cet après-midi et il y aura une évaluation complète du site incluant le code. J'ai bien hâte de voir qui sera le grand gagnant!

Libellés : compétitions, css, html, web design

J'assisterai le mois prochain au Webcom Montréal, qui se veut une continuité de celui de novembre dernier, auquel j'ai assisté.

C'est une sacrée journée, qui débute à 7h30, mais qui s'annonce très intéressante. Parmi les invités, il y a Frédérick Cavazza que j'ai bien hâte de voir en chair et en os plutôt qu'en pixels!

Le thème principal de la journée est «l'entreprise 2.0». Je vais assister à cette journée de conférences pour assimiler les concepts et peut-être avoir des outils pour aider certains clients à passer à l'entreprise 2.0.

Je dois dire aussi que j'aimerais bien profiter de quelques périodes dans la journée pour assister au WebCamp, qui semble encore une fois organisé par Sylvain Carle, événement que j'ai beaucoup apprécié la dernière fois.

Bref, un 14 mai bien chargé... et des billets qui suivront dans les jours suivants, vous pouvez en être certains!

Libellés : conférence, entreprise 2.0, web 2.0, webcom

Ce soir, je vais aller évaluer la portion pour laquelle j'ai été requis pour la compétition de Web design des 10e Olympiades de la formation technique et professionnelle.

Les concurrents ont à concevoir et réaliser un site Web en deux jours. À la vue des exigences et contraintes, je dois dire que c'est un défi assez costaud! J'aurai à évaluer, avec deux autres personnes, le volet design et intégration CSS/HTML.

J'ai bien hâte de voir ce qui ressortira de ce concours et le niveau de qualité des projets. Je vous donnerai mes impressions demain, lorsque j'aurai quelques minutes...

Libellés : compétitions, css, html, web design

Auourd'hui a eu lieu un Webmaestro traitant du processus de sélection de logiciels. Je n'ai pu assister à la première présentation, celle de mon ex-collègue Ramdane Guenineche, étant donné que j'étais à une présentation de Rogers-RIM sur les Blackberry, mais j'ai pu assister au débat de l'après-midi, par contre...

Ok, je l'avoue, le processus de sélection de logiciel, ça peut sembler aride... et oui, ça l'est! j'ai moi même eu à faire l'exercice pour mon organisation lorsque nous avons dû sélectionner un CMS. C'est aride, lourd et pas super amusant. Mais la rencontre d'aujourd'hui, elle, était amusante!

L'idée était de présenter la norme ISO-9126 et ce qui en découle pour le choix logiciel, dans un contexte pratique, avec métriques et tout le bataclan.

Une fois cette approche présentée, on passait à la réalité, une utilisation concrète ce la méthode. Puis, en débat, quatre panelistes (assez colorés) sont venus débattre de la pertinence d'une telle méthode dans la réalité actuelle du monde Web, avec les contraintes de personnel, de budget et normatives.

Étaient présents François Beauregard de Pyxis Technologies, Cyrille Béraud, Savoir-faire Linux, Daniel Pascot, Université Laval et Claude Poirier, Direction générale des achats, CSPQ

Bien peu de personnes étaient présentes (au plus une vingtaine), et ils ont manqué quelque chose. Le débat a vite tourné sur la pertinence même d'un processus de sélection versus une utilisation des standards ouverts. Une fois un tel standard adopté, peu importe l'outil, il fera le travail!

Ensuite, le principe gouvernemental d'acquisition de logiciels, avec appels d'offres et tout, n'est pas adapté à la réalité actuelle, principalement quand des solutions libres et gratuites sont disponibles.

La discussion a tourné autour des logiciels libres, de leur utilisation dans l'appareil gouvernemental. Il n'y a pas eu de guerre de religion, mais une discussion sur des pistes de solutions, des irritants, des problématiques...

Je peine à résumer tout ce dont il a été question, mais je dois dire que ce fut un beau débat, plein de rebondissements, d'exemples concrets et... bon... il en ressort plus de questionnements que de réponses.

Le seule véritable constat, c'est que le processus administratif d'acquisition de logiciels est loin de la réalité actuelle.

Libellés : logiciels libres, standards, web éducation

Ce matin j'ai assisté à une présentation de Rogers et RIM au sujet du développement d'application pour Blackberry. Tout d'abord, je dois dire que je ne m'attendais à rien... dans le fond, j'y allais pour le déjeûner et le dîner, sur le bras de Rogers!

Finalement, j'ai été agréablement surpris. Non pas que je deviens un crinqué du développement sur BB, mais plutôt que je comprends nettement mieux comment on doit s'y prendre... et on était dans le champ!

La présentation était faite par Brent Thornthon, de RIM. Il a trouvé l'autidoire un peu... disons... froid. M'enfin, comme l'a dit un participant, peut-être était-ce la barrière de la langue, Brent étant uniligue anglophone... Malgré tout, j'ai profité des quelques pauses pour l'assaillir de questions (comme mes collègues d'ailleurs).

Je ne suis pas un amateur de ces petits écrans aux capacités limitées, à la bande passante anémique et aux contraintes majeures. Et quand on a dû migrer, il y a plusieurs mois, une application Web développée en Java pour qu'elle fonctionne également sur ces petites bébelles pathétiques, j'ai plus d'une fois récité le chapelet!

Or, je dois faire mon mea culpa... Tout est dans la façon de s'y prendre. Tout d'abord, de prendre une application Web et de la faire fonctionner directement dans le navigateur du BB était... disons... une grave erreur de notre part. C'est entièrement dû à notre méconnaissance du produit.

Bien que, pour certains, ce dont je vais parler ici est du connu, je dois dire que ce n'était pas le cas chez nous lorsque l'on a commencé à travailler avec les BB et que ça aurait été bien utile de connaître un peu plus l'environnement. M'enfin, vaut mieux tard que jamais, non? Peut-être était-ce là un manque d'effort de notre part, ou bien que nous ne cherchions pas au bon endroit... Mais nous avons appris de nos erreurs, et je veux l'éviter aux autres!

Revoir notre approche face à l'envoi de données

Ces appareils, quels qu'ils soient, nécessitent des soins particuliers. Entre autre, au niveau de l'envoi des données... on va privilégier une approche en push plutôt qu'en pull. Ce que ça veut dire, c'est qu'on doit penser envoyer la données sur l'appareil alors que celui-ci est en état de le recevoir.

L'avantage est double: on facilite l'utilisation des dites données et on augmente la longévité de la batterie, le BB étant en mode réception plutôt qu'émission!

Bon, il faut donc revoir complètement notre façon de faire. Traditionnellement, nous n'envoyons des données que lorsque le poste client les demande (sauf avec AJAX, je sais...), c'est un genre de conversation. Pour ce qui est du BB, il semblerai que ce soit mieux de faire un monologue, du serveur à l'appareil...

Trois approches de développement

Lorsque l'on décide de faire du développement pour les BB, il y a trois grandes approches, soit:

• Utilisation du navigateur interne
• Développer avec MDS Studio (un genre de SDK)
• Développer Java mur à mur

Utilisation du navigateur interne

Pour ce qui est de l'application que nous avons développé, nous avons pris la première approche... ce qui était une mauvaise idée!

Le navigateur BB est un simulacre de navigateur. Il ne supporte pas toutes les propriétés CSS, ni même la structure de celles-ci. Il a beaucoup de difficulté avec le javascript. Bref, il a fallu créer deux applications parallèles, soit une pour les ordinateurs et une autre pour les BB. Ça fait le double de code à maintenir.

Brent a mentionné ce problème, qui semblerait assez commun. Peut-être aurait-il mieux valu regarder du côté des autres options...

Développer avec MDS Studio (un genre de SDK)

MDS Studio, ou le plug-in MDS Studio pour Microsoft Visual Studio, permettent de développer rapido des petites applications résidentes sur le BB. Et c'est assez rapide pour qu'il ait pu en faire une en moins de 2 minutes! en direct!

C'est une approche intéressante, dans la mesure où:

• On a une approche de services Web dans l'organisation;
• On a l'infrastructure suffisante;
• Nous sommes prêts à être confinés à l'univrers BB uniquement (pas de Palm ou autres ordinateurs de poche, car ce n'est pas compatible)
• Nous sommes prêts à revenir avec une approche près du client serveur (plutôt que le client léger Web)

L'avantage d'un développement avec MDS, c'est que c'est du RAD pour BB. On se branche sur le bon service Web (protocol SOAP - mais je ne suis pas très ferré là dedans), et ça fonctionne pratiquement tout seul (vive les démos live! ça fonctionne toujours tout seul... dans la mesure où l'émulateur ne plante pas, ce qui est arrivé au pauvre Brent!)

Développer Java mur à mur

La troisième approche, et non la moindre, est de faire du développement Java. Une application Java. BB est basé sur ce langage et permet donc beaucoup de choses. Or, c'est aussi plus complexe que l'utilisation du MDS.

Une autre approche

Il est aussi possible de faire affaire avec des logiciels tiers, développés par des partenaires. On a alors accès à des applications qui sont en mode fureteur, MDS ou en Java, selon le type et le fournisseur.

Une décision à prendre

La véritable question à se poser c'est: doit-on vraiment développer pour le BB? Si oui, quelle approche privilégier?

Désire-t-on avoir des applications qui soient portables d'un appareil et d'un fournisseur à l'autre? Veut-on être dépendant du BB? Désirons-nous avoir des applications complexes qui interagiront avec le système d'exploitation du BB?

Personnellement, je ne suis pas en mesure de faire de tels choix pour mon organisation. Je ne suis pas un décideur, seulement un exécutant. On verra bien quel sera le choix de mes supérieurs...

Libellés : blackberry, développement

Le gouvernement sait se surpasser parfois. On voit des choses très particulières. Mais quand un organisme de normalisation incite les membre de son pallier de gouvernement à des absurdités, nous sommes en droit de réagir, non?

Dans une page du site du SCT du Canada au sujet de la NSI on trouve des informations sur l'utilisation des CSS. Et ce qui est le plus amusant (ou désolant, au choix), c'est l'information sur la simulation de tableaux, en CSS!

Histoire d'être accessibles (si on comprend bien), l'organisme propose de faire des tableaux avec des DIV, plutôt que d'utiliser les balises TABLE et cie...

Vous souvenez-vous, il y a quelques années, lorsque l'on parlait beaucoup de la mise en page sans tableaux, les gens avaient tendance à refaire des tableaux, mais avec des div et plein de classes... je croyais que les leçons avaient été apprises, mais il semblerait que non.

Donc, collègues du fédéral, svp, ne suivez pas ce guide. Si vous voulez avoir un effet de tableau dans une page, ben... faites des tableaux en HTML! Au moins, votre code aura la valeur sémantique appropriée et le tout sera plus accessible (si votre tableau est bien monté!)

Ah Ha! comme dit le gars de Familiprix! Je l'avais (pré)dit! SVN, ou tout autre gestionnaire de sources, est un outil très très très intéressant pour les designers de ce monde, et voilà un article qui enfonce le clou!

Subversion est un gestionnaire de sources. Perso, je crois que cet outil a littéralement changé ma vie (enfin, celle que je vis au bureau), car ça permet tellement de choses concrètes, telles que:

• Le travail en équipe, sans se marcher sur les pieds;
• Un retour en arrière facile dans notre code;
• Voir les conflits de code entre diverses versions;
• Avoir des versions, justement, ce qui est franchement génial;
• Centraliser le dépôt des sources et avoir un contrôle constant sur celles-ci;
• ... et j'en passe!

Depuis que mon équipe a triplé (bref, depuis que nous sommes trois), la notion de gestion de sources est essentielle. Par exemple, si une collègue a des problèmes de code, je n'ai qu'à aller chercher la version problématique sur le serveur de sources, de travailler dans mon environnement et, si je corrige le tout, le pousser dans SVN, elle aura automatiquement accès aux corrections, avec un simple «update»

Le travail avec les équipes de développements est grandement facilité aussi. Ils ont accès au code, aux gabarits, à tout moment, et la dernière version, celle qui est fonctionnelle. Le tout couplé à Maven permet même de rendre le tout transparent grâce au POM

Ça fait maintenant deux ans que nous utilisons une approche avec, comme point central, le gestionnaire de sources. Je n'ai aucune envie de revenir en arrière et je vous conseille ardemment à regarder de ce côté si vous n'avez pas encore implanté une telle pratique chez vous. Même si vous êtes un designer!

Libellés : css, développement, méthodes

Difficile d'être plus explicite!

L'auteur nous remémore une des règles de John Maeda, soit de réduire. La réduction, à la fois de fonctionnalités, mais surtout, d'éliminer ce qui est inutile.

Dans l'image présentée sur le site en lien plus haut, on voit deux philosophies de simplicité superposées à une autre, diamétralement opposée, qui correspond malheureusement à ce que l'on rencontre trop souvent dans notre univers.

Déjà, si les concepteurs des systèmes développés dans nos organisations cessaient de se dire le fameux «tant qu'à y être», peut-être les formulaires et autres considérations administratives seraient moins... lourdes.

Il y a quelques mois, lors d'un Web éducation, un présentateur nous a fait visiter le site de HydroQuébec (je crois que le formulaire n'est plus en ligne! enfin!), avec un éloquent formulaire en ligne qui appliquait la fameuse notion du «tant qu'à y être». Des tonnes de questions, dont certaines nettement questionnables (quoi? le NAS pour demander la facture en ligne?)

Alors, plutôt que d'ajouter, pensez à réduire!

Mais comme le mentionne l'auteur du billet, John Maeda nous met en garde: parfois, la simplicité requiert des connaissances de la part de l'utilisateur. La simplicité et la complexité sont complémentaires et certaines choses ne pourront jamais être totalement simplifiées...

J'ajouterais qu'il est fort simple, par contre, de tout complexifier!

Libellés : interface utilisateur, utilisabilité, web design