Créer une interface web riche peut rapidement devenir une tâche très complexe mais il existe un truc pour simplifier la vie du concepteur et des développeurs de l’application! La rapidité de l’évolution de l’univers web et la multitude de ses implémentations fait en sorte que les artisans œuvrant dans ce domaine acquièrent de très grandes compétences mais avec des manières de faire très distinctes en fonction des technologies qu’ils ont utilisées.

Dans le cadre d’un projet, ces professionnels de l’informatique ont à développer, entre autres, des interfaces visuelles pour l’interaction de l’application avec les usagers. Ces interfaces rivalisent parfois de sophistication et de complexité car ils représentent une métaphore de la vision que les usagers ont de leur système de gestion de l’information. Il en découle que la composition visuelle des interfaces ne suit pas nécessairement les standards de base proposés par les fournisseurs d’éléments techniques de présentation. C’est là qu’entre en jeu la personnalisation de ces éléments visuels. Et c’est à ce moment que les forces des développeurs, au lieu de créer une synergie, peuvent créer une cacophonie technologique susceptible de consommer plus de temps que prévu dans un projet. Voilà pourquoi un conseil pour simplifier la vie du concepteur et des développeurs de l’application peut être très utile!

Une interface web riche se compose généralement de sections présentant un aspect général du système d’informations en offrant une série d’opérations ayant pour objectif de manipuler ces dites informations. Ces sections peuvent aussi se subdiviser en de plus petites sections présentant une ou plusieurs perspectives détaillées accessibles via des éléments de contrôle visuel. Une représentation visuelle particulière peut être employée pour signifier la création, la modification ou la consultation d’informations. Des opérations effectuées sur une section peuvent affecter la présentation d’une section parente, enfante ou latérale dans la hiérarchie. Une interface web riche, dans ces conditions, a toutes les caractéristiques classiques d’une interface résidante sur le poste client ou « client-serveur » complexe. En d’autres mots, ce n’est plus une simple page web comme il en existe des millions sur la toile mais une application complète.

Le conseil qui suit se décompose en une série facile d’activités qui consistent à :

1. identifier la technologie qui sera utilisée dans la conception de l’interface en fonction des éléments visuels particuliers et leurs besoins d’interactions avec le serveur;
2. identifier à partir des devis de l’application les éléments qui apportent l’homogénéité dans l’ergonomie de la présentation. Ces éléments peuvent être considérés comme les différents plus petits dénominateurs connus et il faut en faire l’inventaire;
3. implémenter chacun de ces éléments précédemment inventoriés et faire en sorte qu’ils soient autoportants. Ce sont des « coquilles vides », des éléments près à être personnalisés par le développeur en fonction des besoins fonctionnels présentés dans le devis de l’application;
4. faire un « livre de cuisine » qui indiquera la manière technique souhaitée pour l’usage de ces composants génériques. Ce guide du développeur doit demeurer simple, il sera utilisé comme référence pour se familiariser avec les composants réutilisables.

Cette démarche en quatre étapes épargnera beaucoup de temps dans la réalisation d’un projet comportant une interface web riche. Il apportera une plus grande cohésion technique, ce qui diminuera le risque d’erreurs durant le développement initial et ultérieurement dans le cycle de vie de l’application. De plus, comme l’information de base pour la réalisation des composants visuels sera écrite, la communication de l’information sera efficace et uniforme peu importe le roulement avec les partenaires du projet. Finalement, cette démarche facilitera la synergie des forces entre les membres de l’équipe de développement et évitera une cacophonie technologique très coûteuse en effort dans un projet.

• 0 Commentaires

Dans un site web dynamique reposant sur une base de données, les différentes pages décrivant le même type de données ont toutes la même adresse web. Ce qui permet de les différencier c’est seulement le paramètre, souvent un identifiant numérique, associé à l’URL.

Exemple d’une URL dynamique

http://www.mon-portail-touristique.com/portailregional.jsp?region=4

Ces pages dynamiques sont celles publiant sur le web les données issues de la base de données, par exemple : la page d’un produit dans un commerce électronique, la page d’un article dans un journal, etc.

Ces pages sont très mal indexées par les moteurs de recherche qui s’intéressent surtout à la sémantique de nos pages. En effet, ceux-ci considèrent les informations suivantes par ordre d’importance :

• 1 - Le nom du domaine
• 2 - Le nom de la page et de sa hiérarchie
• 3 - Le titre de la page (balises <hn>)
• 4 - Le contenu

Ces informations permettent au moteur d’indexation de conserver notre page web dans la bonne catégorie de son index et parfois même de tisser des liens sémantiques entre ces contenus et ceux d’autres sites.

Comment un moteur d’indexation, tel que Google, peut-il voir la différence fondamentale entre notre région numéro 4 et notre région numéro 5 s’il n’y a pas d’autres informations les décrivant? D’autre part, comment pourrait-il associer cette donnée avec d’autres informations de sa base de données si les mots-clés décrivant la région manquent !

C’est pourquoi des informations sémantiques plus pertinentes devraient être associées à l’adresse web. Par exemple, il est préférable de publier le mot-clé principal de la région dans l’URL, même si ce mot-clé n’est pas utilisé dans la requête (dans le script de la région c’est l’identifiant numérique qui est utilisé).

Exemple d’une URL dynamique et sémantique

http://www.mon-portail-touristique.com/portailregional.jsp?region=4&nom_region=Quebec

Ainsi, lorsque les ‘crawlers’ iront visiter notre site, ils verront distinctement la différence entre la région 4 et la région 5 et pourront identifier ce contenu avec des mots-clés.

Cependant, l’algorithme de l’engin d’indexation considèrera sans aucun doute que cette information est de second ordre si elle est placée dans un paramètre. Elle ne vaudra pas plus qu’un autre paramètre telle la langue ou le numéro de session ! Un autre facteur défavorisant l’indexation des pages paramétrées est leur nombre impressionnant et leur pertinence toute relative sur le web d’aujourd’hui. Enfin, considérons également le retard dans le développement des moteurs de recherche qui n’aide pas leur cause : celui par rapport à la capacité de gestion de ces url un peu spéciales.

Quoi qu’il en soit, c’est une vérité communément admise de nos jours qu’il vaut mieux avoir une url dans laquelle la sémantique n’est pas distribuée dans les paramètres, mais dans laquelle plutôt, la sémantique serait concentrée dans le chemin de la page et le nom de la page. On tente le plus possible de présenter une adresse de page qui serait sémantique en elle-même : les mots-clés font partie du nom de la page et de ses répertoires. Voici quelques exemples ou les mots-clés sont mis en avant et les identifiants numériques sont filtrés.

Exemple d’une URL sémantique (d’apparence non-dynamique)

http://www.mon-portail-touristique.com/portail-regional-quebec.html

Exemple d’une URL sémantique (d’apparence non-dynamique)

http://www.mon-portail-touristique.com/portail-regional/Quebec/

Comment s’opère cette magie : soit présenter plusieurs noms de pages statiques par un système dynamique opérant un seul script, i.e. une seule page qui les génèrent toutes ?

C’est la réécriture d’URL, aussi connue par les expressions anglophones ‘url rewriting’ ou ‘mod rewrite’.

Dans le prochain article, nous apprendrons comment réaliser cette magie à l’aide du module mod_rewrite de Apache.

• 0 Commentaires