Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

« Présentation de la mêlée quotidienne au Groupe Agile Montreal | Page d'accueil | CMMI et Agilité »

25 juillet 2008

Transformer les applications d'entreprise par le web 2.0

Avec tout le brouhaha autour du web 2.0 depuis quelques années, je me suis pencher sur la question de comment le web 2.0 pouvait nous aider à améliorer les applications que nous construisons pour nos entreprises. Il faut l'admettre, en effet, nos applications sont assez "classiques", pour ne pas dire franchement "platte". J'entends par là qu'elle font le travail, mais sans plus.

Parmi les dimensions importantes du web 2.0 on trouve l'aspect social, la contributiion des utilisateurs et l'effet réseau. Or sur ces plans, nos applications font généralement piètre figure, principalement parce qu'elle ne sont pas concues avec ce point de vue.

Par exemple, lorsque nous modélisons les besoins, on considère les cas d'utilisation de chacun des acteurs séparéments. L'acteur A consulte une information XYZ. On ne tient pas compte du fait que Jean consulte XYZ, Marie consulte ABC et Paul consulte MNOP et aussi XYZ. Or le simple fait d'exécuter le cas d'utilisation procure de l'information utile. Par exemple XYZ semble être populaire actuellement, et peut-être qu'il serait pertinent de dire à ceux qui consulte XYZ que MNOP pourrait être intéressant.

Ainsi il m'apparaît que certaines fonctionnalités pourraient être ajouter à nos applications, parfois sans grands efforts.

Voiçi quelques exemples:

- simplification de l'interface utilisateur. On veut souvent mettre toutes les possibilités d'interactions et d'informations sur des écrans qui finissent par être surchargés. Bien que cette caractéristique soit un effet de bord de la méthode de développement (en cascade, juste une chance pour émettre le besoin, alors on ne prend pas de chance, on l'ajoute!), il reste que les applications web 2.0 on souvent des interfaces épurées, simples et concentrées sur une fonction à la fois.

- informer l'utilisateur sur la "fraîcheur" de l'information. Beaucoup de système d'entreprise conservent les dates de création et de modifications des informations, mais peu exploitent cette information. Il est pourtant simple d'afficher une liste des dernières informations modifiées ou créées dans une format simple à lire comme "il y a 1 heure", ou "mis à jour il y 2 semaines". S'il vous plait n'affichez pas la date brut!

- évaluations. Une façon simple de permettre aux utilisateurs de contribuer du contenu est de leur permettre de voter sur un élément d'information. Par exemple, est-ce que l'information est importante? Utile? De qualité? L'évaluation peut être annonyme ou requérir une autentification selon les besoins. L'information ainsi contribuée permettra me mettre de l'avant les informations ayant une meilleure cote par exemple.

- commentaires. Une autre façon de permettre une contribution est d'offrir aux utilisateurs la possibilité d'ajouter un commentaire, lié à une information. Règle générale, lorsque nos systèmes ont un champ commentaire, ceux-çi sont retreint aux utilisateurs "officiels" du système. Pourquoi ne pas ouvrir l'ajout de commentaires à tous? On pourrait pousser plus loin et parler de "revue" de l'information.

- trace des visites. Une application a tout le loisir de garder une trace de ce que les utilisateurs font durant une session. Cette information peu servir a découvrir quels sont les fonctions, les champs et les informations les plus visitées et par conséquent les plus utiles dans le système, par exemple les informations les plus consultées. Ces traces permettent d'établir des patterns dans les données, par exemple "ceux ont consulté XYZ ont aussi consulté ABC". D'un coté cela permet de faciliter la navigation de l'utilisateur et de l'autre de lui faire découvrir des informations qu'il ne connaissait pas.

- touche personnelle. Il est souvent relativement simple d'identifier l'utilisateur, car la plupart des systèmes d'entreprise sont sécurisé et requiert une authentification. Tout les systèmes auxquels j'accède savent que je suis Jean Desbiens, mais peu s'en préoccupe. Sachant que je me reconnecte, pourquoi ne pas me présenter les informations que j'ai créés ou modifiés récemments, pourquoi ne pas se souvenir des recherches que j'ai effectuées. Pourquoi ne pas me montrer les informations que je partage avec mon groupe de travail? Beaucoup de choses peuvent être faites qui font que je me sente supporté personnellement par l'application plutôt que de façon anonyme.

- liste en format RSS. La plupart des applications web permettent de sauvegarder les listes affichées sous un format Excel ou CSV, pourquoi ne pas ajouter le format RSS? Ce n'est pas plus difficile et en plus ça peut facilement être consommé par d'autres applications! C'est probablement la façon la plus simple de permetttre à une tierce application de souscrire aux informations de l'application et de permettre les mashups.

- recherche en format RSS. Une fois les listes de l'applications disponibles en format RSS, pourquoi ne pas permettre d'interroger l'application dans le même format. Il s'agit simplement de permettre à la fonction de recherche de recevoir ses paramètres par un URL simple et de retourner un fichier RSS ou un autre microformat, ou carrément un XML.

- édition ouverte. Nos applications sont souvent très sécurisées, limitées a un groupe d'utilisateur restreint et la publication de l'information passe même parfois par un flux de travail (workflow) complexe d'approbation. Peut-être est-il temps de voir quel effet aurait une ouverture plus large aux utilisateurs, sur le modèle de wikipedia. A bas les approbations! Responsabilisons les utilisateurs! (Ca ne veux pas dire qu'on ne garde pas de trace des modifications ou qu'il n'y a pas un processus de modération).

- API, Application Programming Interface. La plupart de nos systèmes sont conçu principalement en fonction des besoins des utilisateurs (interactif) et des liens avec d'autres systèmes planifiés lors de l'élaboration des besoins. Ceci fait que les systèmes sont souvent fortement couplés et que ces interfaces sont très "privé". Un premier pas vers les architectures de services est de concevoir les systèmes comme une portion "présentation" et une portion "services" en gardant le couplage entre les deux au minimum. Et publiez cette interface de services ou API afin que d'autres puissent utiliser les informations de l'applications de nouvelles façons, qui apporterons de la valeur à l'entreprise.

Voilà quelques idées pour introduire un peu de web 2.0 dans vous applications.

12:40 | Lien permanent | Commentaires (0) | Tags : web 2.0