Tests et avis sur les Page Builder

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

  • #31
    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
    Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
    Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
    Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

    Commentaire


    • #32
      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?
      Expert en conception et réalisation de sites Internet 100% Joomla
      www.toonetcreation.com

      Commentaire


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

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

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

        Cliquez sur l'image pour l'afficher en taille normale

Nom : sppb-zindex.png 
Affichages : 145 
Taille : 166,1 Ko 
ID : 2010673

        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.
        Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
        Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
        Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

        Commentaire


        • #34
          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?
          Expert en conception et réalisation de sites Internet 100% Joomla
          www.toonetcreation.com

          Commentaire


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

            Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
            Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
            Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

            Commentaire


            • #36
              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

              Commentaire


              • #37
                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.
                Expert en conception et réalisation de sites Internet 100% Joomla
                www.toonetcreation.com

                Commentaire


                • #38
                  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
                  Expert en conception et réalisation de sites Internet 100% Joomla
                  www.toonetcreation.com

                  Commentaire


                  • #39
                    Envoyé par Tortue Genial 69 Voir le message
                    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
                    Dernière édition par dolmenhir à 11/02/2020, 07h30
                    woluweb aime ceci.
                    Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
                    Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
                    Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

                    Commentaire


                    • #40
                      merci pour ton retour.

                      déjà la vidéo m’intéresse grandement

                      pour ce qui est de l'usage, déjà pour ma part, aucun client n'édite le site depuis le front-end (pour un tas de raisons de centralisation d'accès, de mise en forme, de design, de sécurité, etc...c'est pas le débat ici). donc tout le monde passe par le back-office.

                      l'idée des 2 boutons ne me gène pas, car j'ai déjà fais une demande à JoomShaper pour pouvoir les traduire...ils vont remonter ça au dev pour le faire.
                      en gros mon idée est d'avoir :

                      - le bouton JOOMLA EDITOR qui sera traduit en ÉDITEUR SIMPLE
                      - le bouton SP PAGE BUILDER qui sera traduit en ÉDITEUR AVANCE

                      Je suis conscient que cela peut rajouter de la difficulté, mais tout dépend comment cela est géré.
                      surtout que chaque éditeur ne répond pas aux mêmes besoin et j'ai de plus en plus de remontées de clients qui veulent plus que l'éditeur classique.

                      du coup il vaut mieux lui mettre tout dans un article ou dans une page SP ?

                      car au final ca reviendra au même pour lui non?
                      sauf que via l'article, l'avantage est qu'il a les 2.


                      Expert en conception et réalisation de sites Internet 100% Joomla
                      www.toonetcreation.com

                      Commentaire


                      • #41
                        Attention !

                        Dans le backoffice, quand on modifie avec l'éditeur classique, on doit cliquer sur le bouton correspondant si l'édition avec SPPB est aussi activée.
                        La modification ne doit concerner que le texte d'intro.
                        Mais si on oublie, une fois la modification faite, de recliquer sur le bouton pour rebasculer avec SPPB, l'article s'affiche en front avec le contenu présent dans l'éditeur classique, et on perd alors toute la mise en forme du builder (qu'on retrouve si on reclique sur ledit bouton.
                        En fait, ces boutons servent en quelque sorte à définir quel sera l'éditeur d'affichage.

                        L'édition en front permet les deux, mais là on a pas à se soucier du bouton de bascule d'un éditeur à l'autre.
                        Un fois la modification faite l'article s'affiche selon l'éditeur définit en back.
                        Par contre si on modifie l'article avec l'éditeur classique, il ne faut modifier que l'intro.
                        SPPB ajouter du contenu, généralement celui des blocs textes présents dans la page, après la lire de rupture "lire la suite".
                        Un utilisateur peut être tenté de le modifier, mais cela ne servira à rien puisque le builder le remplacera par l'existant.
                        Donc la fonction de modification via l'éditeur Joomla n'a strictement aucun intérêt pour une onepage éditée avec SPPB.

                        Enfin, le fait d'éditer en front l'article avec SPPB, cela permet d'avoir un rendu visuel confirme à la mise en page finale, alors qu'en back-end c'est plus technique et sans rendu sauf si on clique sur le bouton de prévisualisation.
                        Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
                        Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
                        Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

                        Commentaire


                        • #42
                          Envoyé par dolmenhir Voir le message
                          Dans le backoffice, quand on modifie avec l'éditeur classique, on doit cliquer sur le bouton correspondant si l'édition avec SPPB est aussi activée.
                          La modification ne doit concerner que le texte d'intro.
                          Mais si on oublie, une fois la modification faite, de recliquer sur le bouton pour rebasculer avec SPPB, l'article s'affiche en front avec le contenu présent dans l'éditeur classique, et on perd alors toute la mise en forme du builder (qu'on retrouve si on reclique sur ledit bouton.
                          En fait, ces boutons servent en quelque sorte à définir quel sera l'éditeur d'affichage.
                          ok oui je comprends, c'est fait une sorte de sélecteur d'affichage en effet.

                          Envoyé par dolmenhir Voir le message
                          L'édition en front permet les deux, mais là on a pas à se soucier du bouton de bascule d'un éditeur à l'autre.
                          tu veux dire que depuis le front-end, quand tu modifies un article, tu peux faire pointer l'affichage uniquement sur l'éditeur classique ou celui de SP PAGE BUILDER ? et masquer l'autre?

                          Envoyé par dolmenhir Voir le message
                          Enfin, le fait d'éditer en front l'article avec SPPB, cela permet d'avoir un rendu visuel confirme à la mise en page finale, alors qu'en back-end c'est plus technique et sans rendu sauf si on clique sur le bouton de prévisualisation.
                          oui mais l'édition en front-end, bien que carrément plus simple pour le end-user je suis d'accord, pose plusieurs gros problèmes selon moi :

                          - sécurité : avec une page de connexion possible depuis le front-end cela augmente la surface d'attaque potentielle.
                          - design : l'édition en front-end doit souvent être ajustée via du CSS pour coller à la charte du site si on veut un truc nickel ou masquer des options.
                          - accessibilité : toutes les extensions joomla ne sont pas gérables/managables depuis le fornt-end..et du coup, si jamais on en revient à proposer à l'utilisateur de modifier telle et telle extension depuis le font-end et telle et telle extension depuis le back-end, c'est une perte considérable en simplicité et ergonomie.

                          donc je suis quand même mitigé sur ça pour être honnête.

                          quand au rendu visuel depuis le back-office, comme tu l'a dis le bouton de prévisualisation est la, ou au pire on enregistre et on va voir sur le site public ce que cela donne...perso ça fait 11 ans que je fonctionne comme ça et idem pour les clients, c'est pas vraiment gênant je trouve...question de goût certainement.
                          Expert en conception et réalisation de sites Internet 100% Joomla
                          www.toonetcreation.com

                          Commentaire


                          • #43
                            Envoyé par Tortue Genial 69 Voir le message
                            tu veux dire que depuis le front-end, quand tu modifies un article, tu peux faire pointer l'affichage uniquement sur l'éditeur classique ou celui de SP PAGE BUILDER ? et masquer l'autre?
                            Quand tu modifies l'article avec l'éditeur classique, tu ne vois aucun des éléments du builder.
                            Au plus, tu as, après la ligne de rupture "lire la suite" les textes correspondants aux blocs textes des addons présents dans l'article, mais les modifier est sans effet (ce n'est que du texte qui sera remplacé par SPPB.

                            Envoyé par Tortue Genial 69 Voir le message
                            - sécurité : avec une page de connexion possible depuis le front-end cela augmente la surface d'attaque potentielle.
                            Menace relativement circonscrite puisque tu n'as pas accès au reste des fonctions de l'admin.
                            Avec un bon mot de passe, un outil de sécurité (admintools, aesecure), et éventuellement une double authentification, tu peux aisément renforcer la sécurité de l'édition en front.

                            Envoyé par Tortue Genial 69 Voir le message
                            - design : l'édition en front-end doit souvent être ajustée via du CSS pour coller à la charte du site si on veut un truc nickel ou masquer des options.
                            Aucun problème de design avec SPPB.
                            Tu travailles sur la page ou l'article courant, le rendu ne concerne que cette partie. Le reste n'est absolument pas impacté.

                            Envoyé par Tortue Genial 69 Voir le message
                            - accessibilité : toutes les extensions joomla ne sont pas gérables/managables depuis le fornt-end..et du coup, si jamais on en revient à proposer à l'utilisateur de modifier telle et telle extension depuis le font-end et telle et telle extension depuis le back-end, c'est une perte considérable en simplicité et ergonomie.
                            Idem que pour la question précédente.
                            Si tu proposes l'édition d'une onepage via SPPB, la question des extensions ne se posent pas puisqu'elles ne son pas concernées par la page.
                            Le seul intérêt de passer par le back, c'est si on a autre chose à y faire qu'une simple page à modifier.

                            Personnellement, je trouve beaucoup plus risqué de donner un accès, même restreint, au backoffice plutôt qu'au front vu qu'en mode édition beaucoup de fonctions, routines et process ne sont pas accessibles.
                            C'est d'ailleurs pour cela que le front existe : restreindre l'accès au back tout en proposant un accès limité pour la rédaction.

                            Envoyé par Tortue Genial 69 Voir le message
                            quand au rendu visuel depuis le back-office, comme tu l'a dis le bouton de prévisualisation est la, ou au pire on enregistre et on va voir sur le site public ce que cela donne.
                            Si tu veux voir, par exemple, ce que un titre, un texte, une image, donne à l'affichage selon différentes tailles, c'est plus simple et rapide d'utiliser un curseur que de définir une taille, valider, aller voir, de revenir, de changer, de valider, de retourner voir, etc, etc...
                            C'est vraiment plus simple et plus ergonomique, surtout pour un client qui ne maîtrise pas trop la technique, et qui va vite s'agacer de devoir faire d'incessants va-et-vient.


                            Moi je propose de plus en plus souvent cette formule à mes clients et n'ai jamais eu la moindre remarque ni le moindre problème de sécurité.
                            Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
                            Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
                            Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

                            Commentaire


                            • #44
                              ok noté pour l'accès aux éléments du builder je vais tester.

                              par contre, pour travailler régulièrement avec des problématiques de cyber-sécurité (dans mon boulot principal), le fait de ne pas avoir de problème à l'instant T ne signifie pas qu'il n'y en aura jamais. en effet avec tout ce que tu décris, on peut mieux sécuriser l'accès depuis le front-end, mais dans l'absolu, même si c'est moins probable, l'accès en front reste moins secure que le back-end..c'est un fait. disons que même si rien n'est pas parfait et que depuis le back-end le piratage est aussi possible, cela permet quand même de réduire la surface d'attaque.
                              donc au pire je préfère conserver cette solution, c'est toujours un petit plus je trouve.

                              d'autant plus, que je n'avais en tête pas uniquement les site one page, mais tous les types de site en fait.
                              les sites one page sont un cas à part car il n'y a besoin de rien d'autre comme extensions, mais pour tous les autres types de site personnellement j'en utilise d'autres.
                              et la elles ne sont pas forcément toutes dispos depuis le front, et la ça coince.

                              ok noté pour le design en effet cela ne doit pas perturber le builder, mais les autres extensions si malheureusement (j'en ai déjà fait l'expérience).

                              et concernant l'accès back-end, si ça t’intéresse je peux publier un screen shot d'un back-end classique d'un site client, tu verras que c'est épuré de chez épuré et il n'a accès à presque rien..enfin juste à ce dont il a besoin. donc il est strictement impossible qu'il fasse une connerie, vu que tout est calibré.
                              et dans mon cas, cela me permet de le cloisonner dans un environnement contrôlé et délimité, sans avoir à toucher au design des autres extensions que le builder, car cela est pris en charge par le template admin.

                              après il y a toujours plusieurs chemins pour arriver au même endroit c'est sur...la pour le coup dans les 2 cas cela fonctionne.

                              maintenant je réfléchissait plus loin et je me disais que : quitte à utiliser un page builder, en fait les articles ne servent que pour le mode blog à la fin non?
                              car si toutes les pages sont gérées via le builder et vu que leur contenu n'est pas dans un article, ben les articles servent juste pour le blog (si présent)?

                              Expert en conception et réalisation de sites Internet 100% Joomla
                              www.toonetcreation.com

                              Commentaire


                              • #45
                                Envoyé par Tortue Genial 69 Voir le message
                                aintenant je réfléchissait plus loin et je me disais que : quitte à utiliser un page builder, en fait les articles ne servent que pour le mode blog à la fin non?
                                car si toutes les pages sont gérées via le builder et vu que leur contenu n'est pas dans un article, ben les articles servent juste pour le blog (si présent)?
                                Si toutes tes pages sont faites avec le builder sans passer par un article, tu n'auras rien derrière un lien de type blog car cela ne fonctionne qu'avec les articles.

                                Mais y a des cas où les pages faites avec le builder suffisent largement.

                                Jai quelques clients avec des petits sites de 10/15 pages, sans relation particulières entre-elles, qui n'ont pas besoin d'être classées par catégorie ni d'un affichage de type blog.
                                Du coup, toutes ces pages sont faites avec le builder.

                                Mon propre site est pour l'instant intégralement fait avec un builder.
                                Il est en refonte et n'a certes qu'un nombre de pages limité à l'essentiel.
                                Cependant, plusieurs pages actuellement absentes vont rester en mode article mais seront totalement redessinées avec le builder.
                                Je préfère éclairer que briller.” - “J'ai peut-être l'air froid, mais je suis pas givré.- "ça dépend ça dépasse"
                                Ne m'envoyez pas de message privé pour résoudre vos problèmes sans y avoir été invité.
                                Dolmenhir : tailleur de site web depuis 1997. Spécialiste Joomla depuis 2005. https://www.dolmenhir.fr

                                Commentaire

                                Annonce

                                Réduire
                                Aucune annonce pour le moment.

                                Partenaire de l'association

                                Réduire

                                Hébergeur Web PlanetHoster
                                Travaille ...
                                X