Tests et avis sur les Page Builder

[dolmenhir]

Tu préconises quoi? ton avis?

S'il s'agit d'un onepage que ton client devra éditer depuis le frontpage, alors je te conseille de faire une page SPPB plutôt qu'un article.
Pourquoi ?
Pour la simple et bonne raison qu'une fois loggué pour pouvoir éditer la page, il ne verra qu'un seul bouton d'édition, alors qu'avec un article il en verra 2 : celui de SPPB et le bouton "modifier" de Joomla", ce qui peut le perturber et conduire à des erreurs.

Le principal intérêt d'utiliser SPPB pour les articles, c'est que les articles peuvent continuer de fonctionner en mode blog, puisque SPPB permet de faire cohabiter le texte (et l'image) d'intro, réalisé via l'éditeur Joomla, et le contenu détaillé via le pagebuilder.

Dol.

NB : je prépare, pour les jours prochains, un live-vidéo de présentation de sppb

[Tortue Genial 69]

dolmenhir hello, j'aurai une petite question pour toi.
je teste pas mal SP Page Builder en ce moment et si par exemple je veux faire un simple site One Page.
quel est l'interet ou la différence ou je sais pas entre :

- réaliser ma page via le menu spécifique SP PAGE BUILDER ?
- ou réaliser ma page directement dans l'article joomla en cliquant sur le bouton SP PAGE BUILDER ?

dans les 2 cas, le résultat est le même car je peux par exemple importer un des bundle proposés.
mais quid si le client veut mettre à jour lui même son contenu comme son simple article?

Tu préconises quoi? ton avis?

merci

[Tortue Genial 69]

personnellement, je trouve que l'ergonomie de pagebuilder_ck est vraiment pas terrible.
l'outil à l'air très puissant, mais pour mettre entre les mains d'un client qui lui aura besoin de quelque chose de plus simple/sexy/user friendly, je trouve que c'est pas au niveau de SP page builder ou même nicepage.
après cela n'enlève en rien les qualités techniques et fonctionnelles du produit, c'est juste l'approche look and feel.

[lefabdu51]

Nicepage a quand meme un code bien plus propre que son prédecesseur. Et de plus le code correspond mieux au CMS. tu as un plugin joomla et un WP. donc déja ce n est plus le même code pour les deux. MAis bon ca ne vaux pas le pagebuilder_ck

[dolmenhir]

apres quand tu dis Avec nicepage, j'ai testé la version composant, et j'ai des pages à la place de mes articles, et rien d'autre tu veux dire qu'il met toute la page dans un article?

Exactement

[Tortue Genial 69]

ok merci de ton retour c'est impec.
en effet SP page builder me semble quand même plus aboutit...ne serait ce que les modules.

pour le chevauchement, je suis aussi de cet avis.
et c'est le problème sur beaucoup de mises en formes...lors du passage au responsive y'a beaucoup de réglages à faire.
le problème du code généré est aussi embettant...car générer trop de code pour pas grand chose c'est plus pénalisant qu'autre chose (seo, perfs, etc...)

apres quand tu dis Avec nicepage, j'ai testé la version composant, et j'ai des pages à la place de mes articles, et rien d'autre tu veux dire qu'il met toute la page dans un article?

[dolmenhir]

dans la mesure ou le template est la pour fournir la structure/positions et le page builder le coté design et mise en page, c'est sur que pas besoin de 10 000 templates.
par contre tu entends quoi par : certains ayant besoin de faire tourner des pages "classiques", des composants, etc...

Les PageBuilder ne sont pas faits pour mettre en forme le contenu des composants.
Donc un site dont le contenu s'appuie pour l'essentiel sur un ou plusieurs composants n'utilisera un pagebuilder que pour des besoins isolé, au mieux pour une page d'accueil.

pour nicepage ok je vois.
mais typiquement, nicepage VS SP page builder, j'avoue que j'ai quand même du mal à voir les différences...

Il y a en beaucoup, puisqu'il ne fonctionnent pas de la même manière.
Avec SP PageBuilder, comme je te l'ai expliqué précédemment, je peux basculer d'une méthode à l'autre dans un article.
Je peux même exploiter les deux dans des pages blog (intro d'un côté, builder de l'autre), j'ai la possibilité de l'utiliser dans des modules, de créer des sections réutilisables, d'avoir des blocs capable d'afficher des modules ou des articles.
Avec nicepage, j'ai testé la version composant, et j'ai des pages à la place de mes articles, et rien d'autre.

par exemple nicepage semble permettre de faire chevaucher des éléments les uns sur les autres assez simplement, est-ce le cas sur SP page builder?

Oui. Comme je l'ai expliqué, c'est une méthode qui ne date pas d'hier.
On peut attribuer des classes et des id aux lignes, aux blocs etc... donc avec du css bien construit on peut rapidement faire la même chose.
SP PageBuilder intègre même des fonctions pour articuler les blocs entre eux et leur permettre de se superposer les uns par rapport aux autres.
Mais là encore, dans une édition en frontend, l'aperçu est en temps réel : tu déplaces en haut, en bas, devant, derrière et du vois instantanément le rendu. (voir image)



Cependant faut garder à l'esprit que ce type de graphisme ne tient pas longtemps face au "responsive". Cet habillage, quel que soit l'outil utilisé, va rapidement sauter dès que le support d'affichage ne sera pas adapté.
Pour le code, beaucoup de code pour peu de texte.
Sur une page type, j'ai pris un de leur modèle par défaut et j'obtiens un ratio code/text de 2% (de texte par rapport à l'ensemble du code) ce qui est très faible puisqu'il est conseillé d'avoir au moins 10%.

Après, perso je suis très bien avec SP pagebuilder, mais je peux comprendre que certains ne lui trouveront pas le même intérêt et en préféreront un autre.
Les pages Builder c'est comme les chaussures : ce qui va bien aux uns ne va pas forcément aux autres.
Et comme les chaussures, il vaut mieux les essayer avant.

[Tortue Genial 69]

ok pour le Json, je regarderai ça sur SP Page builder...mais c'est une bonne idée je trouve.

dans la mesure ou le template est la pour fournir la structure/positions et le page builder le coté design et mise en page, c'est sur que pas besoin de 10 000 templates.
par contre tu entends quoi par : certains ayant besoin de faire tourner des pages "classiques", des composants, etc...

pour nicepage ok je vois.
mais typiquement, nicepage VS SP page builder, j'avoue que j'ai quand même du mal à voir les différences...
par exemple nicepage semble permettre de faire chevaucher des éléments les uns sur les autres assez simplement, est-ce le cas sur SP page builder?
c'est juste un exemple, mais leurs mises à jour semblent assez soutenus et actives.
ils font pas mal d'update et le produit évolue vite.
après coté code généré faudrait voir ce que ça donne.

t'en dis quoi?

[dolmenhir]

pour l'export Json, tu passes par quoi? un plug-in dédié?

Fonction d'import/export intégrée au pagebuilder

c'est vrai que SP page builder pro à l'air top...du coup au final tu n'as besoin que d'un seul template (helix dans ton cas) et tu fais juste varier le contenu avec les blocs du page builder?

Oui, dans les grandes lignes.
Après t'adaptes bien sûr tout ça en fonction du projet et de ses besoins, certains ayant besoin de faire tourner des pages "classiques", des composants, etc...

du coup j'aimerai bien avoir ton avis sur ce que nicepage appelle le web desgin 3.0 : https://nicepage.com/doc/article/265...t-so-different

c'est vrai que leur solution est intéressante, car le placement d'un élément ne se limite pas à une grille, mais peut chevaucher d'autres éléments.

Ils n'on rien inventé.
ça existe depuis longtemps le principe des layers.
Tu te sers d'attibuts css pour positionner des div, img... à coup de position relative ou absolute et tu les superposes au pixel près tout en leur donnant une valeur z-index qui déterminera leur position dans le mille-feuille (valeur élevée = dessus, valeur basse = dessous...).

Pour nicepage, j'ai pas testé, mais des gens qui me mettent du Artisteer, Wix et Webbly... dans la catégorie "websites builders", puis du photoshop ou adobe xd dans la catégorie "graphic designers" pour, in fine, me faire une fusion donnant naissance à une catégorie "website designers" où prédomine nicepage, c'est à mes yeux des gens qui manquent un peu d'objectivité, de sens critique et de modestie.

De plus se prétendre innovant avec un pompeux "web design 3.0" qui est en fait du réchauffé avec un principe qui remonte au css2... et continuer à me balancer du -webkit dans leur feuilles de style...
Je te dirai pas ce que je pense, mais faut pas être devin pour le deviner

[Tortue Genial 69]

ok super merci pour ces retours c'est très clair.
j'avais pas vu que SP page builder avait un module qui permettait de créer du contenu issu du page builder dans le module directement...malin car pas lié juste au composant

pour l'export Json, tu passes par quoi? un plug-in dédié?

c'est vrai que SP page builder pro à l'air top...du coup au final tu n'as besoin que d'un seul template (helix dans ton cas) et tu fais juste varier le contenu avec les blocs du page builder?
du coup j'aimerai bien avoir ton avis sur ce que nicepage appelle le web desgin 3.0 : https://nicepage.com/doc/article/265...t-so-different

c'est vrai que leur solution est intéressante, car le placement d'un élément ne se limite pas à une grille, mais peut chevaucher d'autres éléments.

[dolmenhir]

De mon coté je n'exporte pas en Json, mais ayant les sauvegardes de l'hébergeur + celles que je fais moi en plus dans le cloud (Google Drive via Rclone), je peux tout remonter sans problème.
Et de mémoire, ce n'est jamais encore arrivé...tant mieux pour le moment

Le coup du fichier json, c'est un chouïa + rapide, puisque ça se fait en 2 clics.
Et surtout on ne touche que ça : remonter une sauvegarde t'oblige à annuler toutes les modifications, même les bonnes.

par contre tu entends quoi par il y a même un type de module dédié. ?

C'est un module, c'est comme un module personnalisé, qui permet de produire du contenu mais mis en forme avec toutes les fonctionnalités du PageBuilder
Et évidement, qui dit module, dit transversalité potentielle

tu veux dire que l'article joomla contient l'intro + le lien lire la suite et le page builder contient l'article complet?

Oui Môssieur, parfaitement

du coup, avec un page builder, tu n'utilises aucun template stylle yootheme ou joomlart ni aucun framework du coup? pas besoin?

Si si, ça me permet d'aller + vite, et par exemple de sortir un site dans la journée, voire moins selon le projet.
Pour l'heure j'utilise Helix Ultimate de Joomshaper, ceux là me^me qui éditent SP PageBuilder.
Je garde un oeil sur les autres, et plus particulièrement sur Astroïd (un problème de vitesse).
GridBox de Balbooa est intéressant aussi, mais très atypique par rapport aux autres.
De tous c'est Gantry que j'aime le moins, suivi de T3, mais j'attend de voir le T4
Je pourrais cependant parfois me contenter d'un simple Protostar ou pondre mon propre Template si nécessaire.
Je réfléchit d'ailleurs à me faire mon propre Framework, histoire de sortir un code + propre, parce que c'est un des défauts des frameworks actuels.

alors la, du coup, si tu créé par exemple un bloc slider avec un page builder, comment tu l'assignes à plusieurs pages sans le dupliquer physiquement?
car un slider positionné via un module, peut être assigné à plusieurs pages sans être dupliqué.

Plusieurs solutions :
- tu peux créer un module qui exploite les fonctionnalités du Page Builder. Du coup tu peux l'affecter comme n'importe quel module
- tu peux sauvegarder un bloc, une ligne, un addon réalisé dans une page sous Pabebuilder, et le réutiliser dans une autre page d'un simple clic.

A noter que dans ce Pagebuilder tu peux placer un addon de type module.
Donc tu peux aussi faire un module avec le pagebuilder, qui contient lui même un module, etc... et le placer dans une page, ou plusieurs si tu l'as sauvegarder pour le ré-utiliser.

ce point m'intéresse, tu gères ça comment?

avec JCE, et cela retaille les images à la volée lors de l'upload
JCE > Profil > Paramètres de l'éditeur > Fichier système > Edition de l'image

[Tortue Genial 69]

L'utilisateur peux mettre les mains dedans s'il le souhaite. Mais comme pour les articles, s'il fait des bêtises, il devra assumer.
Mais en fait j'anticipe puisqu'une fois les pages statiques faites et livrées, je les exporte au format json.
Si le client, bien que préalablement formé, "casse" quelque chose, je n'ai qu'à importer le json pour retrouver ma page telle qu'elle était avant que le client n'intervienne.
Sous oublier les sauvegardes quotidiennes s'il a fait une très grosse bêtise.

De mon coté je n'exporte pas en Json, mais ayant les sauvegardes de l'hébergeur + celles que je fais moi en plus dans le cloud (Google Drive via Rclone), je peux tout remonter sans problème.
Et de mémoire, ce n'est jamais encore arrivé...tant mieux pour le moment

Ensuite, un outil comme SP PageBuilder permet d'être utilisé directement dans l'article (en fait on découvre un onglet qui permet de basculer entre le mode d'édition classique et le pagebuilder) et il y a même un type de module dédié.

Ok ça c'est cool en effet.
par contre tu entends quoi par il y a même un type de module dédié. ?

A savoir que SP Pagebuilder, quand on s'en sert dans un article, copie/colle le contenu de certains blocks (ceux qui ont du contenu de type texte) dans la partie d'édition classique.
Cela signifie que si jamais on désactive ou supprime le pagebuilder, ces contenus ne sont pas perdus, même s'il faudra reprendre leur mise en forme.

oui pratique en effet, dans le cas d'un changement de page builder...au moins on perd pas tout.

Il est également possible d'avoir un mix très utile pour les blog :
- saisir un texte d'intro,
- placer une ligne de rupture "lire la suite"
- éditer l'article complet avec le pagebuilder

tu veux dire que l'article joomla contient l'intro + le lien lire la suite et le page builder contient l'article complet?
ou j'ai raté un truc la

En fait j'ai un peu menti... les articles ultra basique, comme les mentions légales ou la politique de confidentialité, c'est généralement des articles simples via l'éditeur classique de Joomla!
Un peu de style appliqué aux chapitres, et sous-chapitres via l'éditeur avancé et ça suffit.

yes idem pour moi.

Le builder sera plutôt utilisé sur des pages "statiques" qui nécessitent une petite mise en forme spéciale, plus simple à faire avec le builder qu'avec un article standard, genre un page de contact avec des coordonnées à gauche sur 1/3 de la page et un formulaire à droite sur les 2/3 restant, et en dessus un plan de localisation dynamique type GG map.

oui c'est clairement le top pour ça.

Mais l'emploi de champs personnalisés et l'arrivée de nouvelles fonctionnalités dans la v4 de Joomla, va me conduire à reconsidérer le traitement et l'organisation de certains contenus.

idem j'attends de voir ce que ça donner, mais l'emploi d'un page builder sera toujours utile je pense.
du coup, avec un page builder, tu n'utilises aucun template stylle yootheme ou joomlart ni aucun framework du coup? pas besoin?

Ce qui est radicalement différent c'est la prévisualisation de l'article en même temps qu'on le saisi et avant même de le valider et donc d'écraser l'ancien contenu.
Avec un joomla classique, en front comme en back, on édite le contenu via l'éditeur avancé mais il faut valider pour voir la page se remettre en forme avec tous les éléments qui la composent.
Avec un builder, on édite dans la mise en forme et toutes les modifications se visualisent sans avoir à sauvegarder.
On ne sauvegarde la page qu'à la fin, quand on est content du rendu final.

oui c'est vrai que y'a cet aspect visu en live qui est très bien c'est clair.

A noter qu'une page réalisée avec un page builder peut intégrer des bloc de différentes natures, comme un slider, un formulaire, un compteur à rebours, un tableau de prix, une fiche client, des contenus en accordéon, etc... et toutes les modifications de ces éléments se font là aussi avec une une prévisualisation en temps réel, sous les yeux de l'utilisateur.

alors la, du coup, si tu créé par exemple un bloc slider avec un page builder, comment tu l'assignes à plusieurs pages sans le dupliquer physiquement?
car un slider positionné via un module, peut être assigné à plusieurs pages sans être dupliqué.

Avec du Joomla classique, il faut éditer l'article, puis aller voir du côté des modules pour, par exemple, modifier le slider, le formulaire, etc...

c'est sur que c'est la contre-partie en effet.

Ben en terme de sécurité, je préfère laisser les utilisateurs sur le front et limiter les accès à l'admin.
Le client, ce dont il a généralement besoin, c'est un accès au contenu, textes et images.
Lui ouvrir la porte de l'admin, même de manière étroite, ne me semble pas nécessaire, voire imprudent même si j'ai, là aussi, un certain nombre de garde-fous.
C'est d'ailleurs pour ça que par défaut dans Joomla! peu de groupes ont accès au back-office. Et on ne s'improvise pas administrateur sans une bonne petite formation à Joomla.
L'accès aux menus, aux utilisateurs, aux extensions... vaut mieux pas si la personne ne sait pas exactement ce que cela implique.
Toucher aux menus ça peut flinguer une mise en page, pénaliser le référencent, bref être dangereux, et généralement la plupart de sites que je conçois n'ont ce type de besoin (ou alors mes clients me contactent).
Et s'il faut créer un profil d'accès au back-end en limitant l'accès aux zones sensibles, autant passer par le front.

je comprends, mais la j'avoue que j'ai le raisonnement inverse et jamais eu de soucis avec l'accès au back-office, ni pour le clients.
au contraire tout est centralisé au sein d'une même IHM, donc bon...question d'approche et d'usage au final.

Dropeditor a l'air sympa, mais encore une fois, je conçois des sites pour des gens qui n'ont pas vraiment la maîtrise de ces outils, même s'ils ont droit à une formation préalable.
Je configure énormément de chose en amont pour leur simplifier la vie et leur éviter de faire des bêtises.

DropEditor est très simple à utiliser, pas besoin de connaissance..sauf une mini formation.
pour ma part j'ai une chaine youtube avec des vidéo tutoriels pour les clients ou je présente l'utilisation de chaque composant.
les retours sont bons à priori

La configuration des profils me permet de ne laisser dans l'éditeur que le strict nécessaire, ce qui le rend très simple d'utilisation.
L'upload des images se fait dans un dossier dédié et étanche du reste du contenu du dossier images (mais auquel moi j'ai accès).
Idem pour les fichiers, importés dans un dossier à part des images pour ne pas tout mélanger.
Les types de fichiers autorisés sont prédéfinis, et exit les .doc, .xls, etc. Sur les sites c'est du jpg, png, pdf et basta.

idem pour moi, sauf pour les extensions ou j'en tolère un poil plus car c'est un besoin qui a été remonté.

Les images ont des dimensions d'import prédéfinies, adaptées à la structure des pages du site.

ce point m'intéresse, tu gères ça comment?
je veux dire que tu re-taille à la volée les images que les users envoient?
ou tu forces les dimensions via du CSS?

[dolmenhir]

mais si jamais du jour au lendemain il leur prend l'envie de mettre les mains dedans, comment tu gères?

L'utilisateur peux mettre les mains dedans s'il le souhaite. Mais comme pour les articles, s'il fait des bêtises, il devra assumer.
Mais en fait j'anticipe puisqu'une fois les pages statiques faites et livrées, je les exporte au format json.
Si le client, bien que préalablement formé, "casse" quelque chose, je n'ai qu'à importer le json pour retrouver ma page telle qu'elle était avant que le client n'intervienne.
Sous oublier les sauvegardes quotidiennes s'il a fait une très grosse bêtise.

Ensuite, un outil comme SP PageBuilder permet d'être utilisé directement dans l'article (en fait on découvre un onglet qui permet de basculer entre le mode d'édition classique et le pagebuilder) et il y a même un type de module dédié.
A savoir que SP Pagebuilder, quand on s'en sert dans un article, copie/colle le contenu de certains blocks (ceux qui ont du contenu de type texte) dans la partie d'édition classique.
Cela signifie que si jamais on désactive ou supprime le pagebuilder, ces contenus ne sont pas perdus, même s'il faudra reprendre leur mise en forme.

Il est également possible d'avoir un mix très utile pour les blog :
- saisir un texte d'intro,
- placer une ligne de rupture "lire la suite"
- éditer l'article complet avec le pagebuilder

On peut alors afficher une page de blog de catégorie classique, qui affichera l'intro, et en cliquant sur le "lire la suite" on tombera sur la page mise en forme avec le builder.

donc pour la partie dynamique tu utilises les articles?
et pour la partie statique page builder?

En fait j'ai un peu menti... les articles ultra basique, comme les mentions légales ou la politique de confidentialité, c'est généralement des articles simples via l'éditeur classique de Joomla!
Un peu de style appliqué aux chapitres, et sous-chapitres via l'éditeur avancé et ça suffit.
Le builder sera plutôt utilisé sur des pages "statiques" qui nécessitent une petite mise en forme spéciale, plus simple à faire avec le builder qu'avec un article standard, genre un page de contact avec des coordonnées à gauche sur 1/3 de la page et un formulaire à droite sur les 2/3 restant, et en dessus un plan de localisation dynamique type GG map.
Mais l'emploi de champs personnalisés et l'arrivée de nouvelles fonctionnalités dans la v4 de Joomla, va me conduire à reconsidérer le traitement et l'organisation de certains contenus.

ok je vois, mais par contre tu peux déjà le faire en donnant les droits d'accès aux articles depuis le front-end.
donc c'est pareil au final non?

Non.
Ce qui est radicalement différent c'est la prévisualisation de l'article en même temps qu'on le saisi et avant même de le valider et donc d'écraser l'ancien contenu.
Avec un joomla classique, en front comme en back, on édite le contenu via l'éditeur avancé mais il faut valider pour voir la page se remettre en forme avec tous les éléments qui la composent.
Avec un builder, on édite dans la mise en forme et toutes les modifications se visualisent sans avoir à sauvegarder.
On ne sauvegarde la page qu'à la fin, quand on est content du rendu final.
A noter qu'une page réalisée avec un page builder peut intégrer des bloc de différentes natures, comme un slider, un formulaire, un compteur à rebours, un tableau de prix, une fiche client, des contenus en accordéon, etc... et toutes les modifications de ces éléments se font là aussi avec une une prévisualisation en temps réel, sous les yeux de l'utilisateur.
Avec du Joomla classique, il faut éditer l'article, puis aller voir du côté des modules pour, par exemple, modifier le slider, le formulaire, etc...
Rien que pour ça, le page builder c'est le champion de l'édition.

pour ma part, j'ai jamais voulu ouvrir l'accès au front-end et ce pour 2 raisons :
- coté sécurité : cela permet d'ouvrir une "brèche" potentielle...toutes proportions gardées bien entendu, mais çà retire un "point of failure" comme in dit ( ou SPOF pour les intimes )
- coté apprentissage : le fait de cloisonner l'utilisateur au back-offce permet au client d'avoir accès a d'autres fonctions comme l'ajout de liens de menus etc...perso cela m'a été demandé. de plus, pas de tuning CSS à faire dans le back-office, contrairement au front-end ou si tu veu une cohérence graphique, il faut retoucher des choses..maintenant c'est un choix perso

Ben en terme de sécurité, je préfère laisser les utilisateurs sur le front et limiter les accès à l'admin.
Le client, ce dont il a généralement besoin, c'est un accès au contenu, textes et images.
Lui ouvrir la porte de l'admin, même de manière étroite, ne me semble pas nécessaire, voire imprudent même si j'ai, là aussi, un certain nombre de garde-fous.
C'est d'ailleurs pour ça que par défaut dans Joomla! peu de groupes ont accès au back-office. Et on ne s'improvise pas administrateur sans une bonne petite formation à Joomla.
L'accès aux menus, aux utilisateurs, aux extensions... vaut mieux pas si la personne ne sait pas exactement ce que cela implique.
Toucher aux menus ça peut flinguer une mise en page, pénaliser le référencent, bref être dangereux, et généralement la plupart de sites que je conçois n'ont ce type de besoin (ou alors mes clients me contactent).
Et s'il faut créer un profil d'accès au back-end en limitant l'accès aux zones sensibles, autant passer par le front.

Pour ma part j'utilise cet éditeur que je trouve très bien coté ergonomie : https://www.joomunited.com/products/dropeditor
Combiné a DropFiles pour les fichiers : https://www.joomunited.com/products/dropfiles
Et DropPics pour les images : https://www.joomunited.com/products/droppics

J'ai utilisé JCE depuis toujours (donc depuis + de 10 ans en gros) et j'ai changé il y a peu.
La raison : bien que JCE soit incroyablement stable et efficace, je trouve (et d'après des retours clients) qu'il est à la ramasse coté approche et ergonomie.
Les clients avaient beaucoup de mal à faire des choses simples, soit par Drag & Drop soit par simples click.
De plus la gestion des images et fichiers est trop techniques, il y'a trop d'options et le rendu visuel n'est pas top (et j'utilisais pourtant des profils restreints pour les clients).
JCE s'est récemment amélioré avec la gestion des colonnes etc..mais il n'est pas très user friendly je trouve.

Dropeditor a l'air sympa, mais encore une fois, je conçois des sites pour des gens qui n'ont pas vraiment la maîtrise de ces outils, même s'ils ont droit à une formation préalable.
Je configure énormément de chose en amont pour leur simplifier la vie et leur éviter de faire des bêtises.
Et pour ça, JCE me semble parfaitement adapté.
Comme toi je le pratique depuis très longtemps (depuis qu'il existe en fait). J'en ai donc une excellente maîtrise.
La configuration des profils me permet de ne laisser dans l'éditeur que le strict nécessaire, ce qui le rend très simple d'utilisation.
L'upload des images se fait dans un dossier dédié et étanche du reste du contenu du dossier images (mais auquel moi j'ai accès).
Idem pour les fichiers, importés dans un dossier à part des images pour ne pas tout mélanger.
Les types de fichiers autorisés sont prédéfinis, et exit les .doc, .xls, etc. Sur les sites c'est du jpg, png, pdf et basta.
Les images ont des dimensions d'import prédéfinies, adaptées à la structure des pages du site.
Même les vidéos transitent par YT histoire de ne pas surcharger le serveur d'hébergement et de simplifier leur intégration.
Et bien sûr le poids maximal de chaque type de fichier est également défini, pour éviter de voir débarquer un pdf de 5 Go...

Du est-ce que dans ton ou tes page builder tu peux utiliser un éditeur tiers style JCE ou DropEditor?

Dropeditor je sais pas, j'ai pas essayé, mais TinyMCE ou JCE oui, parfaitement.

Oui c'est possible en effet, mais ça reste carrément moins intuitif pour le client.
Je fais déjà énormément de choses avec du CSS, mais tôt ou tard il faudra mettre les mains dedans.

La majorité de mes clients veulent quelque chose de simple, facile et rapide.
Donc un champ texte, un ou deux clic pour l'image, idem pour un fichier ou une vidéo, et voilà.
Ensuite, au fil du temps, pour ceux qui pratiquent régulièrement, les besoins peuvent croître et donc des fonctionnalités apparaître, mais ça reste assez marginal.
Et puis je ne suis jamais bien loin

[Tortue Genial 69]

Merci pour ce retour, c'est cool de voir comment travaillent les autres ça permet de mettre les choses en perspectives

Juste quelques précisions :

Pour les + petits et les moins actualisés, ce n'est que du page builder.

ok why not, ca permet d'être plus rapide...mais si jamais du jour au lendemain il leur prend l'envie de mettre les mains dedans, comment tu gères?

S
Pour les autres c'est un mix, entre la partie "dynamique" (parties du site où il y a de fréquentes màj comme les actus) et la partie "statique" où on trouve des contenu comme les mentions légales, la politique de confidentialité, etc.

donc pour la partie dynamique tu utilises les articles?
et pour la partie statique page builder?

Mais j'ai des sites en "full page builder" que les clients peuvent modifier eux-même, de façon simple et ergonomique, depuis le front-end, avec en plus la possibilité de voir, en direct-live et avant validation, le rendu de la modification.
C'est un vrai + par rapport aux articles "classiques" et un vrai confort pour les clients.

ok je vois, mais par contre tu peux déjà le faire en donnant les droits d'accès aux articles depuis le front-end.
donc c'est pareil au final non?

pour ma part, j'ai jamais voulu ouvrir l'accès au front-end et ce pour 2 raisons :

- coté sécurité : cela permet d'ouvrir une "brèche" potentielle...toutes proportions gardées bien entendu, mais çà retire un "point of failure" comme in dit ( ou SPOF pour les intimes )
- coté apprentissage : le fait de cloisonner l'utilisateur au back-offce permet au client d'avoir accès a d'autres fonctions comme l'ajout de liens de menus etc...perso cela m'a été demandé. de plus, pas de tuning CSS à faire dans le back-office, contrairement au front-end ou si tu veu une cohérence graphique, il faut retoucher des choses..maintenant c'est un choix perso

Le niveau de manipulation est également relativement simple quand le client ne cherche pas à pousser les murs.
S'il s'en tient à modifier les textes et images, ça va. Mais s'il veut ajouter des lignes, des blocs et des colonnes, là il faudra préalablement l'avoir formé à l'outil, même si les builder actuel sont relativement intuitifs et ergonomiques.

Pour ma part j'utilise cet éditeur que je trouve très bien coté ergonomie : https://www.joomunited.com/products/dropeditor
Combiné a DropFiles pour les fichiers : https://www.joomunited.com/products/dropfiles
Et DropPics pour les images : https://www.joomunited.com/products/droppics

J'ai utilisé JCE depuis toujours (donc depuis + de 10 ans en gros) et j'ai changé il y a peu.
La raison : bien que JCE soit incroyablement stable et efficace, je trouve (et d'après des retours clients) qu'il est à la ramasse coté approche et ergonomie.
Les clients avaient beaucoup de mal à faire des choses simples, soit par Drag & Drop soit par simples click.
De plus la gestion des images et fichiers est trop techniques, il y'a trop d'options et le rendu visuel n'est pas top (et j'utilisais pourtant des profils restreints pour les clients).
JCE s'est récemment amélioré avec la gestion des colonnes etc..mais il n'est pas très user friendly je trouve.

Du est-ce que dans ton ou tes page builder tu peux utiliser un éditeur tiers style JCE ou DropEditor?

Pour ton exemple de page "classiques", avec une feuille de style bien pensée et quelques classes bien placées, l'utilisateur pourrait faire ça de façon simple en plaçant :
- l'image 1
- le texte 1
- l'image 2
- le texte 2

sans même chercher à faire la moindre mise en forme, ou presque.
C'est toute la force des CSS

A savoir que l'éditeur JCE permet de générer des templates de contenu, réutilisables à volonté.
Il y a aussi l'extension "content templater" de Regular labs qui mérite un petit détour.

Dol.

Oui c'est possible en effet, mais ça reste carrément moins intuitif pour le client.
Je fais déjà énormément de choses avec du CSS, mais tôt ou tard il faudra mettre les mains dedans.

Je vais jeter un oeil sur content templater merci

[dolmenhir]

Salut,

Typiquement, comment tu fais ou ferais, pour permettre à un client de faire la mise en page ci-dessous, simplement, sans page builder?

[...]

Le page builder semble adapté, mais cela impose un niveau de manipulation plus avancé que de remplir un simple article.

Moi j'utilise les deux fonctions sur de nombreux projets.
Pour les + petits et les moins actualisés, ce n'est que du page builder.

Pour les autres c'est un mix, entre la partie "dynamique" (parties du site où il y a de fréquentes màj comme les actus) et la partie "statique" où on trouve des contenu comme les mentions légales, la politique de confidentialité, etc.

Mais j'ai des sites en "full page builder" que les clients peuvent modifier eux-même, de façon simple et ergonomique, depuis le front-end, avec en plus la possibilité de voir, en direct-live et avant validation, le rendu de la modification.
C'est un vrai + par rapport aux articles "classiques" et un vrai confort pour les clients.

Le niveau de manipulation est également relativement simple quand le client ne cherche pas à pousser les murs.
S'il s'en tient à modifier les textes et images, ça va. Mais s'il veut ajouter des lignes, des blocs et des colonnes, là il faudra préalablement l'avoir formé à l'outil, même si les builder actuel sont relativement intuitifs et ergonomiques.

Pour ton exemple de page "classiques", avec une feuille de style bien pensée et quelques classes bien placées, l'utilisateur pourrait faire ça de façon simple en plaçant :
- l'image 1
- le texte 1
- l'image 2
- le texte 2

sans même chercher à faire la moindre mise en forme, ou presque.
C'est toute la force des CSS

A savoir que l'éditeur JCE permet de générer des templates de contenu, réutilisables à volonté.
Il y a aussi l'extension "content templater" de Regular labs qui mérite un petit détour.

Dol.