Le web, quand on s’attaque à une clientèle large, demande des outils facile à prendre en main pour une utilisation quotidienne.
Les outils existants, CKEditor, TinyMCE proposent des solutions vraiment facile a mettre en place et à intégrer dans un CMS, mais elles ne font pas toujours des merveilles.
Effectivement, ces éditeurs WYSIWYG offrent peut être un aperçu quasi identique à ce que l’on va obtenir dans le site. Mais ils ne corrigent pas les erreurs d’ouverture et de fermetures de balises que provoquent les modifications de mise en forme répétées par l’utilisateur dans cet éditeur. Les dernières version s’approchent de la perfection, mais aucun d’entre eux ne proposent actuellement une correction du code html parfaite à 100%.
La flexibilité que l’on obtient donc avec ces éditeurs peut nuire au rendu final de la page sans que l’utilisateur qui ne connait pas une seule balise html soit a même de comprendre ou d’évaluer l’origine du problème.
Là où je bosse nous avons comme credo d’offrir au client une flexibilité maximale. Une fois une page d’accueil maquettée, il doit etre possible pour l’utilisateur a l’aide d’un éditeur de modifier intégralement la page sans avoir à passer par nous.
Depuis peu, une partie de l’équipe constate le revers de la médaille de cette pratique : les pages finales, rédigées par la secrétaire de l’adjoint-en-second-de-l’adjoint-du-sous-directeur-du-maire qui ne jure que par Comic-sans-MS en fuscia gras dans une charte dominée par le Tahoma vert non-gras rendent le site final incroyablement moche. On fait bien sûr l’impasse sur les marges, les écarts entre les images flottées dans un paragraphe de texte et autres joyeusetés par la même occasion.
Si bien que lorsque l’on présente ou revient sur des sites faisant partie de nos références, on tombe de haut : les sites ne ressemblent en rien aux maquettes livrées et font office de portfolio de débutants si j’exagère un peu.
De mon coté, depuis que je code des outils de mise à jour, j’ai toujours eut en tête des formulaires bien stricts et fixes, avec des éditeurs WYSIWYG légers mais qui ne sont qu’un complément des champs principaux d’une fiche. Si bien que l’utilisateur ne peut pas trop sortir des bornes que l’on a définit. Au final le site est toujours très carré, les marges respectées, les polices et couleurs restreintes à la charte.
Aujourd’hui l’équipe veut continuer dans cette idéologie de fléxibilité, mais que faire ? Les client sont généralement trop profanes pour vraiment appréhender la mise en page différemment de leur word habituel, il n’est même pas question d’apprendre l’html.
A l’heure actuelle je compense énormément les erreurs de mise en page par des scripts javascript qui alignent les blocs, les taillent à la bonne dimension en se basant sur le plus grand, corrige les marges et les conteneurs plus grand que leur parent. Une tonne de scripts qui alourdissent profondément le chargement d’une page… une technique que je n’apprécie pas spécialement.
Même récemment, un client se vantant d’avoir une exigence extrême en terme de mise en page a commencé par mettre un gif des années 80 pour l’adresse de contact accompagné d’un lien bleu IE5 avec une taille de police 6 fois plus importante que la charte.
Au final, je crois bien qu’il faut simplement se faire à l’idée que pour des clients “moyens”, les mises en page seront saccagées quoi que l’on fasse si l’on ne change pas pour des formulaires dirigistes. Seul les gros comptes client où une équipe rédactionnelle travaille 8h par jour sur le contenu peuvent gérer ce genre d’outils. C’est navrant, parcequ’au final, cela nuit quand même a l’image de la boite, quand les clients potentiels viennent faire un tour sur nos références…
Commentaires récents