Édition d'une noisette : problèmes avec la modale #1

Open
opened 2 years ago by tcharlss · 13 comments
tcharlss commented 2 years ago
Owner

L'édition d'une noisette dans une modale pose quelques problèmes :

  • Avec les saisies qui ouvrent elles-mêmes une modale, la saisie de sélection de documents par exemple : après sélection de document ça tourne dans le vide au lieu de revenir vers la modale initiale.
  • Avec certains scripts qui se reposent sur le largeur du conteneur : ils n'arrivent sans doute pas pas à retrouver la largeur de la modale. Je suppose que c'est parcequ'au moment où le script est initialisé, la modale n'a pas encore de largeur fixée, un truc comme ça. Constaté avec Radios to slider par exemple.
  • Et d'autres trucs pas encore identifiés ?

Je n'ai pas de réponse toute prête à ce problème, je note ici juste pour ne pas oublier.

Pour rappel, on était passé à l'utilisation d'une modale pour répondre à un problème d'UX : auparavant ça faisait aller sur une page d'édition à part, et en revenant sur la page initiale on avait du mal à retrouver où on était.

Je pense toujours qu'il faudrait pouvoir éditer une noisette sans quitter la page, mais la modale n'est pas forcément la solution idéale.

L'édition d'une noisette dans une modale pose quelques problèmes : * Avec les saisies qui ouvrent elles-mêmes une modale, la saisie de sélection de documents par exemple : après sélection de document ça tourne dans le vide au lieu de revenir vers la modale initiale. * Avec certains scripts qui se reposent sur le largeur du conteneur : ils n'arrivent sans doute pas pas à retrouver la largeur de la modale. Je suppose que c'est parcequ'au moment où le script est initialisé, la modale n'a pas encore de largeur fixée, un truc comme ça. Constaté avec [Radios to slider](https://github.com/rubentd/radios-to-slider) par exemple. * Et d'autres trucs pas encore identifiés ? Je n'ai pas de réponse toute prête à ce problème, je note ici juste pour ne pas oublier. Pour rappel, on était passé à l'utilisation d'une modale pour répondre à un problème d'UX : auparavant ça faisait aller sur une page d'édition à part, et en revenant sur la page initiale on avait du mal à retrouver où on était. Je pense toujours qu'il faudrait pouvoir éditer une noisette sans quitter la page, mais la modale n'est pas forcément la solution idéale.
Eric commented 1 year ago
Owner

Oui, je suis d'accord sur le fait qu'il faut rester sur la page. Si on n'utilise pas une modale je ne vois pas d'autre solution que celle d'ouvrir le formulaire d'édition sous la noisette à éditer. Par contre, je ne sais pas si c'est possible et si oui, comment.

Oui, je suis d'accord sur le fait qu'il faut rester sur la page. Si on n'utilise pas une modale je ne vois pas d'autre solution que celle d'ouvrir le formulaire d'édition sous la noisette à éditer. Par contre, je ne sais pas si c'est possible et si oui, comment.
Poster
Owner

Quand j'avais ouvert ce ticket, la piste qui me semblait la plus intéressante c'était de reprendre le layout adopté par nombre de ce genre d'outils (bootstrap studio et cie) : 3 colonnes, avec le paramétrage du bloc édité dans la colonne de droite.

J'avais commencé des tests dans ce sens pour voir si et comment ça serait faisable, et voir ce que ça donnait à l'utilisation.
Cf. vidéo en pièce-jointe (obligé de la zipper, gitea n'accepte pas les mp4).

Alternativement, le paramétrage du bloc édité pourrait être placé ailleurs : directement dans la colonne centrale à la place de la previsu de la noisette comme tu dis, ou bien aussi comme le plugin elementor dans wordpress qui replace la liste des blocs à gauche.

Enfin bref, je ne m'étais plus trop penché dessus après ces 1er tests initiaux.


Edit : lien vers le screencast mis sur mon serveur temporairement

video

Quand j'avais ouvert ce ticket, la piste qui me semblait la plus intéressante c'était de reprendre le layout adopté par nombre de ce genre d'outils (bootstrap studio et cie) : 3 colonnes, avec le paramétrage du bloc édité dans la colonne de droite. J'avais commencé des tests dans ce sens pour voir si et comment ça serait faisable, et voir ce que ça donnait à l'utilisation. Cf. vidéo en pièce-jointe (obligé de la zipper, gitea n'accepte pas les mp4). Alternativement, le paramétrage du bloc édité pourrait être placé ailleurs : directement dans la colonne centrale à la place de la previsu de la noisette comme tu dis, ou bien aussi comme le plugin elementor dans wordpress qui replace la liste des blocs à gauche. Enfin bref, je ne m'étais plus trop penché dessus après ces 1er tests initiaux. ---- Edit : lien vers le screencast mis sur mon serveur temporairement [![video](https://git.spip.net/attachments/1e9f69c1-6424-45f5-a27c-938e4f475d4f)](https://bravecassine.com/public/noizetier_dev_1.mp4)
Owner

Vu qu'on avait benchmarké ensemble avec @tcharlss plusieurs plugins de WP qui faisaient du site building comme ça, je suis assez d'accord : je pense que ce serait bien de s'inspirer de ce qui se fait ailleurs, et je pense aussi que ça devrait être revu en plusieurs colonnes.

Mais il me semble que c'est plus simple même : deux suffisent ! En effet, quand tu es en mode "je veux configurer telle noisette", alors forcément tu n'es PAS en mode "je veux ajouter une nouvelle noisette". C'est l'un ou l'autre, il n'y a aucune raison de permettre les deux au même moment.

Dans plusieurs plugins WP, la colonne de configuration d'un bloc (un formulaire donc), remplace la colonne listant les types de blocs possibles. Et quand on a fini et qu'on enregistre, ça enlève le formulaire et ça revient à la liste. Donc toujours que deux colonnes : donc plus de place ! :)

