L’enfer des éditeurs de texte… juillet 26, 2009

Aujourd’hui contrairement aux années précédentes, nous sommes plusieurs rédacteurs sur ukulele.fr. Du coup s’est posé le problème de rentrer du texte dans un blog. Sur le dotclear que j’utilise depuis 4 ans, pas de Rich Text Editor, du “mode wiki” ou du html brut.

Comme je ne peux pas demander à mes corédacteurs d’apprendre le HTML et que j’utilisais moi même le mode wiki, j’ai dû leur faire un peu de rapide formation. Bilan : la syntaxe wiki est facile, c’est passé bien même avec des utilisateurs carrément pas tech-savy, mais néanmoins ça laisse un arrière goût de “je ne comprends pas trop ce que je fais ça passe quand même”, avec des ajouts involontaires (double retour chariot qui deviennent un <p> html etc). Rien de grave mais pas satisfaisant.

Donc pour le back office de éphémérid, je veux un bel éditeur HTML. Tour rapide de l’existant : FCKEditor (bientôt CKEditor), TinyMCE, WYMEditor. Pour le reste, trop fancy, pas assez mature, pas assez documenté.

Mon besoin est simple : un éditeur de texte avec des options très basiques, gras, italique, souligné, strikethrough, bullet list, listes à nombres, hyperliens, et éventuellement je garde la possibilité de lier des images (même si je pense plutôt gérer les médias séparément et les lier aux textes par ailleurs afin de contrôler la vue finale).

Constat : la plupart (tous) les éditeurs de texte choisis sont des usines à gaz qui gèrent trop de choses par rapport à mon besoin. Partant de l’idée que qui peut le plus devrait pouvoir le moins je me lance – en sachant d’avance que je serai déçu sur le chemin.

J’opte pour TinyMCE, utilisé par pas mal de CMS, développement sérieux, API claire, customisation apparemment facile, intégration qui ne parasite pas le framework choisi, bonne documentation. Il existe une application non libre des mêmes développeurs pour éventuellement la gestion des images et une autre open source. Hélàs, je déchante. Très lourd (le temps de chargement est ignoble), sa très bonne API ne suffit pas à me le faire garder. Très chargé, manque de souplesse, les contrôle de son apparence ne sont pas clairs.

Ensuite WYMEditor : à priori une philosophie parfaite pour ce genre d’outil. Il est par nature limité (pas de choix de polices ou autres aberrations pour un back office possible), propose quand même de gérer éventuellement des images, etc… Première grosse déception, il utilise Jquery qui est sans doute très bien mais qui n’est pas le framework que j’ai choisi. Pas très grave (hormis la lourdeur) puisqu’il peut cohabiter sans souci avec Prototype. Ça fait un peu râler quand même. Installation et déploiement : premier essai ça va – j’en profite pour nettoyer un peu ma CSS que j’ai faite par dessus la jambe en évitant que mes div se chevauchent etc… Et j’essaie de customiser la chose. Là c’est la débacle : la doc est indigente et toutes les modifications sont d’ignobles bidouilles indignes ! Il faut taper dans les styles pour désactiver des options, pas de méthodes intégrées, du bricolage qui mélange le HTML, les CSS et les scripts pour les mises en page – c’est ce que préconisent les développeurs eux-même (qui répondent essentiellement par “regarder les exemples – le code source hein, il n’y a rien de bien détaillé). Une horreur d’autant plus décevante qu’elle est à l’opposée du module lui même ! Exit donc les infâmes bidouilles de WYMEditor qui n’est utilisable que si on le prend out of the box (ce qui ne me va pas). Exit aussi tout ce qui ne sera pas correctement documenté.

CKEditor je tente rapidement, mais version RC (utilisable et fonctionnelle quand même), absence de doc (normal le produit n’étant pas en version production), alors que l’API semble très chouette elle n’est pas du tout documentée. Dommage.

FCKEditor la version précédente : je prends, il a un peu des défauts et des qualités des précédents. La doc est bien comme TinyMCE. Il n’est pas d’une souplesse terrible et il faut un peu bricoler – la config ici, le lien là -mais ça marche. Il n’a pas la beauté de la simplicité de WYMEditor (en utilisateur s’entend) mais on peut le brider. Pour le moment ce sera donc FCKEditor. Reste à voir comment il s’intégrera dans la suite du dév.

Bilan de ces essais : si quelqu’un est dans le développement de ce genre d’outil, qu’il pense simplicité et pérennité ! Il faut un outil qui marche sur tous les browsers, qui ne cassent pas avec les changement de version, qui reprenne les bonnes idées de WYMEditor avec la possibilité de contrôler simplement l’aspect, avec une API riche et efficace surtout,où une ligne de code permette d’ajouter ou d’enlever des boutons ou de rajouter des fonctionnalités ! Il ne faut pas des machines à tout faire qui imitent des traitements de textes, c’est le défaut de tous ces éditeurs à l’exception de WYMEditor, ce sont de mauvais clônes de Word – donc ils n’ont rien à faire dans les back offices des CMS ou des blogs.

