The Future of Content Management – Rachel Andrew at Smashing Conference

qui dit encore cela ?

Tous les cahiers des charges demandent du WYSIWYG.

Effectivement, il reste très difficile de faire accepter à un client non technicien un outil de publication qui ne ressemble pas à son habituel Word.

ça divise les commerciaux et les intégrateurs en agence. (les développeurs, en général, s’en fichent...)

Entre montrer une interface de type ▻http://aloha-editor.org à un contributeur et le former (une demi journée au moins) aux raccourcis typos... Les contributeurs ne devraient pas se poser la question de la propreté du code généré. Ceci n’implique pas nécessairement qu’il gère la présentation mais afficher du gras en gras ne me semble pas hérétique #idée_pour_SPIP

Le « WYSIWYM » de SPIP répond à un soucis d’intégrateur, pas à un soucis de rédacteur / contributeur. On impose aux utilisateurs une contrainte par facilité technique sous prétexte de qualité. La qualité ce serait de disposer d’une interface graphique qui apporte satisfaction à la fois aux utilisateurs (WYSIWYG donc) ET génère du code propre (les raccourcis typo de SPIP). Impossible ?

Pas impossible, mais immensément plus compliqué techniquement, à concevoir et à maintenir.

C’est d’ailleurs pour ça que c’est un serpent de mer depuis des années aussi dans la communauté Wikimedia, et que même si depuis peu de temps ils ont quelques pistes, ils n’ont toujours pas terminé de développer une solution satisfaisante et complète. Et ce malgré les milliers de dollars qu’ils ont, comparé au projet SPIP.

Donc même si on peut toujours rêver, il y a relativement peu de chance pour que ce soit chez nous qu’apparaisse la solution miracle qui contentera tout le monde.

Par contre on peut suivre avec intérêt l’évolution de l’éditeur de Wikimedia, et voir s’il pourra être rendu générique pour générer n’importe quel format ensuite.
▻http://www.mediawiki.org/wiki/VisualEditor

Merci pour ces précisions. Je vais suivre ce qu’ils font.

Oh, ce très bon argumentaire m’avait échappé, merci @notabene ! Ça pose les bonnes problématiques.

« Provide something better than the Word experience of website content-editing. Your clients will stop asking for Word » : comme je plussoie !

Il faut NodeJS (coté serveur) pour VisualEditor @rastapopoulos. Ça va être compliqué pour SPIP.

En même temps c’est pas con, pour pouvoir dialoguer super rapidement entre client et serveur pour compiler le langage partout pareil sans programmer 3 fois la même chose... Enfin je dis ça au hasard sans savoir comment c’est fait (et wikimedia est en PHP je crois, pas en JS).

Plus précisément, le sous-projet de scannage et compilation, est là :
▻http://www.mediawiki.org/wiki/Parsoid

Et il n’est pas prévu de supporter d’autres langages que wikitext.