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!

BPMN

Voilà que, dans le cadre d’un boulot, je commence à m’initier au Business Process Modeling Notation (BPMN). Ouais, z’allez dire qu’il était peut-être temps, ou bien carrément: «kossé ça?»… Je vais tenter de répondre aux deux commentaires!


Quoi que pas très sexy à première vue, le BPMN est un outil fort intéressant pour modéliser des processus.

Le syndrôme du «Kossé ça?»

Le BPMN, c’est ni plus ni moins une manière de codifier visuellement les processus d’affaires qui sont en place dans une organisation. Ironiquement, c’est pas quelque chose qu’on avait tendance à faire dans le cadre de nos projets. Traditionnellement, quand j’aborde un développement de site ou de système, je me colle plus à une approche comme le User centered Design (UCD).

Généralement, tout designer qui se respecte fait quelque chose qui se rapproche de près ou de loin à du UCD, étant donné notre formation. Comment? on tente de comprendre les processus, les besoins, les volontés et les limitations liés à l’utilisation d’un produit. Je ne suis pas certifié en la matière, mais plutôt un autodidacte, donc pas un spécialiste à proprement parler. Alors, que fait le BPMN là dedans?

Le BPMN permet de codifier visuellement (et textuellement) les processus d’affaires d’une entité, ainsi d’avoir un diagramme qui explique comment sont faites les choses par étape, un workflow, en bon français. Je dirais que c’est un bon complément à une approche centrée utilisateur car ça vient compléter l’analyse que l’on fait du besoin.

Pourquoi maintenant?

On a eu droit à une petite présentation d’introduction au BPMN au bureau et ça m’a accroché. J’ai tout de suite trouvé un lien direct avec le boulot de Web designer. Nous devons à tout moment modéliser des processus et on utilisait parfois tant bien que mal le UML. Encore une fois, j’ai appris sur le tas et, dans ce cas, j’ai toujours trouvé ça laborieux. BPMN est nettement plus près de mes besoins et connaissances!

Il est certain que le BPMN n’est pas la panacée, mais disons que c’est un outil de plus dans notre arsenal.

Ok, on fait ça comment?

C’est assez simple. Si ça vous intéresse, je vous invite à aller chercher l’aide mémoire (qui s’apparente à un cheat sheet) de BPMN. En parallèle, vous pouvez vous initier par l’utilisation d’un outil fort simple comme Aris Express.

Bon, l’outil est simple, mais difficile à installer dans un environnement comme celui de mon bureau!

Pour ceux qui ont Visio, des versions récentes, il y a plein de plug-ins BPMN que l’on peut installer gratuitement. Petit hic, par contre, ces plug-ins sont des banques de visuels pour les diagrammes, mais il n’y a pas les règles de positionnement (ou semblent incomplètes) telles que dans Aris Express, car des «erreurs de notification» sont possibles (des trucs que BPMN ne permet pas sont possibles dans Visio, et non dans Aris).

Sinon, il y a toujours le bon vieux papier et crayon 😉

Et alors?

Je commence à m’y mettre tranquillement. Comme bien des trucs, j’apprends sur le tas et je fais des lectures sur le sujet. Heureusement, c’est assez simple, logique et facile d’utilisation.

Si vous avez à travailler auprès de clients pour informatiser certains aspects de leurs processus, je vous conseille fortement de vous y mettre. Et si vous êtes Web Designer, il y a fort à parier que vous y trouviez votre compte.

Les ventes de portables dépassent celles des ordis de bureau… et j’en fais partie!

Pour la première fois, les ventes de portables ont surpassé les ventes d’ordinateurs de bureau. Bon, là, je ne vous apprends rien, c’est des statistiques connues depuis quelques semaines déjà. Mais ce qui est intéressant, c’est pas tant le fait que les portables sont plus vendus, mais plutôt que ça change la manière dont les gens ont accès au Web.

Louis Naugès (encore lui, je sais…) en parle dans son blogue, sur le iPod Touch Max (nom fictif?) et l’analyse qu’il fait, c’est surtout que, de plus en plus, les gens vont accéder au Web par des smartphones, netbooks ou des bons vieux portables (comme mon tout nouveau Studio 17, eheh!).

Ça change la manière dont on va concevoir nos sites. De plus en plus, on devra s’adapter à ces multiples outils qui viennent diversifier la manière de visualiser et de consulter nos sites.

Déjà, nous avons des clients, à mon ministère, qui utilisent des BlackBerry pour accéder aux sites qui leurs sont dédiés. Pourquoi se limiter à cette technologie alors qu’il existe plein d’autres outils? Quoi que le nouveau BB, le Storm, est nettement plus intéressant que les anciens que l’on voit dans les mains de nos gestionnaires…

C’est à nous de repousser encore plus loin les limites de la conception des interfaces Web de façon à tirer profit de la mobilité accrue de nos utilisateurs. Leur offrir des outils utiles là où ils sont! Pourquoi pas, lorsque c’est possible, les localiser par GPS et leur offrir les données susceptibles des les intéresser au moment présent?

Ouais, je sais, certains le font déjà, mais au gouvernement, principalement au Québec, je crois qu’on a un sacré retard en la matière. Nous continuons à faire dse formulaires de saisie, alors que l’expérience utilisateur pourrait être nettement plus poussée.

Une amie me parlait, pendant un excellent souper du temps des fêtes, du travail en cours dans son ministère, qui devrait «révolutionner» l’approche utilisateur. J’ai confiance en son travail, et j’ai bien hâte de voir le résultat. Étant donné que son ministère est un phare, un leader en la matière, il y a de bonnes chances que les autres emboîtent le pas.

Bref, tout ça pour dire que nos utilisateurs sont plus mobiles, et on se doit de profiter de cette mobilité.

Expérience utilisateur pour les nuls

Quel superbe article! L’expérience utilisateur pour les nuls, 101, démystifié… nommez ça comme vous voulez, mais c’est enfin un condensé de l’ensemble des théories, vues, visions et autres idées des grands penseurs de l’expérience utilisateur: Garrett, Nielsen, Morville

J’apprécie l’ensemble de l’oeuvre, mais tout particulièrement la portion où il est question de gestion de projet et de biens livrables. Effectivement, trop souvent, on se fait dire que d’implanter une approche centré utilisateur est difficile:

  • Quand doit-on faire des prototypes?
  • Quand doit-on faire des testes d’utilisabilité?
  • Quelles sont les étapes de réalisation?

L’auteur présente un schéma qui résume l’ensemble des tâches, biens livrables et les moments où on devrait faire des preuves de concept (prototypes). Juste ce petit diagramme vaut l’article au complet, pour mes besoins, du moins!

Je travaille dans un monde d’informaticiens qui sont habitués à travailler avec une méthode traditionnelle (voire rétrograde), ce qui, selon l’auteur de l’article, n’est pas adapté à une approche d’expérience utilisateur.

Effectivement, si on réfère à son avant-dernier diagramme, on voit bien vite que les méthodes dites agiles sont nettement plus adaptées!

N’allez pas croire que je renie le début de l’article, au contraire! il démystifie et explique ce qu’est le champ de travail de l’expérience utilisateur, les composantes, les théories…

Bref, pour ceux qui veulent faire comprendre que l’utilisateur est au centre du développement et que l’on devrait peut-être s’en soucier plus, histoire d’éviter des développements pathétiques d’applications telles que des SAGIR…

Développer des applications pour Blackberry, trois approches

Petites baies noires nommées mûres en français
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…