Vu qu'on avait benchmarké ensemble avec @tcharlss plusieurs plugins de WP qui faisaient du site building comme ça, je suis assez d'accord : je pense que ce serait bien de s'inspirer de ce qui se fait ailleurs, et je pense aussi que ça devrait être revu en plusieurs colonnes. Mais il me semble que c'est plus simple même : deux suffisent ! En effet, quand tu es en mode "je veux configurer telle noisette", alors forcément tu n'es PAS en mode "je veux ajouter une nouvelle noisette". C'est l'un ou l'autre, il n'y a aucune raison de permettre les deux au même moment. Dans plusieurs plugins WP, la colonne de configuration d'un bloc (un formulaire donc), *remplace* la colonne listant les types de blocs possibles. Et quand on a fini et qu'on enregistre, ça enlève le formulaire et ça revient à la liste. Donc toujours que deux colonnes : donc plus de place ! :)
Eric commented 1 year ago
Owner

Oui c'est assez sympa comme présentation avec un formulaire qui s'ouvre à droite. Je suis aussi d'accord avec Rasta que l'on peut considérer que le volet des types de noisette et celui du formulaire d'édition d'une noisette peuvent s'exclure étant donné l'utilisation qu'on en fait.

En particulier, ça permettrait d'avoir des largeurs suffisantes pour chaque colonne. Moi je suis toujours dubitatif sur celle des types de noisette, le sticky fonctionne mal et cette litanie qui n'en finit pas est tout sauf ergonomique. Peut-être qu'un acoordéon ou un rangement par groupes (mais lesquels ?) serait mieux ?

Oui c'est assez sympa comme présentation avec un formulaire qui s'ouvre à droite. Je suis aussi d'accord avec Rasta que l'on peut considérer que le volet des types de noisette et celui du formulaire d'édition d'une noisette peuvent s'exclure étant donné l'utilisation qu'on en fait. En particulier, ça permettrait d'avoir des largeurs suffisantes pour chaque colonne. Moi je suis toujours dubitatif sur celle des types de noisette, le sticky fonctionne mal et cette litanie qui n'en finit pas est tout sauf ergonomique. Peut-être qu'un acoordéon ou un rangement par groupes (mais lesquels ?) serait mieux ?
Poster
Owner

e suis aussi d'accord avec Rasta que l'on peut considérer que le volet des types de noisette et celui du formulaire d'édition d'une noisette peuvent s'exclure étant donné l'utilisation qu'on en fait.

Ouais je viens de retester elementor, c'est assez pratique à l'usage, ça me semble une bonne direction.

Moi je suis toujours dubitatif sur celle des types de noisette, [...] cette litanie qui n'en finit pas est tout sauf ergonomique. Peut-être qu'un acoordéon ou un rangement par groupes (mais lesquels ?) serait mieux ?

