Tests et avis sur les Page Builder

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    pour l'export Json, tu passes par quoi? un plug-in dédié?
    Fonction d'import/export intégrée au pagebuilder

    Envoyé par Tortue Genial 69 Voir le message
    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...

    Envoyé par Tortue Genial 69 Voir le message
    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
    Dernière édition par dolmenhir à 06/12/2019, 16h50

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    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.

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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

    Envoyé par Tortue Genial 69 Voir le message
    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

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    Envoyé par dolmenhir Voir le message
    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

    Envoyé par dolmenhir Voir le message
    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é. ?

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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é.

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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.

    Envoyé par dolmenhir Voir le message
    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

    Envoyé par dolmenhir Voir le message
    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é.

    Envoyé par dolmenhir Voir le message
    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?
    ​​​​​​​

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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...

    Envoyé par Tortue Genial 69 Voir le message
    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.

    Envoyé par Tortue Genial 69 Voir le message
    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
    Dernière édition par dolmenhir à 06/12/2019, 12h29

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    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 :

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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

    Envoyé par dolmenhir Voir le message
    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?

    Envoyé par dolmenhir Voir le message
    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
    Dernière édition par Tortue Genial 69 à 06/12/2019, 10h14

    Laisser un commentaire:


  • dolmenhir
    a répondu
    Salut,
    Envoyé par Tortue Genial 69 Voir le message
    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.

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    Envoyé par GraphiqueDesign Voir le message
    Ce que je nomme "page statique", c'est une page qui n'a que très peu de chance d'être modifiée fréquemment, une page de présentation d'un site vitrine par exemple. En général, on y touche plus trop une fois en ligne, enfin dans mon monde.

    Une page non statique, pour reprendre ton expression, c'est une page que selon moi, on modifie sans cesse, comme les pages d'un blog par exemple. De plus, c'est l'utilisateur final qui intervient à ce niveau, contrairement à la page statique où selon moi, c'est au Web Designer de porter les modifications, si possible, celui qui a conçu le site. Les enrichissements typographiques, le graphisme, etc, je considère que l'utilisateur final n'a pas forcément les compétences graphiques pour intervenir sur les pages statiques. D'ailleurs, pourquoi aurait il sollicité les services d'un Web Designer s'il pouvait le faire lui-même ...

    Oui, pour les pages statiques donc, j'utilise les outils de texte et de mise en page du PageBuilder qui propose une multitude de réglages (dont typographiques) pour donner au rendu final de la page, un esthétisme irréprochable et attrayant. Par contre, pour les pages non statiques, je préfère utiliser les articles et les outils natifs de Joomla qui sont eux, totalement adaptés à l'utilisateur final. L'esthétique de ces pages est sous-jacent puisque soumis au fichier custom.css, l'utilisateur final ne fait dans ce cas, que rentrer des informations sans trop se soucier de la mise en page.

    Un PB permet de faire de belles choses en un minimum de temps, c'est selon moi un outil de productivité qui demande une certaine maitrise. Il doit aussi n'être utilisé que là où son usage est le plus productif et adapté.
    Re,

    Je reviens sur ce que tu disais car j'ai pris un peu de temps pour re-décomposer les choses, suite à certaines demandes clients récentes.
    En effet je comprends la différence entre les 2 et je fais plus ou moins pareil actuellement (sauf que j'utilise pas encore de page builder).

    Page statique : c'est l'admin qui modifie via page builder
    Page dynamique : c'est le client qui gère et la mise en page est celle du template au final (via custom.css)

    Mais en fait c'est pas toujours simple de différencier les 2.
    J'ai eu de récentes demandes ou cela n'a pas été simple de catégoriser les pages car peu après avoir mis le site en ligne, le client à voulu modifier lui même certains réglages, mais ce n'était pas possible car il n'était pas censé le faire.

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

    - on a besoin d'une mise en page dédiée
    - mais c'est du contenu pur car le client peu rajouter des blocs
    - mais il ne l'a modifie pas tous les jours non plus

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

    Du coup la frontière entre les 2 types de pages devient très mince...

    Cliquez sur l'image pour l'afficher en taille normale  Nom : img.png  Affichages : 0  Taille : 80,2 Ko  ID : 2010493

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    hello,

    petit up sur le sujet.
    est ce que certains ont tésté nicepage ?
    je l'ai testé en surface, mais je manque de recul..donc si certains ont des retours

    merci

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    Envoyé par RobertG Voir le message
    Je viens de vérifier : en ce qui concerne PageBuilder CK, les données du contenu principal sont dans la table "#__content", mais des infos complémentaires dans une table de PageBuilder.
    J'essaierai peut-être de désinstaller PBCK pour voir ce que donne cette suppression au niveau du rendu.

    Bon, je viens de faire le test : aucune perte sinon celle de la disposition.
    Il s'agit d'un site de test a minima, recettes de cuisine, qui ne comportent qu'une image d'entête, du contenu et un module ou champ complémentaire pour les ingrédients, avec la version free du composant (sans le plugin "Parameters" donc). Les ingrédients définis sous PBCK comme devant s'afficher dans la colonne de droite de l'article se retrouvent sous le texte principal.

    Il faudrait tester avec des compositions plus complexes, mais je reste persuadé que le contenu ne sera pas perdu en cas de désinstallation de PBCK.
    good news deja !

    Laisser un commentaire:


  • RobertG
    a répondu
    Je viens de vérifier : en ce qui concerne PageBuilder CK, les données du contenu principal sont dans la table "#__content", mais des infos complémentaires dans une table de PageBuilder.
    J'essaierai peut-être de désinstaller PBCK pour voir ce que donne cette suppression au niveau du rendu.

    Bon, je viens de faire le test : aucune perte sinon celle de la disposition.
    Il s'agit d'un site de test a minima, recettes de cuisine, qui ne comportent qu'une image d'entête, du contenu et un module ou champ complémentaire pour les ingrédients, avec la version free du composant (sans le plugin "Parameters" donc). Les ingrédients définis sous PBCK comme devant s'afficher dans la colonne de droite de l'article se retrouvent sous le texte principal.

    Il faudrait tester avec des compositions plus complexes, mais je reste persuadé que le contenu ne sera pas perdu en cas de désinstallation de PBCK.
    Dernière édition par RobertG à 12/09/2019, 15h17

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    ok je vois mieux ta définition des choses.
    je comprends tout à fait la séparation que tu fais entre les deux, mais je trouve que ce n'est pas la bonne approche, enfin d'après ce que j'ai comme retours de mon coté, ce qui est tout à fait subjectif je te l'accorde.
    je pense que la tendance est à rendre l'utilisateur de plus en plus autonome sur le contenu uniquement..quoi que..je vais y revenir.

    dans un premier temps, je suis d'accord que si une personne fait appel à un intégrateur ou webmaster, ce n'est pas pour le faire lui même.
    le soucis est que, je trouve, de plus en plus de personnes demandent à pouvoir faire des modifications simples par elles mêmes, qui malheureusement ne sont souvent pas accessibles simplement.

    le meilleur exemple est la mise en page d'une page.
    même si le client n'est pas qualifié pour faire du CSS, il a très souvent besoin de pouvoir faire des petites ajustements lui même.
    exemple, mettre une image à gauche et du texte à droite, faire des colonnes, des marges, travailler un peu des images etc....

    et la, si tu sépares les pages comme tu le fais, tu seras tôt ou tard embêté car le jour ou il voudra modifier une page que tu n'as pas prévue comme ça, c'est vite le bazar.
    après cela dépend bien évidemment du type de clients que tu adresses.

    je pense que l'utilisateur doit se concentrer sur le contenu et sa mise en forme et le webmaster/intégrateur sur la mise en place du site en terme de structure.
    bien que lorsqu'on livre un site, il est généralement remplit de contenu, par la suite le client va inévitablement vouloir se faire des modifs lui même.

    le problème n'est pas simple et je n'ai pas répondu à tous les problèmes je l'admet.
    c'est pour ça qu'un page builder est interréssant car il permet de gagner en productivité (coté intégrateur/webmaster) mais aussi d’éventuellement donner un peu de liberté au client..moyennant formation car la prise en main n'est pas toujours plug & play.

    sinon, et c'est la que je n'arrive pas à y voir clair, c'est que le page builder permettrait de concevoir la structure/la mise en page, mais si le client doit se cantonner au contenu, il faudrait que cela reste dans les articles joomla car beaucoup plus simple à prendre en main pour lui.

    d'ou ma question : est-il possible avec un page builder de créer la structure des pages et de garder le contenu dans joomla?

    Laisser un commentaire:


  • GraphiqueDesign
    a répondu
    Envoyé par Tortue Genial 69 Voir le message
    en fait ce n'est pas le sens de ma question, je vais essayer d'être plus clair désolé

    déjà qu'entends tu par pages statiques ?
    quel distinguo fais-tu entre page statique et non statique ?
    donc si je comprends bien, les textes de tes pages sont directement dans le page builder et pas dans les articles joomla?

    en effet on trouve toujours une solution, mais pas nécessairement la plus adaptée pour l'utilisateur final
    Ce que je nomme "page statique", c'est une page qui n'a que très peu de chance d'être modifiée fréquemment, une page de présentation d'un site vitrine par exemple. En général, on y touche plus trop une fois en ligne, enfin dans mon monde.

    Une page non statique, pour reprendre ton expression, c'est une page que selon moi, on modifie sans cesse, comme les pages d'un blog par exemple. De plus, c'est l'utilisateur final qui intervient à ce niveau, contrairement à la page statique où selon moi, c'est au Web Designer de porter les modifications, si possible, celui qui a conçu le site. Les enrichissements typographiques, le graphisme, etc, je considère que l'utilisateur final n'a pas forcément les compétences graphiques pour intervenir sur les pages statiques. D'ailleurs, pourquoi aurait il sollicité les services d'un Web Designer s'il pouvait le faire lui-même ...

    Oui, pour les pages statiques donc, j'utilise les outils de texte et de mise en page du PageBuilder qui propose une multitude de réglages (dont typographiques) pour donner au rendu final de la page, un esthétisme irréprochable et attrayant. Par contre, pour les pages non statiques, je préfère utiliser les articles et les outils natifs de Joomla qui sont eux, totalement adaptés à l'utilisateur final. L'esthétique de ces pages est sous-jacent puisque soumis au fichier custom.css, l'utilisateur final ne fait dans ce cas, que rentrer des informations sans trop se soucier de la mise en page.

    Un PB permet de faire de belles choses en un minimum de temps, c'est selon moi un outil de productivité qui demande une certaine maitrise. Il doit aussi n'être utilisé que là où son usage est le plus productif et adapté.

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    ajout du page builder T4 de Joomlart !
    qui n'est peut-être pas encore en version stable.
    Dernière édition par Tortue Genial 69 à 10/09/2019, 13h58

    Laisser un commentaire:


  • Tortue Genial 69
    a répondu
    en fait ce n'est pas le sens de ma question, je vais essayer d'être plus clair désolé

    déjà qu'entends tu par pages statiques ?
    quel distinguo fais-tu entre page statique et non statique ?
    donc si je comprends bien, les textes de tes pages sont directement dans le page builder et pas dans les articles joomla?

    en effet on trouve toujours une solution, mais pas nécessairement la plus adaptée pour l'utilisateur final
    Dernière édition par Tortue Genial 69 à 10/09/2019, 13h33

    Laisser un commentaire:

Annonce

Réduire
1 sur 2 < >

C'est [Réglé] et on n'en parle plus ?

A quoi ça sert ?
La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
Comment ajouter la mention [Réglé] à votre discussion ?
1 - Aller sur votre discussion et éditer votre premier message :


2 - Cliquer sur la liste déroulante Préfixe.

3 - Choisir le préfixe [Réglé].


4 - Et voilà… votre discussion est désormais identifiée comme réglée.

2 sur 2 < >

Assistance au forum - Outil de publication d'infos de votre site

Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

UTILISER À VOS PROPRES RISQUES :
L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

Problèmes connus :
FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

Installation :

1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

Archive zip : https://github.com/AFUJ/FPA/zipball/master

2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
et remplacer www. votresite .com par votre nom de domaine


Exemples:
Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/
Pour executer le script: http://www..com/fpa-fr.php

Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/cms/
Pour executer le script: http://www..com/cms/fpa-fr.php

En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
Voir plus
Voir moins

Partenaire de l'association

Réduire

Hébergeur Web PlanetHoster
Travaille ...
X