Pourquoi nous avons décidé de développer ManyPage

Pour mieux comprendre l'intérêt de ManyPage, il faut comprendre qu'il est issu d'une expérience de plus de 6 ans de développement et de maintenance de site web depuis 1994

De HTML 1.0 HTML 2.0 puis ...

Nous y avons pensé pour la première fois quand ils ont lancé HTML 2.0. Ou plus précisément était-ce peu après que Netscape ait introduit la possibilité d'ajouter de jolis papiers peints comme fonds des pages HTML. En fait, ces "backgrounds" étaient parfois si "lourds" qu'ils rendaient la lecture des pages difficile, mais de toute manière, nous avions voulu utiliser cette fonctionnalité, car à cette époque, il n'y avait pas tant de possibilités pour rajouter un peu de piment aux page web...

Du coup, nous nous sommes mis au copier/coller à la chaîne pour rajouter un attribut au tag BODY de dizaines de pages web. Et nous avons alors décidé que nous ne tomberions pas deux fois dans le même piège. Nous avions alors déjà beaucoup de pages à gérer et nous commencions à utiliser Perl.

D'un directeur, d'un président au suivant.

De plus, non seulement les versions de HTML, mais aussi les président et leurs cohortes de directeurs changent dans une entreprise ou un institut. Et bien sur chaque nouveau directeur ou président se doit de prouver qu'il est celui qui a inventé l'internet (ou l'intranet suivant l'époque). Il exige pour cela de tout reconstruire. Bien sur, l'information brute ne change pas vraiment avec l'arrivée d'un nouveau directeur. Il suffit en fait de changer la manière dont cette information est présentée.

De l'écriture du HTML avec 'vi' à l'utilisation de Dreamweaver.

Pour rester honnête, je dois avouer que je n'utilise 'vi' que pour la configuration à distance de daemon comme apache. En fait j'utilise des éditeurs de texte un peu plus évolués comme 'jot' sous SGI ou BBEdit sous Mac et qui permettent le copier/collé à la souris. Heureusement, aujourd'hui, n'importe qui peut produire des pages web simples à l'aide des éditeurs HTML modernes. Et il est important que ces pages produites par ceux qui apportent l'information puissent facilement être incorporées dans des sites web, graphiquement et fonctionnellement enrichies.

D'un Webmaster centralisateur à une équipe de 10 correspondants éditoriaux.

Cette démocratisation de la production de l'information s'accorde avec l'évolution naturelle de la production et de la maintenance d'un site web ; quand de plus en plus de personnes ont besoin d'apporter et/ou de corriger de l'information sur un site. Et au plus les correspondants éditoriaux sont indépendants, au plus les équipes techniques peuvent se concentrer sur des taches plus enrichissante pour le site que la simple mise en page HTML de document textes.

D'un site web à 10 sites web.

Après notre première expérience de mise à jour de notre code HTML, nous avons développé un premier script qui rajoutait des menus à des pages HTML encapsulées dans du SGML. Mais la définition de ces menus se trouvait inclus dans l'écriture du script. Ainsi à chaque fois que nous voulions développer un nouveau site avec un design différent, il nous fallait modifier le code Perl de notre premier script. Il était en particulier difficile de gérer plusieurs sites différents simultanément.

D'un langage à 2, 3, 4... langues.

Notre site se devait d'être au moins bilingue. Il devait être au minimum en Français. Et comme nous avions l'ambition de présenter un site international, il nous fallait au moins le rendre disponible en Anglais et aussi parfois d'autres langues quand la traduction était disponible. Nous avons retenu deux caractéristiques à ce sujet.

D'abord, les différentes versions de la même information devaient se trouver assez proche en terme de gestion de l'information. Si vous placez les pages françaises et anglaises à différents endroits (nous parlons ici de répertoires) avec des noms différents, vous pouvez être sur que l'équipe éditoriale oubliera de maintenir l'une ou l'autre des versions.

Ensuite, au moment ou nous élaborions ManyPage, les moteurs de recherche n'étaient pas encore capables de distinguer les langues utilisées dans les pages web. Quand un lecteur anglophone débarquait sur une quelconque page française de notre site, nous voulions qu'il puisse facilement et rapidement passer à la version anglaise, sans par exemple avoir à repasser par la page d'accueil du site. Cette préoccupation reste encore valide car il peut arriver de débarquer sur un site par l'intermédiaire d'un autre site monolingue (et donc ne pointant pas systématiquement vers la bonne version des pages).

Bien sur, il est possible de laisser la gestion de cette bascule au soin du couple client/serveur. Mais de mon point de vue, je préfère pouvoir choisir quand je désire basculer de la version locale à la version internationale d'un site, et en particulier quand je pense que les deux versions ne sont pas mises à jour de façon totalement synchrone, ou encore quand je veux travailler ma connaissance d'une langue :-)

D'un habillage simple à un design graphique doublé d'une version allégée (pour l'impression ou pour faciliter l'accès au site).

Ce dernier point est en rapport avec la complexité croissante des pages web. Au plus vous rajoutez des images et des gadgets graphiques à une page web, au moins cette page est lisible ou accessible pour une imprimante, pour des websurfeurs avec des connections de faible bande passante, et aussi et surtout pour les aveugles et les malvoyants.

A partir d'une page web sans fioriture, notre outil peut générer en même temps une page web graphique avec des menus pop-up et une page légère avec des menus textuels.