Là je pense qu'il faut aussi adopter l'affichage des autres outils : faire une grille de noisettes plutôt qu'une liste verticale. Ça réduirait beaucoup l'espace vertical, et de plus on aurait beaucoup plus de noisettes visibles d'un seul coup.
Au moins une grille à 2 colonnes, peut-être même que 3 ça passerait.

Cf. capture d'elementor à la fin pour référence (mais c'est pareil dans moqup, proto.io, etc.)

le sticky fonctionne mal

Alors le sticky il marchait très bien en 3.2, mais ça plantouille en 3.3 avec le nouveau layout. Faut le garder et le refaire marcher :)
Sans sticky sur les pages avec beaucoup de noisettes, c'est la souffrance absolue.

Peut-être qu'un acoordéon ou un rangement par groupes (mais lesquels ?) serait mieux ?

Pareil, je pense qu'il y a une réflexion à faire sur les groupes.

À 1ère vue, je me dis que le noizetier devrait définir un nombre limité de groupes, et chaque type de noisette pourrait dire dans sa déclaration « j'appartiens à tel groupe ». Comme pour les plugins en quelque sorte.

Après, lesquels exactement, c'est la question.
Dans la plupart des outils que j'ai regardés, il y a toujours en 1er un groupe avec les éléments de bases (bloc de texte, image, heading, bouton, ce genre de choses), et puis ensuite d'autres plus spécifiques.

Et au niveau de l'affichage, elementor utilise des accordéons aussi, ma foi quand il y a beaucoup de groupes c'est pratique.
Et un champ de filtrage rapide au début, bien pratique aussi.

> e suis aussi d'accord avec Rasta que l'on peut considérer que le volet des types de noisette et celui du formulaire d'édition d'une noisette peuvent s'exclure étant donné l'utilisation qu'on en fait. Ouais je viens de retester elementor, c'est assez pratique à l'usage, ça me semble une bonne direction. > Moi je suis toujours dubitatif sur celle des types de noisette, [...] cette litanie qui n'en finit pas est tout sauf ergonomique. Peut-être qu'un acoordéon ou un rangement par groupes (mais lesquels ?) serait mieux ? Là je pense qu'il faut aussi adopter l'affichage des autres outils : faire une grille de noisettes plutôt qu'une liste verticale. Ça réduirait beaucoup l'espace vertical, et de plus on aurait beaucoup plus de noisettes visibles d'un seul coup. Au moins une grille à 2 colonnes, peut-être même que 3 ça passerait. Cf. capture d'elementor à la fin pour référence (mais c'est pareil dans moqup, proto.io, etc.) > le sticky fonctionne mal Alors le sticky il marchait très bien en 3.2, mais ça plantouille en 3.3 avec le nouveau layout. Faut le garder et le refaire marcher :) Sans sticky sur les pages avec beaucoup de noisettes, c'est la souffrance absolue. > Peut-être qu'un acoordéon ou un rangement par groupes (mais lesquels ?) serait mieux ? Pareil, je pense qu'il y a une réflexion à faire sur les groupes. À 1ère vue, je me dis que le noizetier devrait définir un nombre limité de groupes, et chaque type de noisette pourrait dire dans sa déclaration « j'appartiens à tel groupe ». Comme pour les plugins en quelque sorte. Après, lesquels exactement, c'est la question. Dans la plupart des outils que j'ai regardés, il y a toujours en 1er un groupe avec les éléments de bases (bloc de texte, image, heading, bouton, ce genre de choses), et puis ensuite d'autres plus spécifiques. Et au niveau de l'affichage, elementor utilise des accordéons aussi, ma foi quand il y a beaucoup de groupes c'est pratique. Et un champ de filtrage rapide au début, bien pratique aussi. ![](https://git.spip.net/attachments/56aeec1d-9e73-4a90-9cc2-44c80f00634e)
Eric commented 1 year ago
Owner

Oui j'adhère totalement à la présentation type elementor, accordéon par groupe et une grille de 3 types de noisette par ligne. Le problème ça reste les groupes et là je m'y connais avec les catégories de plugin ;-).

Pour moi il existe déjà 2 typologie de principe:

  • la portée des types de noisette, à savoir, communes, spécifique à une page ou spécifique à une composition de page (hors composition par défaut). C'est déjà comme ça que l'on range le bloc et c'est pas hyper top.
  • le plugin fournisseur du type de noisette. Ce n'est pas forcément une mauvaise idée car en général un plugin a une thématique donnée mais je me rappelle avoir déjà fait cette proposition.