Et ceux qui veulent faire un traitement de texte en AJAX n’ont qu’à aller voir chez GoogleDocs !

Du choix des technologies suite juillet 26, 2009

J’en suis actuellement après un premier draft fonctionnel de la base de données à développer le back-office.

J’ai une vague idée pour le front, mais finalement on s’en branle je sais que ce que je produis sera facilement utilisable, et le cahier des charges étant assez simple je peux me lancer avec cette simple vague idée.

Pour le back office du tout venant, avec pour moi cette nouveauté de finalement utiliser AJAX, donc requête et tutti cuanti… nouveauté toute relative puisque c’est exactement comme ça que je codais en actionscript, en plus simple ! Aujourd’hui avec tous les bons exemples d’applis on line (chez google en particulier) on a de suite les bons réflexes.

Après il faut savoir éviter les mauvais plis. Je n’ai pas besoin d’utiliser une librairie à la scriptaculous pour faire des fondus de transparence, parceque je n’ai pas besoin de transition. Exit donc ces apparitions que mes mauvaises habitudes de flasheur me font toujours regarder (et une heure de dev perdues du coup mais bon). Je la garde sous le coude parcequ’il y a peut-être quelques trucs efficace pour l’usability comme disait le désagréable Jakob Nielsen – qui a toujours fait croire qu’il était révolutionnaire en disant les évidences avec deux trains de retard.

Donc je me perfectionne un peu en CSS toutes carrées, en js, dans la librairie prototype.js, dans les aller retours AJAX style, et l’utilisation du browser comme un environnement d’exécution d’applications.

Et aussi je me débarasse d’un vieux principe qui m’a fait perdre des journées : j’arrête de réinventer la roue, en ne me resservant pas de mes bibliothèques parceque pas assez “dans le vent” et en n’utilisant pas les choses toutes faites – j’arrête l’open source à sens unique du coup et je me sers aussi.

Et les problèmes commencent

Des choix des technologies en gros juillet 26, 2009

À l’ordre du jour, le développement d’une application dont le synopsis résumé est en gros de gérer pour le back office (single-user) et d’afficher une chronologie, aggrémentée d’un système de tags et éventuellement d’une gestion de médias.

Quelques choix déjà pris et pourquoi :

- Pas de flash : parceque j’ai fait ça exclusivement depuis huit ans pour toutes les parties clients des sites, donc lassitude, mais surtout parceque c’est une technologie dans laquelle je n’ai plus confiance. Pas confiance dans l’éditeur qui n’est pas capable de faire des versions utilisables de ses outils, pas confiances dans les bidouillages open source autour – parfois d’un niveau épatant quand même mais bidouillage non par leur fabrication, mais par la nature de la plateforme, qui évolue trop vite au gré des modes et qui se trouve aujourd’hui limitée à lire des videos dans des environnements HTML/JS. Pas confiance non plus dans l’insistance à ne pas suivre les standards. Pas utile car ce qu’on ne pouvait faire qu’avec flash est largement faisable en Ajax dès qu’on ne parle pas d’animation riche et d’eye candies pour lesquels Flash reste insurpassable.

-PHP/MySQL/Apache : forcément incontournable trio, qui a fait ses preuves et dispo chez quantités d’hébergeurs, donc permettant une migration facile. En outre tout ce petit monde étant open source, le développement sera toujours récupérable d’une manière ou d’une autre.

- AJAX : nouveauté pour moi, mais on voit tellement de bonnes choses, et c’est tellement familier, et surtout je peux continuer à coder des choses rapidement pour de petites applications sans rentrer dans des frameworks imbitables.

- En parlant de framework justement : je découvre Prototype.js dont la philosophie m’est assez familière (et que je t’étends allègrement les namespace existants) qui est proche aussi de la philosophie “développement rapide” inhérente à javascript, sans s’empêcher de faire les choses proprement.

- Du coup pour les échanges clients/server ce sera JSON, côté client c’est pris en charge pas le framework Prototype.js, côté serveur ce sera du fait main le temps de me bricoler un parser approprié en PHP (grave manque de ce côté là dans l’open source, rien de facile à utiliser dans un simple include, je ne veux pas entendre parler de PEAR). JSON aussi parceque du XML j’en ai fait plus qu’assez, donc passons à autre chose, que malgré l’aspect un peu dégueu de la spec remplie de guillemets c’est rapide à déployer et plus lisible que du XML, et parceque du XML je m’en fade avec le DOM de toutes façons.