Il existe de plus en plus de wysiwyg pour spip
- BTE
- Tynymce
- spip-typo
mais lequel choisir / pourquoi ?
merci pour votre aide.
Bonjour,
par expérience le Wisiwyg explose ta mise en page,
et j'ai beaucoup pesté contre SPIP de ne pas avoir mis un éditeur Wisiwyg,
mais finalement, je remercie SPIP de ne pas le faire, quel galère le HTML non contrôlé !!!
Donc toute barre typo fondé sur les raccourcis SPIP, c'est ça qu'il faut.
Athama
Il existe de plus en plus de wysiwyg pour spip
- BTE
- Tynymce
- spip-typo
mais lequel choisir / pourquoi ?
merci pour votre aide.
"athama" <athama@fantastikasia.net> a écrit dans le message de news:
001401c7c88b$7d7e7f80
par expérience le Wisiwyg explose ta mise en page,
et j'ai beaucoup pesté contre SPIP de ne pas avoir mis un éditeur Wisiwyg,
mais finalement, je remercie SPIP de ne pas le faire, quel galère le HTML
non contrôlé !!!
Donc toute barre typo fondé sur les raccourcis SPIP, c'est ça qu'il faut.
Athama
----------
+1
j'ai fait le même cheminement. Mais il faut souligner que la typo de spip
sans les plugins barres typo c'est pas facile à présenter à des gens qui se
moquent d'avoir à connaître la typo de spip.
En tout cas, c'est un vrai sujet au moment de créer un site car faire un
choix quelqu'il soit c'est s'engager pour longtemps car "balises" ou
"typo"... tout çà s'écrit dans la base...
Stanislas
Bonjour Stanislas,
Le mardi 17 juillet 2007 à 18:49:41, vous écriviez :
"athama" <athama@fantastikasia.net> a écrit dans le message de news:
001401c7c88b$7d7e7f80
par expérience le Wisiwyg explose ta mise en page,
et j'ai beaucoup pesté contre SPIP de ne pas avoir mis un éditeur Wisiwyg,
mais finalement, je remercie SPIP de ne pas le faire, quel galère le HTML
non contrôlé !!!
Donc toute barre typo fondé sur les raccourcis SPIP, c'est ça qu'il faut.
Athama
----------
+1
j'ai fait le même cheminement. Mais il faut souligner que la typo de spip
sans les plugins barres typo c'est pas facile à présenter à des gens qui se
moquent d'avoir à connaître la typo de spip.
En tout cas, c'est un vrai sujet au moment de créer un site car faire un
choix quelqu'il soit c'est s'engager pour longtemps car "balises" ou
"typo"... tout çà s'écrit dans la base...
Stanislas
C'est quand même pour ça que tant de gens fuient Spip et se réfugient
vers d'autres CMS.Que la grande majorité des blogs ne sont pas sous Spip.
Sur Wordpress faudra qu'on me montre que le html
explose la page...
--
Cordialement,
AS Courriel : karaou@gmail.com
AS a écrit :
C'est quand même pour ça que tant de gens fuient Spip et se réfugient
vers d'autres CMS.Que la grande majorité des blogs ne sont pas sous Spip.
Sur Wordpress faudra qu'on me montre que le html
explose la page...
Quand tu as 20 redacteurs qui ne sont pas informaticiens pour 10 cents (des journalistes par exemple), il est plus simple qu'ils n'aient pas la main sur la mise en page. ca evite qu'une fois le titre soit en 16, une fois en 14, une fois en gras, une fois en souligné, etc.
avec spip, l'utilisateur se concentre sur le contenu et la mise en page est faite grâce aux feuilles de style.
Je suis d'accord, quand on est le seul redacteur de son blog, on aimerait avoir la possibilité de faire ce qu'on veut mais quand tu es dans une structure un peu plus importante, qui possede une charte visuelle, on ne eut pas se permettre qu'un utilisateur puisse mettre une fois un titre en Arial 18 rouge bold.
Je pense que c'est groso modo dans cet esprit la que spip est orienté. Libérer au maximum les redacteurs des contraintes graphiques qui ne sont pas forcement leur qualité principale.
Bien sur, on pourrait les former au html et au design et a tout un tas de truc. Mais ce n'est souvent pas leur metier.
Chag
--
"Ca ne marche pas" ne veut rien dire. Alors ne dites rien
"it doesn't work" means nothing. So, say nothing
A propos des mini-éditeurs qui font exploser la mise en page, il suffit que vous fassiez un petit copié collé de votre texte depuis Word (qui va vous mettre plein de balises absconnes)... Ce logiciel vous collent même des balises "invisibles"...
Donc souvent un petit effort, permet d'avoir de la Qualité, et aujourd'hui, il y a suffisamment de barre typo enrichie pour pallier à toutes les situations... et à l'usage, j'apprécie beaucoup plus l'usage de ces barres que les mini éditeurs...
Athama
chag a écrit :
AS a écrit :
C'est quand même pour ça que tant de gens fuient Spip et se réfugient
vers d'autres CMS.Que la grande majorité des blogs ne sont pas sous Spip.
Sur Wordpress faudra qu'on me montre que le html
explose la page...Quand tu as 20 redacteurs qui ne sont pas informaticiens pour 10 cents (des journalistes par exemple), il est plus simple qu'ils n'aient pas la main sur la mise en page. ca evite qu'une fois le titre soit en 16, une fois en 14, une fois en gras, une fois en souligné, etc.
avec spip, l'utilisateur se concentre sur le contenu et la mise en page est faite grâce aux feuilles de style.
Je suis d'accord, quand on est le seul redacteur de son blog, on aimerait avoir la possibilité de faire ce qu'on veut mais quand tu es dans une structure un peu plus importante, qui possede une charte visuelle, on ne eut pas se permettre qu'un utilisateur puisse mettre une fois un titre en Arial 18 rouge bold.
Je pense que c'est groso modo dans cet esprit la que spip est orienté. Libérer au maximum les redacteurs des contraintes graphiques qui ne sont pas forcement leur qualité principale.
Bien sur, on pourrait les former au html et au design et a tout un tas de truc. Mais ce n'est souvent pas leur metier.
Chag
Si je suis d'accord sur le principe, je ne suis pas d'accord sur le fond.. Sur 40.000 sites crées l'an dernier avec SPIP, combien sont ceux qui sont utilisés par des journalistes ? Bon nombre de ces sites sont soit des sites persos soit des sites pros et cela regarde directement le développeur du dit site et le webmaster. Si l'envie de faire du titre en 18 rouge lui prend, pourquoi pas? après tout ça le regarde !
Je pense que la méthode choix de l'éditeur dans la configuration générale du site serait certainement un plus pour SPIP, tout comme le fameux retour chariot..
Bernard
Le 17/07/07, AS a écrit :
C'est quand même pour ça que tant de gens fuient Spip et se réfugient
vers d'autres CMS.Que la grande majorité des blogs ne sont pas sous Spip.
Sur Wordpress faudra qu'on me montre que le html
explose la page...
<troll de l"été ?>
La fuite vers d'autres CMS. Holà, va falloir que l'on se reprenne.
Mais bon, pour les puristes, un blog n'est pas un CMS.
D'aucuns ne doivent pas beaucoup lire les archives et il est si simple
d'installer un plugin, ce qui était, le sujet initial de ce fil. Donc
avant d'ergoter, il suffit de rechercher et de lire.
Pensée émue à Josh.... 
</troll>
--
@plus
Jacques
Pour les lyonnais++ spip-lyon@rezo.net http://spip-party.net/-Lyon-
Plugins zippés Téléchargement : http://spip.jermer.fr/?Liste-des-zip-produits
Remercier Spip et les plugins (Crédits) :
http://spip.jermer.fr/?Plugin-plugins-actifs-version-5
Gérer ses squelettes & thèmes en interne :
monnaieancienne a écrit :
(...) Si l'envie de faire du titre en
18 rouge lui prend, pourquoi pas? après tout ça le regarde !
Je pense que la méthode choix de l'éditeur dans la configuration
générale du site serait certainement un plus pour SPIP, tout comme le
fameux retour chariot..
Poussons le raisonnement.
Prenons Word©®, qui est un logiciel qui contient une tripoté de
fonctionnalités (rien que moi, qui bidouille pas mal, je pense
l'utiliser à 30-40% de ses potentialités) : les gens qui font des docs
sans rien connaître du machin font des documents quasiement illisibles,
sans constance (on ne distingue pas les titres et la hiérarchie de
ceux-ci), et en plus en y passant un temps incroyable. Le wysiwyg ne
change rien pour les personnes qui ne passent pas un minimum
d'apprentissage sur le truc (d'ailleurs, un débutant sur Word©® attrape
régulièrement des crises de nerfs...).
Et je ne te parle pas d'Excel©®...
On peut mettre au crédit des concepteurs de SPIP d'obliger un minimum le
responsable du site à mettre les mains dans le cambouis, même si le
concept peut choquer ou rebuter au départ.
Bref, je ne suis pas convaincu qu'une heure d'apprentissage sur un
wysiwyg n'équivaut pas à une heure d'apprentissage sur les feuilles de
style (ou un plugin de typo)... A mon avis, c'est kif-kif...
-- Franck
Le 17 juil. 07 à 20:48, Jacques J. a écrit :
Le 17/07/07, AS a écrit :
C'est quand même pour ça que tant de gens fuient Spip et se réfugient
vers d'autres CMS.Que la grande majorité des blogs ne sont pas sous Spip.
Sur Wordpress faudra qu'on me montre que le html
explose la page...<troll de l"été ?>
La fuite vers d'autres CMS. Holà, va falloir que l'on se reprenne.
Mais bon, pour les puristes, un blog n'est pas un CMS.
D'aucuns ne doivent pas beaucoup lire les archives et il est si simple
d'installer un plugin, ce qui était, le sujet initial de ce fil. Donc
avant d'ergoter, il suffit de rechercher et de lire.
Pensée émue à Josh....
</troll>--
@plusJacques
je vais rater ça avec mon départ en congés. Heureusement, il y a les archives 
bon, pour les CMS, blogs, etc., il y a de la place pour toutes et tous et Spip n'a pas de parts de marché à conquérir, d'occasions perdues à jamais et tout le tintouin. Il faut juste une base installée minimum et une communauté minimum qui va avec pour avancer et accompagner utilisateurs, utilisatrices, développeurs et développeuses. C'est le cas, sauf erreur.
Le reste c'est se faire peur pour le plaisir.
Claude
Athama a écrit :
...plein de balises absconnes...
Mais alors, elles sont "abolument c..." ces balises !?!
JMarie
NB : c'était juste pour sourire ensemble de ces balises "absconses" !
[pub_on]
N’oubliez pas qu’il existe Spip Typo pour les fadas du Wysiwyg 
[/pub_on] Sinon, c’est vrai que le WYSIWYG XHTML a fait des progrès (XStandards, Wym, BBComposer…) les solutions ne manquent pas et le XHTML en sortie est sémantique et valide (au moins pour le premier et le dernier). Mais bon, je vois pas ça changer maintenant dans tous les sites Spip… CHOSSON Jean-Marie a écrit :
C'est quand même pour ça que tant de gens fuient Spip et se réfugient
vers d'autres CMS.Que la grande majorité des blogs ne sont pas sous Spip.
Sur Wordpress faudra qu'on me montre que le html
explose la page...
Salut , quand tu es un pro que tu fourni un site, tu fais en sorte qu'a l'utilisation ce soit le plus simple possible pour l'utilisateur ... et toujours dans le respect de la charte graphique ... car (trop) souvent quand tu laisse la main sur la présentation tu te retrouve avec tes abérrations et au bout de quelques jours de fonctionnement a peine... alors au bout de plusieurs mois...
Le principe des barres typo c'est comme dans les principaux principes de développement ( xhtml + css , MVC, ... ) , c'est de séparer les données ( le contenu de tes articles ) et leur présentation car si tu veux fournir un article en pdf ou encore en faire de l'édition papier, etc ... mets-y de l'html dedans et tu verras comme c'est beau.
Alors certes pour l'utilisateur qui connait les wysiwyg, il comprend pas tout ca mais si tu lui explique que c'est plus imple pour lui ca pose pas de problémes.
En plus avec la barre typo V2 tu as un aperçu dynamique ... certes tu vois du code mais ce n'est pas si grave puisque tu vois ce que ca donne...
Perso je conseille : barre typo V2 + enluminure typo que tu peux paramétrer a ta convenance pour rajouter tes propres styles ( ce que j'ai fait en fonction des chartes graphiques de mes sites ).
bref les barres typo c'est bon mangez-en !!!
* Franck Ducas tapotait, le 17/07/2007 21:04:
Bref, je ne suis pas convaincu qu'une heure d'apprentissage sur un
wysiwyg n'équivaut pas à une heure d'apprentissage sur les feuilles de
style (ou un plugin de typo)... A mon avis, c'est kif-kif...
+1
D'expérience, ceux qui ont réclamé (pour économiser en temps de formation) un éditeur WYSIWYG pour SPIP et l'ont eu s'en mordent les doigts 6 mois plus tard lorsqu'ils se rendent compte :
1/ Que la charte du site n'existe plus
2/ Que chaque rédacteur fait selon son propre goût
3/ Qu'il faut repasser sur chaque article pour les corriger/harmoniser
4/ Qu'il faut donc organiser la formation qu'on souhaitait justement éviter
5/ Que parce que c'est WYSIWYG, on a toutes les peines du monde à faire descendre les gens au niveau du sens et non de la forme.
A cela s'ajoute que dans une équipe où l'un des administrateurs est aveugle, ce dernier aura *vraiment* beaucoup de mal à relire le HTML généré par l'éditeur WYSIWYG...
--
RealET
coyote90@free.fr a écrit :
Il existe de plus en plus de wysiwyg pour spip
- BTE
- Tynymce
- spip-typomais lequel choisir / pourquoi ?
merci pour votre aide.
Un éditeur WYSIWYG pour SPIP ?
Vaste question et vastes interrogations (notez le « s »).
En clair, il est possible de se poser différentes questions :
Faut-il proposer un éditeur wysiwyg ou pas, et si oui pourquoi ? et si non pourquoi ?
Note pour ceux qui ne connaissent pas : wysiwyg est l’acronyme de « What you see is what you get » ou en bon français « tel écran, tel écrit » ce que tu vois sur l’écran est ce que tu auras sur le papier. Ce terme a fait les « choux gras » des logiciels de PAO à une autre grande époque.
SPIP est-il wysiwyg ?
Non et ouf… heureusement d’ailleurs. Pour rédiger le contenu d’un texte il faut insérer un certain nombre de « balises » pas très compliquées à apprendre.
Oui… mais les balises c’est du code ? non ?
Ben… euh… oui c’est du code mais tu sais c’est facile les raccourcis avec SPIP.
Ah bon et comment on fait ? ben… tu vois… tu sélectionnes ton texte et ensuite tu cliques sur le bouton là.
Ah bon… et les {{ qui apparaissent là c’est quoi ?
ben c’est des balises.
Pfff…
Nous sommes ici rendus dans la partie la plus difficile à appréhender et expliquer à un rédacteur occasionnel de contenu éditorial avec SPIP (ou avec un autre CMS d’ailleurs).
Et alors là, il faut argumenter et tout ça…
Et là le formateur commence à avoir une belle paire de rames…
« Bon alors, les gars, je vais vous expliquer… Oubliez Word et ne vous faites pas d’illusions. On ne rédige pas sur le web comme dans Word. Et voilà pourquoi »
Un outil de gestion de contenu n’est pas un traitement de texte. Trop souvent, les auteurs de la partie privée d’un site web de mise en ligne de contenu considèrent que le texte se manipule comme dans un traitement de texte (comme Word par exemple). Ainsi par exemple, ils abusent de l’utilisation des caractères gras ou italiques, de la couleur et de la justification du texte et du multicolonnage.
Ils pensent qu’il en est de même pour le texte d’un site web destiné à être affiché sur un écran.
Cette affirmation est erronée, le texte d’un article se manipule en suivant un certain nombre de règles simples. Ces dernières utilisent une logique qui consiste à rajouter des balises pour préciser la mise en forme du texte. Un moyen qui se révèle puissant à l’usage
Cette méthode peut sembler rebutante de prime abord mais – bien comprise – se révèle à l’usage plus puissante et plus facile à mettre en oeuvre.
Les raisons qui justifient cette méthode
- On ne lit pas sur un écran comme sur le papier
Lire sur écran est plus fatiguant que sur le papier, en particulier si la mise en forme du texte est trop chargée. Il est à noter que l’on parle ici de mise en forme et non pas de mise en page.
- Le langage d’affichage utilisé est limité
Le langage d’affichage d’une page web (le langage HTML) n’est pas adapté à une mise en page « rigide » comme le serait un traitement de texte.
- Les performances d’affichage
La simulation d’une mise en page comme un traitement de texte est envisageable mais elle alourdit considérablement un article et affecte les performances d’affichage. Par ailleurs une mise en forme complexe va provoquer des dysfonctionnements dans la présentation du texte en fonction du logiciel navigateur utilisé.
- Un souci d’homogénéité
Laisser trop de possibilités aux rédacteurs pour modifier la mise en forme du texte nuit à la cohérence entre les différents articles du site web. Cette remarque est d’autant plus pertinente si le nombre de rédacteurs est conséquent. Il y en qui resteront "sobres" et d'autres qui vont écrire des articles qui ressemblent à des arbres de Noël..
- Penser accessibilité
Un site web se doit d’être accessible à toute personne quel que soit son âge, son expérience et ses capacités physiques. Par extension, l’affichage des informations du site doit être adapté à la non ou mal voyance ainsi qu’au handicap physique. Ainsi, par exemple, la taille des caractères doit pouvoir être augmentée à la demande. Dans cette situation, il n’est pas concevable d’envisager une « mise en page » trop rigide.
---------------------------------------------------------------
Oui mais nous, on voudrait bien avoir un éditeur wysiwyg, M'sieu.
---------------------------------------------------------------
Bon… OK, il existe des plugins qui peuvent faire cela très bien.
Personnellement j’en connais au moins deux que j’ai trituré un peu beaucoup.
L’objectif est tout de même de répondre à ta question et d’apporter des arguments – ou du moins – des pistes de solutions.
FCKEditor et TinyMCE.
L’idée de base est qu’un article SPIP peut contenir du code HTML.
Certe…
Sans hésitation si tu es devant l’alternative – et je n’engage que moi – prend TinyMCE qui est à la fois le plus complet et le plus simple à utiliser. FCKEditor a trop d’icônes et prendra plus de temps à être expliqué que d’apprendre à utiliser des balises SPIP – tiens c’est curieux non ?
J’avais un lien vers une étude sur les éditeurs wysiwyg du « marché » avec comparatif et tout et tout… s’il faut, je peux le retrouver… TinyMCE arrivait bon premier.
C’est par ailleurs l’éditeur choisit par Claroline c’est dire si c’est bien.
Avantage d’une solution FCK ou Tiny – Ok on fait ce que l’on veut mais il faut un plugin.
FCKEditor ? sûrement pas, y a trop d’icônes… c’est trop confusant pour mes secrétaires de mairies.
TinyMCE ? oui peut-être s'il faut vraiment…
En revanche, il y a un sacré inconvénient qui est de ne pouvoir mixer facilement du code SPIP dans un texte avec le code HTML généré par l’éditeur wysiwyg. Par ailleurs si tu désactive le plug-in que deviennent les articles en HTML qui deviennent alors "inbitable" pour le rédacteur moyen.
En fait – et de toi à moi – je me suis aperçu d’une chose. Si tu veux arriver à convaincre et expliquer les raccourcis de SPIP – il suffit de faire de bonnes fiches de formation qui vont bien.
Le souci provient précisément lorsque SPIP se retrouve un peu « à la rue » dans le cadre de traitements d’affichage HTML un peu particuliers.
Un exemple ? ben… euh… les tableaux.
Gérer un tableau complexe avec des fonds de couleurs etc. SPIP est très juste je l’avoue.
Un autre exemple est l'utilisation de cartes dites "mappées" qu'il est dommage de ne pas utiliser dans certains cas.
Alors faut-il un éditeur wysiwyg pour cela ?
J’ai essayé et j’ai retourné le truc dans tous les sens en gardant le rédacteur lambda en tête, ni FCK ni Tiny n’arrive au niveau d’un Dreamweaver pour t’appuyer des tableaux en tr/td bien caca beurk pour un puriste mais tellement efficace pour contenter le client parce que ça va vite.
Créer des cartes mappée avec Dream est un jeu d'enfant.
Ensuite tu colle le fichier HTML produit dans le texte de ton article et le tour est joué. En plus depuis la 1.9.2 tu peux même y glisser subrepticement du JavaScript, ça va fonctionner. OK c’est laid mais c’est efficace et le client est content. Et il est possible - dans ce cas - d'envisager une partie de ton texte en "codes SPIP" et une autre en HTML.
OK garçon, tu es gentil mais Dreamwaever c’est payant non ?
Ben… euh… oui
Alors on fait quoi ?
NVU ? NVU – si mes souvenirs sont exacts – n’aime pas trop SPIP.
Et Tonton BP, il fait comment ?
J’ai investigué pour mes clients une solution qui se ramenait au déroulé suivant :
1 – On explique et on forme sur le fait que les raccourcis SPIP – c’est le mieux
2 – On utilise les raccourcis SPIP en suivant les fiches de formation ad hoc.
3 - On glisse en catimini quelques infos au rédacteur éclairé comme quoi si dans le texte d'un article SPIP il place une balise HTML ou deux il ne sera pas cloué au pilori du genre <font color="red"> bla bla </font>
4 – S’il y a un besoin spécifique – l’exemple ci–dessus des tableaux - on cherche un "outil" alternatif extérieur de façon à ne pas surcharger le site de plugins.
5 – Eh… s’il te plait, le truc alternatif - gratuit…
Personnellement comme truc alternatif j’ai choisi l’outil libre SeaMonkey qui est très bien pour monter des tableaux ou des cartes mappées pour pas un sou.
OK c’est laid de placer du HTML dans un article mais c’est efficace
Et pour méditer à la plage, l'apophtegme N°12 de Tonton BP :
"S'il existe une solution alternative à un plug-in - outil extérieur, utilisation des modèles SPIP, CSS alternative etc. Oublie le plug in..."
Tonton BP
Bonjour,
à titre d'exemple : voilà ce qu'on peut obtenir quand on met en place un plugin avec éditeur WYSIWYG (FCKeditor pour ne pas le citer) puis qu'on change la charte graphique :
http://clg-mendesfrance-valdereuil.ac-rouen.fr/public/cyberjournal/spip.php?article533
En conclusion, terminé le WYSIWYG pour mes prochains rédacteurs.
Je n'aurais même pas dû mettre ça en place, je le regrette maintenant car c'est moi qui vais me coltiner tout le boulot pour supprimer les balises html gènantes.
Cordialement, Olivier Gautier.
BPE a écrit :
coyote90@free.fr a écrit :
Il existe de plus en plus de wysiwyg pour spip
- BTE
- Tynymce
- spip-typomais lequel choisir / pourquoi ?
merci pour votre aide.
Un éditeur WYSIWYG pour SPIP ?
Vaste question et vastes interrogations (notez le « s »).
En clair, il est possible de se poser différentes questions :
Faut-il proposer un éditeur wysiwyg ou pas, et si oui pourquoi ? et si non pourquoi ?
Note pour ceux qui ne connaissent pas : wysiwyg est l’acronyme de « What you see is what you get » ou en bon français « tel écran, tel écrit » ce que tu vois sur l’écran est ce que tu auras sur le papier. Ce terme a fait les « choux gras » des logiciels de PAO à une autre grande époque.SPIP est-il wysiwyg ?
Non et ouf… heureusement d’ailleurs. Pour rédiger le contenu d’un texte il faut insérer un certain nombre de « balises » pas très compliquées à apprendre.
Oui… mais les balises c’est du code ? non ?
Ben… euh… oui c’est du code mais tu sais c’est facile les raccourcis avec SPIP.
Ah bon et comment on fait ? ben… tu vois… tu sélectionnes ton texte et ensuite tu cliques sur le bouton là.
Ah bon… et les {{ qui apparaissent là c’est quoi ?
ben c’est des balises.Pfff…
Nous sommes ici rendus dans la partie la plus difficile à appréhender et expliquer à un rédacteur occasionnel de contenu éditorial avec SPIP (ou avec un autre CMS d’ailleurs).
Et alors là, il faut argumenter et tout ça…
Et là le formateur commence à avoir une belle paire de rames…
« Bon alors, les gars, je vais vous expliquer… Oubliez Word et ne vous faites pas d’illusions. On ne rédige pas sur le web comme dans Word. Et voilà pourquoi »Un outil de gestion de contenu n’est pas un traitement de texte. Trop souvent, les auteurs de la partie privée d’un site web de mise en ligne de contenu considèrent que le texte se manipule comme dans un traitement de texte (comme Word par exemple). Ainsi par exemple, ils abusent de l’utilisation des caractères gras ou italiques, de la couleur et de la justification du texte et du multicolonnage.
Ils pensent qu’il en est de même pour le texte d’un site web destiné à être affiché sur un écran.
Cette affirmation est erronée, le texte d’un article se manipule en suivant un certain nombre de règles simples. Ces dernières utilisent une logique qui consiste à rajouter des balises pour préciser la mise en forme du texte. Un moyen qui se révèle puissant à l’usage
Cette méthode peut sembler rebutante de prime abord mais – bien comprise – se révèle à l’usage plus puissante et plus facile à mettre en oeuvre.Les raisons qui justifient cette méthode
- On ne lit pas sur un écran comme sur le papier
Lire sur écran est plus fatiguant que sur le papier, en particulier si la mise en forme du texte est trop chargée. Il est à noter que l’on parle ici de mise en forme et non pas de mise en page.
- Le langage d’affichage utilisé est limité
Le langage d’affichage d’une page web (le langage HTML) n’est pas adapté à une mise en page « rigide » comme le serait un traitement de texte.
- Les performances d’affichage
La simulation d’une mise en page comme un traitement de texte est envisageable mais elle alourdit considérablement un article et affecte les performances d’affichage. Par ailleurs une mise en forme complexe va provoquer des dysfonctionnements dans la présentation du texte en fonction du logiciel navigateur utilisé.
- Un souci d’homogénéité
Laisser trop de possibilités aux rédacteurs pour modifier la mise en forme du texte nuit à la cohérence entre les différents articles du site web. Cette remarque est d’autant plus pertinente si le nombre de rédacteurs est conséquent. Il y en qui resteront "sobres" et d'autres qui vont écrire des articles qui ressemblent à des arbres de Noël..
- Penser accessibilité
Un site web se doit d’être accessible à toute personne quel que soit son âge, son expérience et ses capacités physiques. Par extension, l’affichage des informations du site doit être adapté à la non ou mal voyance ainsi qu’au handicap physique. Ainsi, par exemple, la taille des caractères doit pouvoir être augmentée à la demande. Dans cette situation, il n’est pas concevable d’envisager une « mise en page » trop rigide.
---------------------------------------------------------------
Oui mais nous, on voudrait bien avoir un éditeur wysiwyg, M'sieu.
---------------------------------------------------------------
Bon… OK, il existe des plugins qui peuvent faire cela très bien.Personnellement j’en connais au moins deux que j’ai trituré un peu beaucoup.
L’objectif est tout de même de répondre à ta question et d’apporter des arguments – ou du moins – des pistes de solutions.
FCKEditor et TinyMCE.
L’idée de base est qu’un article SPIP peut contenir du code HTML.
Certe…
Sans hésitation si tu es devant l’alternative – et je n’engage que moi – prend TinyMCE qui est à la fois le plus complet et le plus simple à utiliser. FCKEditor a trop d’icônes et prendra plus de temps à être expliqué que d’apprendre à utiliser des balises SPIP – tiens c’est curieux non ?
J’avais un lien vers une étude sur les éditeurs wysiwyg du « marché » avec comparatif et tout et tout… s’il faut, je peux le retrouver… TinyMCE arrivait bon premier.
C’est par ailleurs l’éditeur choisit par Claroline c’est dire si c’est bien.Avantage d’une solution FCK ou Tiny – Ok on fait ce que l’on veut mais il faut un plugin.
FCKEditor ? sûrement pas, y a trop d’icônes… c’est trop confusant pour mes secrétaires de mairies.
TinyMCE ? oui peut-être s'il faut vraiment…En revanche, il y a un sacré inconvénient qui est de ne pouvoir mixer facilement du code SPIP dans un texte avec le code HTML généré par l’éditeur wysiwyg. Par ailleurs si tu désactive le plug-in que deviennent les articles en HTML qui deviennent alors "inbitable" pour le rédacteur moyen.
En fait – et de toi à moi – je me suis aperçu d’une chose. Si tu veux arriver à convaincre et expliquer les raccourcis de SPIP – il suffit de faire de bonnes fiches de formation qui vont bien.
Le souci provient précisément lorsque SPIP se retrouve un peu « à la rue » dans le cadre de traitements d’affichage HTML un peu particuliers.
Un exemple ? ben… euh… les tableaux.
Gérer un tableau complexe avec des fonds de couleurs etc. SPIP est très juste je l’avoue.
Un autre exemple est l'utilisation de cartes dites "mappées" qu'il est dommage de ne pas utiliser dans certains cas.Alors faut-il un éditeur wysiwyg pour cela ?
J’ai essayé et j’ai retourné le truc dans tous les sens en gardant le rédacteur lambda en tête, ni FCK ni Tiny n’arrive au niveau d’un Dreamweaver pour t’appuyer des tableaux en tr/td bien caca beurk pour un puriste mais tellement efficace pour contenter le client parce que ça va vite.
Créer des cartes mappée avec Dream est un jeu d'enfant.
Ensuite tu colle le fichier HTML produit dans le texte de ton article et le tour est joué. En plus depuis la 1.9.2 tu peux même y glisser subrepticement du JavaScript, ça va fonctionner. OK c’est laid mais c’est efficace et le client est content. Et il est possible - dans ce cas - d'envisager une partie de ton texte en "codes SPIP" et une autre en HTML.OK garçon, tu es gentil mais Dreamwaever c’est payant non ?
Ben… euh… oui
Alors on fait quoi ?
NVU ? NVU – si mes souvenirs sont exacts – n’aime pas trop SPIP.Et Tonton BP, il fait comment ?
J’ai investigué pour mes clients une solution qui se ramenait au déroulé suivant :
1 – On explique et on forme sur le fait que les raccourcis SPIP – c’est le mieux
2 – On utilise les raccourcis SPIP en suivant les fiches de formation ad hoc.
3 - On glisse en catimini quelques infos au rédacteur éclairé comme quoi si dans le texte d'un article SPIP il place une balise HTML ou deux il ne sera pas cloué au pilori du genre <font color="red"> bla bla </font>
4 – S’il y a un besoin spécifique – l’exemple ci–dessus des tableaux - on cherche un "outil" alternatif extérieur de façon à ne pas surcharger le site de plugins.
5 – Eh… s’il te plait, le truc alternatif - gratuit…Personnellement comme truc alternatif j’ai choisi l’outil libre SeaMonkey qui est très bien pour monter des tableaux ou des cartes mappées pour pas un sou.
OK c’est laid de placer du HTML dans un article mais c’est efficace
Et pour méditer à la plage, l'apophtegme N°12 de Tonton BP :
"S'il existe une solution alternative à un plug-in - outil extérieur, utilisation des modèles SPIP, CSS alternative etc. Oublie le plug in..."Tonton BP
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ
Je trouve cette discussion assez stérile dans la mesure où nous savons tous que Spip ne passera pas en wysiwyg...Mais bon pour démontrer que certains rédacteurs en faisant un simple copier/coller arrivent AUSSI à utiliser fckeditor:
http://palabres.la-plume-et-lencrier.com/article.php3?id_article=124
Je continue à penser qu'on peut faire comme on veut, mais il faut bien connaître les risques. Le message qui suit démontre bien que le rédacteur qui écrit en bleu pale sur fond blanc n'en a pas grand chose à faire et qu'après tout le webmaster n'a qu'à se débrouiller...Lamentable.
J'espère Olivier que tu n'en as pas 300 comme ça!
Bernard
Olivier Gautier a écrit :
Bonjour,
à titre d'exemple : voilà ce qu'on peut obtenir quand on met en place un plugin avec éditeur WYSIWYG (FCKeditor pour ne pas le citer) puis qu'on change la charte graphique :
http://clg-mendesfrance-valdereuil.ac-rouen.fr/public/cyberjournal/spip.php?article533En conclusion, terminé le WYSIWYG pour mes prochains rédacteurs.
Je n'aurais même pas dû mettre ça en place, je le regrette maintenant car c'est moi qui vais me coltiner tout le boulot pour supprimer les balises html gènantes.Cordialement, Olivier Gautier.
BPE a écrit :
coyote90@free.fr a écrit :
Il existe de plus en plus de wysiwyg pour spip
- BTE
- Tynymce
- spip-typomais lequel choisir / pourquoi ?
merci pour votre aide.
Un éditeur WYSIWYG pour SPIP ?
Vaste question et vastes interrogations (notez le « s »).
En clair, il est possible de se poser différentes questions :
Faut-il proposer un éditeur wysiwyg ou pas, et si oui pourquoi ? et si non pourquoi ?
Note pour ceux qui ne connaissent pas : wysiwyg est l’acronyme de « What you see is what you get » ou en bon français « tel écran, tel écrit » ce que tu vois sur l’écran est ce que tu auras sur le papier. Ce terme a fait les « choux gras » des logiciels de PAO à une autre grande époque.SPIP est-il wysiwyg ?
Non et ouf… heureusement d’ailleurs. Pour rédiger le contenu d’un texte il faut insérer un certain nombre de « balises » pas très compliquées à apprendre.
Oui… mais les balises c’est du code ? non ?
Ben… euh… oui c’est du code mais tu sais c’est facile les raccourcis avec SPIP.
Ah bon et comment on fait ? ben… tu vois… tu sélectionnes ton texte et ensuite tu cliques sur le bouton là.
Ah bon… et les {{ qui apparaissent là c’est quoi ?
ben c’est des balises.Pfff…
Nous sommes ici rendus dans la partie la plus difficile à appréhender et expliquer à un rédacteur occasionnel de contenu éditorial avec SPIP (ou avec un autre CMS d’ailleurs).
Et alors là, il faut argumenter et tout ça…
Et là le formateur commence à avoir une belle paire de rames…
« Bon alors, les gars, je vais vous expliquer… Oubliez Word et ne vous faites pas d’illusions. On ne rédige pas sur le web comme dans Word. Et voilà pourquoi »Un outil de gestion de contenu n’est pas un traitement de texte. Trop souvent, les auteurs de la partie privée d’un site web de mise en ligne de contenu considèrent que le texte se manipule comme dans un traitement de texte (comme Word par exemple). Ainsi par exemple, ils abusent de l’utilisation des caractères gras ou italiques, de la couleur et de la justification du texte et du multicolonnage.
Ils pensent qu’il en est de même pour le texte d’un site web destiné à être affiché sur un écran.
Cette affirmation est erronée, le texte d’un article se manipule en suivant un certain nombre de règles simples. Ces dernières utilisent une logique qui consiste à rajouter des balises pour préciser la mise en forme du texte. Un moyen qui se révèle puissant à l’usage
Cette méthode peut sembler rebutante de prime abord mais – bien comprise – se révèle à l’usage plus puissante et plus facile à mettre en oeuvre.Les raisons qui justifient cette méthode
- On ne lit pas sur un écran comme sur le papier
Lire sur écran est plus fatiguant que sur le papier, en particulier si la mise en forme du texte est trop chargée. Il est à noter que l’on parle ici de mise en forme et non pas de mise en page.
- Le langage d’affichage utilisé est limité
Le langage d’affichage d’une page web (le langage HTML) n’est pas adapté à une mise en page « rigide » comme le serait un traitement de texte.
- Les performances d’affichage
La simulation d’une mise en page comme un traitement de texte est envisageable mais elle alourdit considérablement un article et affecte les performances d’affichage. Par ailleurs une mise en forme complexe va provoquer des dysfonctionnements dans la présentation du texte en fonction du logiciel navigateur utilisé.
- Un souci d’homogénéité
Laisser trop de possibilités aux rédacteurs pour modifier la mise en forme du texte nuit à la cohérence entre les différents articles du site web. Cette remarque est d’autant plus pertinente si le nombre de rédacteurs est conséquent. Il y en qui resteront "sobres" et d'autres qui vont écrire des articles qui ressemblent à des arbres de Noël..
- Penser accessibilité
Un site web se doit d’être accessible à toute personne quel que soit son âge, son expérience et ses capacités physiques. Par extension, l’affichage des informations du site doit être adapté à la non ou mal voyance ainsi qu’au handicap physique. Ainsi, par exemple, la taille des caractères doit pouvoir être augmentée à la demande. Dans cette situation, il n’est pas concevable d’envisager une « mise en page » trop rigide.
---------------------------------------------------------------
Oui mais nous, on voudrait bien avoir un éditeur wysiwyg, M'sieu.
---------------------------------------------------------------
Bon… OK, il existe des plugins qui peuvent faire cela très bien.Personnellement j’en connais au moins deux que j’ai trituré un peu beaucoup.
L’objectif est tout de même de répondre à ta question et d’apporter des arguments – ou du moins – des pistes de solutions.
FCKEditor et TinyMCE.
L’idée de base est qu’un article SPIP peut contenir du code HTML.
Certe…
Sans hésitation si tu es devant l’alternative – et je n’engage que moi – prend TinyMCE qui est à la fois le plus complet et le plus simple à utiliser. FCKEditor a trop d’icônes et prendra plus de temps à être expliqué que d’apprendre à utiliser des balises SPIP – tiens c’est curieux non ?
J’avais un lien vers une étude sur les éditeurs wysiwyg du « marché » avec comparatif et tout et tout… s’il faut, je peux le retrouver… TinyMCE arrivait bon premier.
C’est par ailleurs l’éditeur choisit par Claroline c’est dire si c’est bien.Avantage d’une solution FCK ou Tiny – Ok on fait ce que l’on veut mais il faut un plugin.
FCKEditor ? sûrement pas, y a trop d’icônes… c’est trop confusant pour mes secrétaires de mairies.
TinyMCE ? oui peut-être s'il faut vraiment…En revanche, il y a un sacré inconvénient qui est de ne pouvoir mixer facilement du code SPIP dans un texte avec le code HTML généré par l’éditeur wysiwyg. Par ailleurs si tu désactive le plug-in que deviennent les articles en HTML qui deviennent alors "inbitable" pour le rédacteur moyen.
En fait – et de toi à moi – je me suis aperçu d’une chose. Si tu veux arriver à convaincre et expliquer les raccourcis de SPIP – il suffit de faire de bonnes fiches de formation qui vont bien.
Le souci provient précisément lorsque SPIP se retrouve un peu « à la rue » dans le cadre de traitements d’affichage HTML un peu particuliers.
Un exemple ? ben… euh… les tableaux.
Gérer un tableau complexe avec des fonds de couleurs etc. SPIP est très juste je l’avoue.
Un autre exemple est l'utilisation de cartes dites "mappées" qu'il est dommage de ne pas utiliser dans certains cas.Alors faut-il un éditeur wysiwyg pour cela ?
J’ai essayé et j’ai retourné le truc dans tous les sens en gardant le rédacteur lambda en tête, ni FCK ni Tiny n’arrive au niveau d’un Dreamweaver pour t’appuyer des tableaux en tr/td bien caca beurk pour un puriste mais tellement efficace pour contenter le client parce que ça va vite.
Créer des cartes mappée avec Dream est un jeu d'enfant.
Ensuite tu colle le fichier HTML produit dans le texte de ton article et le tour est joué. En plus depuis la 1.9.2 tu peux même y glisser subrepticement du JavaScript, ça va fonctionner. OK c’est laid mais c’est efficace et le client est content. Et il est possible - dans ce cas - d'envisager une partie de ton texte en "codes SPIP" et une autre en HTML.OK garçon, tu es gentil mais Dreamwaever c’est payant non ?
Ben… euh… oui
Alors on fait quoi ?
NVU ? NVU – si mes souvenirs sont exacts – n’aime pas trop SPIP.Et Tonton BP, il fait comment ?
J’ai investigué pour mes clients une solution qui se ramenait au déroulé suivant :
1 – On explique et on forme sur le fait que les raccourcis SPIP – c’est le mieux
2 – On utilise les raccourcis SPIP en suivant les fiches de formation ad hoc.
3 - On glisse en catimini quelques infos au rédacteur éclairé comme quoi si dans le texte d'un article SPIP il place une balise HTML ou deux il ne sera pas cloué au pilori du genre <font color="red"> bla bla </font>
4 – S’il y a un besoin spécifique – l’exemple ci–dessus des tableaux - on cherche un "outil" alternatif extérieur de façon à ne pas surcharger le site de plugins.
5 – Eh… s’il te plait, le truc alternatif - gratuit…Personnellement comme truc alternatif j’ai choisi l’outil libre SeaMonkey qui est très bien pour monter des tableaux ou des cartes mappées pour pas un sou.
OK c’est laid de placer du HTML dans un article mais c’est efficace
Et pour méditer à la plage, l'apophtegme N°12 de Tonton BP :
"S'il existe une solution alternative à un plug-in - outil extérieur, utilisation des modèles SPIP, CSS alternative etc. Oublie le plug in..."Tonton BP
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ
------------------------------------------------------------------------No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 17/07/2007 18:30
BPE a écrit :
ou en bon français « tel écran, tel écrit » ce
<troll>
en bon francais, on dit TATI :
Tel Affiché, Tel Imprimé....
</troll>
Le mercredi 18 juillet 2007, Jean-Marc Viglino a écrit :
BPE a écrit :
> ou en bon français « tel écran, tel écrit » ce<troll>
en bon francais, on dit TATI :
Tel Affiché, Tel Imprimé....
</troll>
j'adore !!!
--
Cordialement, Daniel Cartron
« Quand on ne peut pas apprécier ce qu'on a, il vaut mieux avoir ce qu'on peut
apprécier.»
Bernard Shaw - Pygmalion
Je trouve cette discussion assez stérile dans la mesure où nous savons
tous que Spip ne passera pas en wysiwyg...
Bonjour,
Il y a pas mal de temps, j'ai été un "emmerd..." parce que je cherchais en
vain à avoir un éditeur wysiwyg, c'était surtout pour les tableaux. Depuis
le temps (v. 1.7), spip a énormément évolué et même si j'ai pesté localement
à l'époque contre les développeurs (mea culpa), je dois reconnaître que
l'avenir leur a donné raison. Avec les barres typographiques actuelles, les
besoins fondamentaux sont couverts et le fond reste prioritaire par rapport
à la forme. C'est d'ailleurs ce qui, sur le moyen et long terme, fait le
succès d'un site. Le "tape-à-l'œil" n'a qu'une brève existence et correspond
à notre société de consommation.
Cordialement.
Samuel Perrin
samper@netplus.ch
-----Message d'origine-----
De : spip-bounces@rezo.net [mailto:spip-bounces@rezo.net] De la part de
monnaieancienne
Envoyé : mercredi, 18. juillet 2007 13:02
À : spip@rezo.net
Objet : Re: [Spip] Trans.: quel editeur wysiwyg pour spip ?Je trouve cette discussion assez stérile dans la mesure où nous savons
tous que Spip ne passera pas en wysiwyg...Mais bon pour démontrer que
certains rédacteurs en faisant un simple copier/coller arrivent AUSSI à
utiliser fckeditor:
http://palabres.la-plume-et-lencrier.com/article.php3?id_article=124Je continue à penser qu'on peut faire comme on veut, mais il faut bien
connaître les risques. Le message qui suit démontre bien que le
rédacteur qui écrit en bleu pale sur fond blanc n'en a pas grand chose à
faire et qu'après tout le webmaster n'a qu'à se débrouiller...Lamentable.
J'espère Olivier que tu n'en as pas 300 comme ça!Bernard