Après, on peut en définir une comme les catégories de plugin ou autre mais là on est parti pour un grand moment de solitude... mais c'est possible. Et on peut aussi proposer plusieurs regroupement à choisir en configuration par exemple et même avoir un indicateur précisant les autres typologies pour chaque noisette (l'icone du plugin, icone de portée).

Oui, je pense que c'est la bonne piste. On saurait faire un layout pour ça sachant que la liste des groupes c'est pas un souci on pourra toujours prendre l'une des deux précitées le temps de trouver une typologie plus fonctionnelle ?

Oui j'adhère totalement à la présentation type elementor, accordéon par groupe et une grille de 3 types de noisette par ligne. Le problème ça reste les groupes et là je m'y connais avec les catégories de plugin ;-). Pour moi il existe déjà 2 typologie de principe: * la portée des types de noisette, à savoir, communes, spécifique à une page ou spécifique à une composition de page (hors composition par défaut). C'est déjà comme ça que l'on range le bloc et c'est pas hyper top. * le plugin fournisseur du type de noisette. Ce n'est pas forcément une mauvaise idée car en général un plugin a une thématique donnée mais je me rappelle avoir déjà fait cette proposition. Après, on peut en définir une comme les catégories de plugin ou autre mais là on est parti pour un grand moment de solitude... mais c'est possible. Et on peut aussi proposer plusieurs regroupement à choisir en configuration par exemple et même avoir un indicateur précisant les autres typologies pour chaque noisette (l'icone du plugin, icone de portée). Oui, je pense que c'est la bonne piste. On saurait faire un layout pour ça sachant que la liste des groupes c'est pas un souci on pourra toujours prendre l'une des deux précitées le temps de trouver une typologie plus fonctionnelle ?
Owner

Alors les groupes on en a déjà parlé plusieurs fois, mais c'était avant les tickets par plugin. Donc oui, je suis le premier à pousser à fond pour ça. M'est-avis qu'on devrait plutôt faire un ticket dédié pour débattre ce point de typologie, c'est différent du layout général de l'édition dont on parle ici. :)

Alors les groupes on en a déjà parlé plusieurs fois, mais c'était avant les tickets par plugin. Donc oui, je suis le premier à pousser à fond pour ça. M'est-avis qu'on devrait plutôt faire un ticket dédié pour débattre ce point de typologie, c'est différent du layout général de l'édition dont on parle ici. :)
Eric commented 1 year ago
Owner

Oui je suis d'accord. Je pense qu'on peut acter par contre la proposition type elementor avec des groupes non ?

J'ouvre un ticket sur les groupes.

Oui je suis d'accord. Je pense qu'on peut acter par contre la proposition type elementor avec des groupes non ? J'ouvre un ticket sur les groupes.
Poster
Owner

Oui je suis d'accord. Je pense qu'on peut acter par contre la proposition type elementor avec des groupes non ?

+1

> Oui je suis d'accord. Je pense qu'on peut acter par contre la proposition type elementor avec des groupes non ? +1
tcharlss added the
UX
label 1 year ago
Owner

Comme dit dans l'autre ticket, j'ai passé toute la soirée à lire la doc de Gutenberg sur leurs blocs. Et je pense que c'est encore mieux de partir sur ça comme base plutôt qu'Elementor. En réalité c'est très proche hein, ça reprend plein de choses pareil comme les colonnes la config d'un bloc ou la liste des blocs, etc, sauf que Gutenberg est conçu et maintenu par mille fois plus de gens avec plus de moyen, donc je pense que niveau réflexion ergo, illes ont forcément encore plus avancé que l'équipe d'un simple plugin.

https://wordpress.org/support/article/wordpress-editor/

Du coup ça vaut pour le layout de #2 aussi (mais bon chez WP ya toujours un contenu puisque c'est jamais le plan/outline toujours l'édition complète, donc pas juste une simple ligne).

Comme dit dans l'autre ticket, j'ai passé toute la soirée à lire la doc de Gutenberg sur leurs blocs. Et je pense que c'est encore mieux de partir sur ça comme base plutôt qu'Elementor. En réalité c'est très proche hein, ça reprend plein de choses pareil comme les colonnes la config d'un bloc ou la liste des blocs, etc, sauf que Gutenberg est conçu et maintenu par mille fois plus de gens avec plus de moyen, donc je pense que niveau réflexion ergo, illes ont forcément encore plus avancé que l'équipe d'un simple plugin. https://wordpress.org/support/article/wordpress-editor/ Du coup ça vaut pour le layout de #2 aussi (mais bon chez WP ya toujours un contenu puisque c'est jamais le plan/outline toujours l'édition complète, donc pas juste une simple ligne).
Collaborator

Et pour renforcer l'idée que Gutemberg est supérieur à Elementor : https://wp-bullet.com/wordpress-page-builder-performance-case-study-elementor-vs-generateblocks-benchmarks

Et pour renforcer l'idée que Gutemberg est supérieur à Elementor : https://wp-bullet.com/wordpress-page-builder-performance-case-study-elementor-vs-generateblocks-benchmarks
Poster
Owner

Comme dit dans l'autre ticket, j'ai passé toute la soirée à lire la doc de Gutenberg sur leurs blocs. Et je pense que c'est encore mieux de partir sur ça comme base plutôt qu'Elementor. En réalité c'est très proche hein [...]

J'ai juste survolé la doc pour l'instant, anéfé à quelques pétouilles près les concepts de base on l'air identiques. Ça montre bien qu'on est parti sur la bonne piste.
Ils ont l'air d'avoir fait pas mal de "fine-tuning" par dessus-ça : prévisu des changements dès qu'on modifie un paramètre, sauvegarde automatique des brouillons, passage d'un type de bloc à un autre (mais ce dernier point est sans doute un poil plus compliqué que des questions d'UX...), etc.

J'ai commencé à implémenter tout ce qui a été proposé jusque là (ce ticket, le #2, un peu du #5 et le #14). C'est presque prêt, je pousserai ça dans une branche de dev sous peu.
Je veux pas nous lancer des fleurs mais ça devient presque agréable à utiliser :p

Comme ça regroupe plein de choses, je pense que j'ouvrirai un ticket général « édition dans le privé » pour faire le suivi, et plus tard un autre « édition dans le public ».

Je ferai le détail dans le nouveau ticket, mais en 2 mots j'ai essayé d'anticiper au maximum la future édition dans le public, en mutualisant les choses de façon à avoir le moins de choses à refaire.
À moins de lièvres cachés, une fois l'interface du privé bouclée on devrait plus être très loin de pouvoir rétablir celle du public.

> Comme dit dans l'autre ticket, j'ai passé toute la soirée à lire la doc de Gutenberg sur leurs blocs. Et je pense que c'est encore mieux de partir sur ça comme base plutôt qu'Elementor. En réalité c'est très proche hein [...] J'ai juste survolé la doc pour l'instant, anéfé à quelques pétouilles près les concepts de base on l'air identiques. Ça montre bien qu'on est parti sur la bonne piste. Ils ont l'air d'avoir fait pas mal de "fine-tuning" par dessus-ça : prévisu des changements dès qu'on modifie un paramètre, sauvegarde automatique des brouillons, passage d'un type de bloc à un autre (mais ce dernier point est sans doute un poil plus compliqué que des questions d'UX...), etc. J'ai commencé à implémenter tout ce qui a été proposé jusque là (ce ticket, le #2, un peu du #5 et le #14). C'est presque prêt, je pousserai ça dans une branche de dev sous peu. Je veux pas nous lancer des fleurs mais ça devient presque agréable à utiliser :p Comme ça regroupe plein de choses, je pense que j'ouvrirai un ticket général « édition dans le privé » pour faire le suivi, et plus tard un autre « édition dans le public ». Je ferai le détail dans le nouveau ticket, mais en 2 mots j'ai essayé d'anticiper au maximum la future édition dans le public, en mutualisant les choses de façon à avoir le moins de choses à refaire. À moins de lièvres cachés, une fois l'interface du privé bouclée on devrait plus être très loin de pouvoir rétablir celle du public.
Owner

Cool, hâte de voir ! Niveau suivi plutôt qu'un autre ticket encore :

  1. tu peux créer un Jalon avec un nom pour regrouper les tickets ensemble
  2. tu peux créer une PR clairement marquée "WIP" dans le titre, qui suit telle branche, quand on veut discuter de l'ensemble, et surtout de ce qui est en cours à tester, et pas d'un ticket particulier
Cool, hâte de voir ! Niveau suivi plutôt qu'un autre ticket encore : 1) tu peux créer un Jalon avec un nom pour regrouper les tickets ensemble 2) tu peux créer une PR clairement marquée "WIP" dans le titre, qui suit telle branche, quand on veut discuter de l'ensemble, et surtout de ce qui est en cours à tester, et pas d'un ticket particulier
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.