Classement des saisies #7

Closed
opened 1 year ago by maieul · 56 comments
maieul commented 1 year ago
Collaborator

Comme remarqué, il faudrait voir dans les constructeurs de formulaire à présenter autrement les saisies, pour mieux les repèrer.

Plus qu'un tri (qui actuellement existe = alphabétique) ce qui importerait serait une catégorisation.

Je vois pour l'heure deja 3 grandes catégories :

  • saisies de texte
  • saisie de choix fermée
  • saisie lié à des objets SPIP

Mais évidemment je n'ai pas encore parcouru toute les saisies. Mais deja voyons si on a consensus sur cela.

J'ajouterai également qu'il faudrait prévoir la possibilité pour les plugins fournissant des saisies d'avoir leurs propres catégories (par exemple toutes les saisies liées à un domaine métier).

Comme remarqué, il faudrait voir dans les constructeurs de formulaire à présenter autrement les saisies, pour mieux les repèrer. Plus qu'un tri (qui actuellement existe = alphabétique) ce qui importerait serait une catégorisation. Je vois pour l'heure deja 3 grandes catégories : - saisies de texte - saisie de choix fermée - saisie lié à des objets SPIP Mais évidemment je n'ai pas encore parcouru toute les saisies. Mais deja voyons si on a consensus sur cela. J'ajouterai également qu'il faudrait prévoir la possibilité pour les plugins fournissant des saisies d'avoir leurs propres catégories (par exemple toutes les saisies liées à un domaine métier).

grouper oui, je pensais à ça aussi pour mieux y voir, en revanche séparer texte, choix etc, je réfléchis encore

notamment parce que pour l'instant je pense que les saisies méga super courantes devraient toujours être dans un groupe en tout premier (input, textarea, radios…), mais peut-être que c'est pas une bonne idée

faudrait voir comment c'est fait dans plusieurs autres générateurs de form (drupal, google forms, frama, etc) et en tirer le mieux

grouper oui, je pensais à ça aussi pour mieux y voir, en revanche séparer texte, choix etc, je réfléchis encore notamment parce que pour l'instant je pense que les saisies méga super courantes devraient toujours être dans un groupe en tout premier (input, textarea, radios…), mais peut-être que c'est pas une bonne idée faudrait voir comment c'est fait dans plusieurs autres générateurs de form (drupal, google forms, frama, etc) et en tirer le mieux
Poster
Collaborator
  • frama form: pas de groupement

image

A mon avis, il faudrait donc

  1. Regrouper par type
  2. Hierarchiser les groupements
- frama form: pas de groupement ![image](/attachments/9ac5a9f4-da29-4536-906d-5fb3181360a9) - mechant capitaliste google : regroupement par type ![image](/attachments/b1ad5170-17c3-40a1-a65b-9d54bb968752) - druapl form builder : pas de regroupement https://www.drupal.org/files/project-images/formio-form-builder.png A mon avis, il faudrait donc 1. Regrouper par type 2. Hierarchiser les groupements

Google forms est vraiment le plus clair dans cette liste pour l'instant, ça me parait assez flagrant :D

Après nous on en a beaucoup plus (dont plein qui se ressemblent, tous les email, number, couleur etc ne sont que des variantes de l'input text de base), donc après à nous de les regrouper au mieux suivant ce qu'on veut afficher à la fin.

Là par exemple dans Google forms c'est plus ou moins regroupé par type MAIS parce qu'il n'y en a que DEUX dans le texte, donc on voit vite les suivants. Si chez nous on se met à avoir 10 trucs dans "type texte", ça devient moins pertinent, car par exemple, les "boutons radios" sont un besoin plus courant et générique que "couleur". Voilà pourquoi je disais qu'il fallait peut-être (c'est à réfléchir) un groupe où il y avait vraiment les 4-5 trucs les plus courants en tout premier à part, et seulement après les autres avec leur classement.

Google forms est vraiment le plus clair dans cette liste pour l'instant, ça me parait assez flagrant :D Après nous on en a beaucoup plus (dont plein qui se ressemblent, tous les email, number, couleur etc ne sont que des variantes de l'input text de base), donc après à nous de les regrouper au mieux suivant ce qu'on veut afficher à la fin. Là par exemple dans Google forms c'est plus ou moins regroupé par type MAIS parce qu'il n'y en a que DEUX dans le texte, donc on voit vite les suivants. Si chez nous on se met à avoir 10 trucs dans "type texte", ça devient moins pertinent, car par exemple, les "boutons radios" sont un besoin plus courant et générique que "couleur". Voilà pourquoi je disais qu'il fallait peut-être (c'est à réfléchir) un groupe où il y avait vraiment les 4-5 trucs les plus courants en tout premier à part, et seulement après les autres avec leur classement.
Poster
Collaborator

Moi je serais pour faire ceci

  1. Regrouper par type pour les choses de "base". Input+textarea vs selection/radio
  2. Ensuite tout ce qui est des "sous variantes pour des usages avancées" seraient des groupes à part, classé plus bas.
Moi je serais pour faire ceci 1. Regrouper par type pour les choses de "base". Input+textarea vs selection/radio 2. Ensuite tout ce qui est des "sous variantes pour des usages avancées" seraient des groupes à part, classé plus bas.
Poster
Collaborator

Au dela de la typologie par défaut, quelques réflexions techniques que je me suis faites durant une balade lacustre

  1. Il faut qu'un plugin puisse avoir ses propres groupes
    => Ma proposition est la suivante : le .yaml contiendrait une ligne de type:
categorie: '<prefixe>:<chainedelangue>'

Comme cela le nom de la catégorie est automatiquement définie, et cela correspond rapidement à son identifiant. Une version suffisée _explication de la chaine de langue permettrait, si on juge utile, d'avoir explication sur le regroupement (je ne sais pas encore)
2. On mettra une categorie fallback autre
3. Il faut avoir un tri des chaines des catégories, pour hiéarchiser. Je propose un pipeline saisies_lister_disponibles (appeler dans la fonction homonyme). Cela permettrait non seulement de réordonner les groupes, mais aussi, si on le souhaite, de supprimer certaines saisies sur un site (pour simplifier l'interface pour les gens)
4. La question est de savoir si saisies_lister_disponibles() doit retourner les saisies en groupe par défaut, ou bien si c'est une option qu'on lui passe. Sachant qu'on avait deja mis une option pour les obsolètes. J'ai peur d'une signature à rallonge. Après on peut encore modifier actuellement, personne n'utilise le deuxième argument > on peut en faire facilenment un tableau. Mais du coup la question de ce qu'on propose par défaut se pose.

Avis bienvenue, j'aimerais bien commencer à bosser sur cela la semaine prochaine, pour faire un proto. Ca commence à devenir important pour mes propres besoins.

Au dela de la typologie par défaut, quelques réflexions techniques que je me suis faites durant une balade lacustre 1. Il faut qu'un plugin puisse avoir ses propres groupes => Ma proposition est la suivante : le .yaml contiendrait une ligne de type: ``` categorie: '<prefixe>:<chainedelangue>' ``` Comme cela le nom de la catégorie est automatiquement définie, et cela correspond rapidement à son identifiant. Une version suffisée `_explication` de la chaine de langue permettrait, si on juge utile, d'avoir explication sur le regroupement (je ne sais pas encore) 2. On mettra une categorie fallback autre 3. Il faut avoir un tri des chaines des catégories, pour hiéarchiser. Je propose un pipeline `saisies_lister_disponibles` (appeler dans la fonction homonyme). Cela permettrait non seulement de réordonner les groupes, mais aussi, si on le souhaite, de supprimer certaines saisies sur un site (pour simplifier l'interface pour les gens) 4. La question est de savoir si saisies_lister_disponibles() doit retourner les saisies en groupe par défaut, ou bien si c'est une option qu'on lui passe. Sachant qu'on avait deja mis une option pour les obsolètes. J'ai peur d'une signature à rallonge. Après on peut encore modifier actuellement, personne n'utilise le deuxième argument > on peut en faire facilenment un tableau. Mais du coup la question de ce qu'on propose par défaut se pose. Avis bienvenue, j'aimerais bien commencer à bosser sur cela la semaine prochaine, pour faire un proto. Ca commence à devenir important pour mes propres besoins.

Faudrait peut-être parler 20min à l'oral pour débroussailler, et faire le CR ici ensuite, ça sera peut-être plus rapide.

Faudrait peut-être parler 20min à l'oral pour débroussailler, et faire le CR ici ensuite, ça sera peut-être plus rapide.
Poster
Collaborator

oui. Tu aurais du temps éventuellement ce we ?

oui. Tu aurais du temps éventuellement ce we ?

Le WE prochain 23-24 ? oui je vais bien trouver 30min pour ça :)

Le WE prochain 23-24 ? oui je vais bien trouver 30min pour ça :)
Poster
Collaborator

oki, je sais pas encore mes dispo mais je te bipperai sur irc

oki, je sais pas encore mes dispo mais je te bipperai sur irc
Poster
Collaborator

Bon, on a pas fait notre réunion, mais du coup on s'est dit qu'on reprenait ce qui a été fait pour le noisetier :

  • une liste par défaut de categorier modifiable par le pipeline saisies_categories
  • chaque catégorie sous forme d'un array, si possible identique dans la structure à ce qui se fait côté noisetier
  • la question qui se pose : est-ce que comme pour le noisetier on autorise plusieurs catégories pour une saisie ?
  • reste la question de ce que doit renvoyer saisies_lister_disponibles(), sachant qu'elle est utilisés dans 3-4 plugins en plus de saisies. Je vois 3 options actuellement :
    • Laisser comme tel, et avoir une fonction qui catégorise après coup
    • Renvoyer un tableau de type 'categorie' => liste_des_saisies, et donc casser les autres appel à la fonction, mais les corriger dans la foulée pour tout les plugins concernées
    • Avoir un troisième argument qui permet dire cela, ou mieux, changer le 2 arg en tableau d'options
Bon, on a pas fait notre réunion, mais du coup on s'est dit qu'on reprenait ce qui a été fait pour le noisetier : - une liste par défaut de categorier modifiable par le pipeline saisies_categories - chaque catégorie sous forme d'un array, si possible identique dans la structure à ce qui se fait côté noisetier - la question qui se pose : est-ce que comme pour le noisetier on autorise plusieurs catégories pour une saisie ? - reste la question de ce que doit renvoyer saisies_lister_disponibles(), sachant qu'elle est utilisés dans 3-4 plugins en plus de saisies. Je vois 3 options actuellement : - Laisser comme tel, et avoir une fonction qui catégorise après coup - Renvoyer un tableau de type 'categorie' => liste_des_saisies, et donc casser les autres appel à la fonction, mais les corriger dans la foulée pour tout les plugins concernées - Avoir un troisième argument qui permet dire cela, ou mieux, changer le 2 arg en tableau d'options

Ça fait trop longtemps qu'elle existe, depuis le début de l'API + pour construire l'interface tout comme le noizetier on ne part pas des saisies pour savoir quelles catégories elles ont, mais bien des catégories dans leur ordre et pour chacun on remplit avec les saisies trouvées ; et donc pour ces deux raisons je pense que c'est forcément une autre fonction, plutôt.

Genre saisies_lister_disponibles_par_categories() ?

Ou bien c'est directement saisies_lister_categories() qui contient le pipeline, et qui en plus de sortir la liste des catégories, met aussi dans leur tableau les saisies pour chacune (identifiant, label, icone, saisies).

Ça fait trop longtemps qu'elle existe, depuis le début de l'API + pour construire l'interface tout comme le noizetier on ne part pas des saisies pour savoir quelles catégories elles ont, mais bien des catégories dans leur ordre et pour chacun on remplit avec les saisies trouvées ; et donc pour ces deux raisons je pense que c'est forcément une autre fonction, plutôt. Genre saisies_lister_disponibles_par_categories() ? Ou bien c'est directement saisies_lister_categories() qui contient le pipeline, et qui en plus de sortir la liste des catégories, met aussi dans leur tableau les saisies pour chacune (identifiant, label, icone, saisies).
Poster
Collaborator

Je me dit que selon la manière dont on affiche, etc, on pourrait avoir besoin de lister les categories sans savoir précisement ce qu'il y dedans, du coup je ne serais pas pour mettre directement dans saisies_lister_categorie()`.

Du coup saisies_lister_disponibles_par_categories() est sans doute le plus pertinent. Et la variante saisies_lister_disponibles_par_categories_sql() (ou bien un argument pour filtrer ?)

et du coup sur le multi catégorie ?

Je me dit que selon la manière dont on affiche, etc, on pourrait avoir besoin de lister les categories sans savoir précisement ce qu'il y dedans, du coup je ne serais pas pour mettre directement dans saisies_lister_categorie()`. Du coup `saisies_lister_disponibles_par_categories()` est sans doute le plus pertinent. Et la variante `saisies_lister_disponibles_par_categories_sql()` (ou bien un argument pour filtrer ?) et du coup sur le multi catégorie ?

on pourrait avoir besoin de lister les categories sans savoir précisement ce qu'il y dedans

bé qui peut le plus peut le moins non ? mais bon ça ferait du traitement plus long à chaque fois oui…

donc

  • saisies_lister_categories() pour avoir la liste des catégories dans l'ordre manuel (càd notre ordre de départ par défaut + les modifs par pipeline des gens)
  • saisies_lister_disponibles_par_categories($categorie=null) : liste les types par catégories (dans l'ordre de saisies_lister_categories()) et s'il y a un identifiant de catégorie, ne sortir que directement les saisies de celle là
  • saisies_lister_disponibles_sql_par_categories() plutôt

Pour le multi, je ne sais pas encore

  • tout comme pour le noizetier : il n'y a pas besoin du tout que ce soit une utilisation fréquente pour que ce soit utile, ça permet au moins de mettre "input" dans "champs de base" (nom à trouver), et d'avoir un autre groupe avec toutes les variantes de "input" (et donc y compris celui de base)
  • mais en même temps, ya pas autant d'histoire de "groupe thématique" comme dans les noisettes, et aussi il y a beaucoup moins de champs que de noisette : c'est juste pour rendre plus lisible une liste UN PEU longue, mais pas du tout pour organiser une liste de 50 ou plus élémentsn, ce n'est pas pile la même problématique, pas la même échelle

Donc si possible c'est peut-être mieux un seul, car comme toujours plus c'est simple, mieux c'est. (et donc là pour l'exemple considérer qu'une fois que "input" est dans le tout début dans ceux "de base", on ne le retrouve pas ensuite, c'est très bien aussi)

> on pourrait avoir besoin de lister les categories sans savoir précisement ce qu'il y dedans bé qui peut le plus peut le moins non ? mais bon ça ferait du traitement plus long à chaque fois oui… donc - saisies_lister_categories() pour avoir la liste des catégories dans l'ordre manuel (càd notre ordre de départ par défaut + les modifs par pipeline des gens) - saisies_lister_disponibles_par_categories($categorie=null) : liste les types par catégories (dans l'ordre de saisies_lister_categories()) et s'il y a un identifiant de catégorie, ne sortir que directement les saisies de celle là - saisies_lister_disponibles_sql_par_categories() plutôt Pour le multi, je ne sais pas encore - tout comme pour le noizetier : il n'y a pas besoin du tout que ce soit une utilisation fréquente pour que ce soit utile, ça permet au moins de mettre "input" dans "champs de base" (nom à trouver), et d'avoir un autre groupe avec toutes les variantes de "input" (et donc y compris celui de base) - mais en même temps, ya pas autant d'histoire de "groupe thématique" comme dans les noisettes, et aussi il y a beaucoup moins de champs que de noisette : c'est juste pour rendre plus lisible une liste UN PEU longue, mais pas du tout pour organiser une liste de 50 ou plus élémentsn, ce n'est pas pile la même problématique, pas la même échelle Donc si possible c'est peut-être mieux un seul, car comme toujours plus c'est simple, mieux c'est. (et donc là pour l'exemple considérer qu'une fois que "input" est dans le tout début dans ceux "de base", on ne le retrouve pas ensuite, c'est très bien aussi)
Poster
Collaborator

Partons sur cela alors.

Pour la typologie, je partirais bien de ce que fait le grand mechant loup (cf capture d'écran plus haut) + rajouter une catégorie "objets spip".

Partons sur cela alors. Pour la typologie, je partirais bien de ce que fait le grand mechant loup (cf capture d'écran plus haut) + rajouter une catégorie "objets spip".

au delà des "types de base" à mettre en tout premier obligatoirement, pour tout le reste je n'ai pas du tout réfléchi au classement pour l'instant… :)

effectivement tous ceux qui sélectionnent des contenus SPIP ça serait bien à regrouper

après ya peut-être des exceptions, par ex "Pays", c'est techniquement fait avec un objet SPIP, mais plus tard ça pourrait très bien juste venir d'une API, et c'est pas autant considéré comme un "contenu SPIP", c'est plus à utiliser dans une adresse, des coordonnées, etc. Mais bon faudrait que j'ai la liste la plus exhaustive possible sous les yeux (saisies + tous les plugins communs qui en ajoutent) pour voir des regroupements

au delà des "types de base" à mettre en tout premier obligatoirement, pour tout le reste je n'ai pas du tout réfléchi au classement pour l'instant… :) effectivement tous ceux qui sélectionnent des contenus SPIP ça serait bien à regrouper après ya peut-être des exceptions, par ex "Pays", c'est techniquement fait avec un objet SPIP, mais plus tard ça pourrait très bien juste venir d'une API, et c'est pas autant considéré comme un "contenu SPIP", c'est plus à utiliser dans une adresse, des coordonnées, etc. Mais bon faudrait que j'ai la liste la plus exhaustive possible sous les yeux (saisies + tous les plugins communs qui en ajoutent) pour voir des regroupements
Poster
Collaborator

Oui, mais si tu prend le cas de google, même les types de base ils les séparent typologiquement (ce qui n'empêchent pas de les mettre en premier).

Bon on va deja deja impléemnter le niveau abstrait avec queqlues essais d'affectation sur ce qui est livré dans saisies, et on ajustera à partir de là.

Oui, mais si tu prend le cas de google, même les types de base ils les séparent typologiquement (ce qui n'empêchent pas de les mettre en premier). Bon on va deja deja impléemnter le niveau abstrait avec queqlues essais d'affectation sur ce qui est livré dans saisies, et on ajustera à partir de là.
Poster
Collaborator

Bon, voilà

  • j'ai implémenté les fonctions (à quelques variantes près par rapport à ce qui avait été discuté)
  • j'ai mis des catégories, avec "divers" en fallback. Je trouve que cela marche plutot bien... sauf pour ce que j'ai mis en divers (date et champ cachée)
  • j'ai mis cela dans le constructeur de formulaire, avec un structure html minimialiste (fieldset) et sans m'occuper des styles
  • de même je n'ai pas associé d'icones aux catégories, car je laisse cela aux spécialistes comme @tcharlss pour nous faire une joli présentation et tout.

Voici ce que cela donne pour l'instant. Là je passe la main pour la suite

image

Bon, voilà - j'ai implémenté les fonctions (à quelques variantes près par rapport à ce qui avait été discuté) - j'ai mis des catégories, avec "divers" en fallback. Je trouve que cela marche plutot bien... sauf pour ce que j'ai mis en divers (date et champ cachée) - j'ai mis cela dans le constructeur de formulaire, avec un structure html minimialiste (fieldset) et sans m'occuper des styles - de même je n'ai pas associé d'icones aux catégories, car je laisse cela aux spécialistes comme @tcharlss pour nous faire une joli présentation et tout. Voici ce que cela donne pour l'instant. Là je passe la main pour la suite ![image](/attachments/d484a89c-eab9-4f0f-bf68-45cc328b1e00)
101 KiB
Poster
Collaborator

nb : selection multiple est vouée à disparaitre, il y a un ticket à ce sujet.

nb : selection multiple est vouée à disparaitre, il y a un ticket à ce sujet.
Poster
Collaborator

commme @rastapopoulos, je suis d'avis de supprimer les explications (y compris en amont, pour pas avoir de chaine de langue à traduire pour rien)

commme @rastapopoulos, je suis d'avis de supprimer les explications (y compris en amont, pour pas avoir de chaine de langue à traduire pour rien)
Poster
Collaborator

Une version

  1. Sans explication
  2. Ou la catégorie "divers" devient "défaut" (en terme technique, mais toujours avec le label divers)
  3. OÙ le met la date dans les "choix limités"
  4. Où on a "avancé" qui comprend "hidden" et "fichiers" (si cvt-upload installé)
  5. Objet SPIP > contenu editorial (en label)

image

Deux remarques comme cela

  • avec cette nouvelle structuration, le label "ajouter un champ" se voit moins bien. Sans doute faudrait-il faire un fieldset global et styliser un peu
  • Dans chaque catégorie, il faudrait avoir un tri. Le problème c'est que modifier des ordres de tableau en PHP (si les gens utilisent un pipeline) ce n'est pas évident du tout. Je proposerai d'ajouter "rang" dans le .yaml
    • si pas de rang > on met à 0
    • ainsi le rang "email" pourrait être de 10
    • le tri se ferait soit en PHP dans saisies_lister_disponibles, soit à l'affichage dans la boucle DATA (à mon avis plutot dans saisies_lister_disponibles)
    • on trierai par rang, puis par nom
Une version 1. Sans explication 2. Ou la catégorie "divers" devient "défaut" (en terme technique, mais toujours avec le label divers) 3. OÙ le met la date dans les "choix limités" 4. Où on a "avancé" qui comprend "hidden" et "fichiers" (si cvt-upload installé) 5. Objet SPIP > contenu editorial (en label) ![image](/attachments/c690906c-a933-4bb7-98f5-e32d602515c1) Deux remarques comme cela - avec cette nouvelle structuration, le label "ajouter un champ" se voit moins bien. Sans doute faudrait-il faire un fieldset global et styliser un peu - Dans chaque catégorie, il faudrait avoir un tri. Le problème c'est que modifier des ordres de tableau en PHP (si les gens utilisent un pipeline) ce n'est pas évident du tout. Je proposerai d'ajouter "rang" dans le .yaml - si pas de rang > on met à 0 - ainsi le rang "email" pourrait être de 10 - le tri se ferait soit en PHP dans saisies_lister_disponibles, soit à l'affichage dans la boucle DATA (à mon avis plutot dans saisies_lister_disponibles) - on trierai par rang, puis par nom
226 KiB
Poster
Collaborator

Reflexion faite, mettre la date avec les choix est pas terrible. Peut être dans avancé ? En tout cas "texte" me paraitrait bizarre (à moins que "texte" deviennent "base", mais bon une liste déroulante aussi c'est la base, plus qu'une date amha)

Reflexion faite, mettre la date avec les choix est pas terrible. Peut être dans avancé ? En tout cas "texte" me paraitrait bizarre (à moins que "texte" deviennent "base", mais bon une liste déroulante aussi c'est la base, plus qu'une date amha)
Poster
Collaborator

idée "texte" deviendrait "Libre" (par opposition à préfediniti) et aurait input, textarea, date et email

idée "texte" deviendrait "Libre" (par opposition à préfediniti) et aurait input, textarea, date et email

"email" est tout aussi restreint comme choix que "date", me semble.
Du coup, je verrais bien "date" avec les champs texte.

Après, les légendes + explications étaient en trop, mais les explications étaient plus parlantes, plus compréhensibles : les remettre en légendes ?

"email" est tout aussi restreint comme choix que "date", me semble. Du coup, je verrais bien "date" avec les champs texte. Après, les légendes + explications étaient en trop, mais les explications étaient plus parlantes, plus compréhensibles : les remettre en légendes ?
Poster
Collaborator

peut être oui, mais en legerement plus court, un truc intermediaire.

Et du coup "texte" faudrait voir le bon titre.

peut être oui, mais en legerement plus court, un truc intermediaire. Et du coup "texte" faudrait voir le bon titre.

PS : les styles des légendes de fieldsets sont vraiment moches de base, y'a pas eu un travail là dessus ?
(oui, ça sort complètement de saisies, je parle de styles spip)

PS : les styles des légendes de fieldsets sont vraiment moches de base, y'a pas eu un travail là dessus ? (oui, ça sort complètement de saisies, je parle de styles spip)

peut être oui, mais en legerement plus court, un truc intermediaire.

Et du coup "texte" faudrait voir le bon titre.

Champs de texte ?

En tout cas, merci pour ces évolutions, ça faisait un moment qu'on en parlait, c'est chouette ! :)

> peut être oui, mais en legerement plus court, un truc intermediaire. > > Et du coup "texte" faudrait voir le bon titre. Champs de texte ? En tout cas, merci pour ces évolutions, ça faisait un moment qu'on en parlait, c'est chouette ! :)

idée "texte" deviendrait "Libre" (par opposition à préfediniti) et aurait input, textarea, date et email

Ah oui, "Champs de saisie libre" ? (il ne faut pas trop condenser les intitulés je pense)

> idée "texte" deviendrait "Libre" (par opposition à préfediniti) et aurait input, textarea, date et email Ah oui, "Champs de saisie libre" ? (il ne faut pas trop condenser les intitulés je pense)
Poster
Collaborator

moi ca me va, j'attend l'avis des autres....

moi ca me va, j'attend l'avis des autres....
Poster
Collaborator

Rasta sur IRC était pas convaincu par les labels long. Perso je pense qu'il fallait rendre un peu plus explicite. J'ai tenté un compromis.

J'ai réaffecté les catégories + renommer "texte" en "libre".

J'ai également ajouter la possibilité d'avoir un rang dans le .yaml. Si rang pas explicitement défini : 0. Si 2 rangs égaux : ordre alpha. A noter que je n'applique le tri qu'une fois réparti par catégories, pour économiser un peu en triant sur des plus petit groupes et car il ne me semble pas qu'un retour de saisies_lister_disponibles en aurait vraiment besoin.

bref, cela donne ceci (avec divers tout à la fin, en fallback)

image

Rasta sur IRC était pas convaincu par les labels long. Perso je pense qu'il fallait rendre un peu plus explicite. J'ai tenté un compromis. J'ai réaffecté les catégories + renommer "texte" en "libre". J'ai également ajouter la possibilité d'avoir un rang dans le .yaml. Si rang pas explicitement défini : 0. Si 2 rangs égaux : ordre alpha. A noter que je n'applique le tri qu'une fois réparti par catégories, pour économiser un peu en triant sur des plus petit groupes et car il ne me semble pas qu'un retour de saisies_lister_disponibles en aurait vraiment besoin. bref, cela donne ceci (avec divers tout à la fin, en fallback) ![image](/attachments/1ae864ef-43c2-4b27-abe1-0162cb8e9a7f)
242 KiB

Je pense qu'on peut encore simplifier.

Quand un même mot est répété plusieurs fois, sur la majorité, c'est comme s'il n'avait pas besoin d'être là. D'autant plus quand le contexte entier de la page ne parle que de ça. Je pense donc qu'au moins le mot "champs" peut être totalement omis : on sait parfaitement que c'est une liste des champs possibles, ya que ça, c'est le but même d'un constructeur de formulaire.

  • Saisie libre, ou Réponse libre suffit (moi j'aime assez le "réponse" utilisé par google)
  • Choix restreint
  • Structuration du formulaire (outils peut être omis)
  • Sélection de contenu SPIP (pas besoin de mettre contenu + éditorial, et partout ailleurs dans les form de config des liaisons, c'est le mot "contenu" seul, restons-en là)
  • Divers
Je pense qu'on peut encore simplifier. Quand un même mot est répété plusieurs fois, sur la majorité, c'est comme s'il n'avait pas besoin d'être là. D'autant plus quand le contexte entier de la page ne parle que de ça. Je pense donc qu'au moins le mot "champs" peut être totalement omis : on sait parfaitement que c'est une liste des champs possibles, ya que ça, c'est le but même d'un constructeur de formulaire. - Saisie libre, ou Réponse libre suffit (moi j'aime assez le "réponse" utilisé par google) - Choix restreint - Structuration du formulaire (outils peut être omis) - Sélection de contenu SPIP (pas besoin de mettre contenu + éditorial, et partout ailleurs dans les form de config des liaisons, c'est le mot "contenu" seul, restons-en là) - Divers
Poster
Collaborator

Je crois que c'est l'expression "Saisie" qui me rebute, je la touvais trop technique toute seule. D'où le "champ" redondant. Mais oui pour ces termes.

Je crois que c'est l'expression "Saisie" qui me rebute, je la touvais trop technique toute seule. D'où le "champ" redondant. Mais oui pour ces termes.
Poster
Collaborator

Ah et aussi "Ajouter un champ" étant stylistiquement peu visible (mais ca peut se corriger très certainement !) je l'avais repeter. En fait je me dit que "ajouter un champ" devraot être un legend d'un fieldset global

Ah et aussi "Ajouter un champ" étant stylistiquement peu visible (mais ca peut se corriger très certainement !) je l'avais repeter. En fait je me dit que "ajouter un champ" devraot être un legend d'un fieldset global
Poster
Collaborator

ce qui donnerait

image

ce qui donnerait ![image](/attachments/d5f4e46e-65d3-4f64-9bbb-426e713babb3)
245 KiB
Poster
Collaborator

(je me demande si fichier devrait pas remonter dans "saisies libres"

(je me demande si fichier devrait pas remonter dans "saisies libres"
Poster
Collaborator

(et j'ai oublié de renommer saisie en réponse, je vais le faire... je commiterai après les prochains retours)

(et j'ai oublié de renommer saisie en réponse, je vais le faire... je commiterai après les prochains retours)
Owner

Nickel tout ça.

Je sens que je vais plus passer des plombes à retrouver la saisie ligne de texte :p

Quelques détails :

  • Choix restreints / Sélection de contenus Spip : pour le 2ème groupe il s'agit aussi d'un type précis de choix restreints, est-ce qu'il vaudrait pas mieux reprendre le même terme ? « Choix de contenus Spip »
  • « Réponse libre » ça fait un peu penser à des réponse à un formulaire QCM, La 1ère formulation me semble plus générale. Dans champ extras, « réponse libre » ça semblerait un peu déplacé par exemple.
  • « Ajoute un champ » est certes plus lisible, mais les fieldsets imbriqués, ça fait mal.
Nickel tout ça. Je sens que je vais plus passer des plombes à retrouver la saisie ligne de texte :p Quelques détails : * Choix restreints / Sélection de contenus Spip : pour le 2ème groupe il s'agit aussi d'un type précis de choix restreints, est-ce qu'il vaudrait pas mieux reprendre le même terme ? « Choix de contenus Spip » * « Réponse libre » ça fait un peu penser à des réponse à un formulaire QCM, La 1ère formulation me semble plus générale. Dans champ extras, « réponse libre » ça semblerait un peu déplacé par exemple. * « Ajoute un champ » est certes plus lisible, mais les fieldsets imbriqués, ça fait mal.
Poster
Collaborator

Choix restreints / Sélection de contenus Spip : pour le 2ème groupe il s'agit aussi d'un type précis de choix restreints, est-ce qu'il vaudrait pas mieux reprendre le même terme ? « Choix de contenus Spip »

Pq pas oui

« Réponse libre » ça fait un peu penser à des réponse à un formulaire QCM, La 1ère formulation me semble plus générale. Dans champ extras, « réponse libre » ça semblerait un peu déplacé par exemple.

bien vu, donc plutot pour saisie libre, mais retour des gens attendu

« Ajoute un champ » est certes plus lisible, mais les fieldsets imbriqués, ça fait mal.

Sémantiquement il me semble que c'est mieux. Après on est sur le problème des fieldsets imbriqués en general. Mais j'imagine qu'un pro du stylage comme toi pourrait régler cela :)

> Choix restreints / Sélection de contenus Spip : pour le 2ème groupe il s'agit aussi d'un type précis de choix restreints, est-ce qu'il vaudrait pas mieux reprendre le même terme ? « Choix de contenus Spip » Pq pas oui > « Réponse libre » ça fait un peu penser à des réponse à un formulaire QCM, La 1ère formulation me semble plus générale. Dans champ extras, « réponse libre » ça semblerait un peu déplacé par exemple. bien vu, donc plutot pour saisie libre, mais retour des gens attendu > « Ajoute un champ » est certes plus lisible, mais les fieldsets imbriqués, ça fait mal. Sémantiquement il me semble que c'est mieux. Après on est sur le problème des fieldsets imbriqués en general. Mais j'imagine qu'un pro du stylage comme toi pourrait régler cela :)

Sémantiquement c'est pas mieux si au final c'est pas un groupe de champ… Là sémantique ça ne l'est pas, en vrai c'est plutôt comme un formulaire à part, avec juste une liste de boutons, c'est même pas des champs à remplir (c'est une sous partie du formulaire seulement parce que depuis le début c'est construit comme un immense gros formulaire tout-en-un). Tout la partie d'ajout, moi je vois ça plutôt comme une partie séparée en soi, donc c'est plutôt un intertitre, H2 ou ce genre pour séparer.

Pour les contenus SPIP moi au départ je proposais juste : "Contenus SPIP" tout court. On s'en fiche définir que c'est "un choix", "une sélection" à cet endroit : la raison d'exister du groupe c'est de regrouper tout ce qui concerne "des contenus SPIP". Tout comme "champs" précédemment, je trouve que "choix" ou "sélection" est superflu ici, ne dit rien de particulièrement utile. Mot en moins, bruit en moins, on va à l'essentiel. Le but premier c'est de découper et d'ordonner pour que la lecture soit plus fluide et logique suivant la fréquence d'utilisation, pas de donner des explications détaillées.

Sémantiquement c'est pas mieux si au final c'est pas un groupe de champ… Là sémantique ça ne l'est pas, en vrai c'est plutôt comme un formulaire à part, avec juste une liste de boutons, c'est même pas des champs à remplir (c'est une sous partie du formulaire seulement parce que depuis le début c'est construit comme un immense gros formulaire tout-en-un). Tout la partie d'ajout, moi je vois ça plutôt comme une partie séparée en soi, donc c'est plutôt un intertitre, H2 ou ce genre pour séparer. Pour les contenus SPIP moi au départ je proposais juste : "Contenus SPIP" tout court. On s'en fiche définir que c'est "un choix", "une sélection" à cet endroit : la raison d'exister du groupe c'est de regrouper tout ce qui concerne "des contenus SPIP". Tout comme "champs" précédemment, je trouve que "choix" ou "sélection" est superflu ici, ne dit rien de particulièrement utile. Mot en moins, bruit en moins, on va à l'essentiel. Le but premier c'est de découper et d'ordonner pour que la lecture soit plus fluide et logique suivant la fréquence d'utilisation, pas de donner des explications détaillées.
Poster
Collaborator

H2 ou ce genre pour séparer.

très franchement j'avais hésité avec cela. H2 + hr ?

> H2 ou ce genre pour séparer. très franchement j'avais hésité avec cela. H2 + hr ?
Owner

H2 ça devrait suffire oui.
Le div ayant déjà une bordure supérieure, le hr semble pas nécessaire.

H2 ça devrait suffire oui. Le div ayant déjà une bordure supérieure, le hr semble pas nécessaire.
Poster
Collaborator

le hr c'est sémantique, la bordure supérieure c'est du pure css. Mais oui, pas forcément nécessaire.

Et pour chaque catégories? on reste sur du fieldset ou on bascule en h3 ?

le hr c'est sémantique, la bordure supérieure c'est du pure css. Mais oui, pas forcément nécessaire. Et pour chaque catégories? on reste sur du fieldset ou on bascule en h3 ?
Poster
Collaborator

bon ca donnerait ca

image

bon ca donnerait ca ![image](/attachments/91098fbf-10f4-4101-b7af-3c9d5b30472d)
159 KiB
Poster
Collaborator

OUPS, la bonne capture

image

OUPS, la bonne capture ![image](/attachments/640a8239-a1ce-431d-99f4-0f56eeb25675)
155 KiB

Oh ! J'avais point vu toutes ces captures...
Cool.

Je proposerais bien :

  • structuration > structure
  • contenu spip > contenu éditorial
  • Mettre une marge après chaque fieldset pour aérer un peu (c'est les styles de SPIP par défaut je pense là, mais bon)
Oh ! J'avais point vu toutes ces captures... Cool. Je proposerais bien : - structuration > structure - contenu spip > contenu éditorial + Mettre une marge après chaque fieldset pour aérer un peu (c'est les styles de SPIP par défaut je pense là, mais bon)
Owner

Ça me paraît très bien tout ça.

contenu spip > contenu éditorial

Ah oui, +1

Ça me paraît très bien tout ça. > contenu spip > contenu éditorial Ah oui, +1
Owner

Choix restreint ne pourrait s'appeler Champ Liste ?
Fichiers dans Champ Libre ?

Choix restreint ne pourrait s'appeler Champ Liste ? Fichiers dans Champ Libre ?
Poster
Collaborator

Choix restreint ne pourrait s'appeler Champ Liste ?

On a un plugin qui propose une saisie "liste". Ca permet par exemple d'inserer x fois de suite "Nom - Prénom - Date de Naisaance"

Fichiers dans Champ Libre ?

OUI, c'est juste que c'est un plugin à part, du coup j'avais pas fait. Mais oui.

> Choix restreint ne pourrait s'appeler Champ Liste ? On a un plugin qui propose une saisie "liste". Ca permet par exemple d'inserer x fois de suite "Nom - Prénom - Date de Naisaance" > Fichiers dans Champ Libre ? OUI, c'est juste que c'est un plugin à part, du coup j'avais pas fait. Mais oui.
Poster
Collaborator

a aussi pour "champ liste" la case à cocher est pas vraiment une liste :-)

a aussi pour "champ liste" la case à cocher est pas vraiment une liste :-)
Poster
Collaborator

Apercu

image

Apercu ![image](/attachments/44d262f7-a0e9-4c35-947d-767552feb16e)
154 KiB
Poster
Collaborator

Caramba, encore raté, voilà la dernière version

image

juste une question sur la catégorie "Contenu éditorial". Au niveau de la clé technique, j'ai mis "objet". De même pour "divers" c'est "defaut". Est-ce qu'il faudrait changer?

Caramba, encore raté, voilà la dernière version ![image](/attachments/5f68beb5-0f97-4f95-9cfb-4b5f3b0e87de) juste une question sur la catégorie "Contenu éditorial". Au niveau de la clé technique, j'ai mis "objet". De même pour "divers" c'est "defaut". Est-ce qu'il faudrait changer?
157 KiB

Pas spécialement, dans tous les forms de config de liaison (core et plugins) au niveau technique c'est "lier_objets" ou ce genre, mais dans l'interface c'est "Lier les patates aux contenus :"

Pas spécialement, dans tous les forms de config de liaison (core et plugins) au niveau technique c'est "lier_objets" ou ce genre, mais dans l'interface c'est "Lier les patates aux contenus :"
Poster
Collaborator

La toute dernière version, après des simplifications de libellés

image

Si pas de réaction d'ici samedi, je publie.

La toute dernière version, après des simplifications de libellés ![image](/attachments/08d25047-73f6-4766-84ea-4e65c82f3d50) Si pas de réaction d'ici samedi, je publie.
148 KiB
Owner








désolé
![](https://media.giphy.com/media/xT1XGT9ersCCKjhVny/giphy.gif) <br> <br> <br> <br> <br> <br> <br> <small>désolé</small>

Ma réaction, c'est que faut des icones SVG pour les saisies !

Sinon c'est TOP ! Bravo à vous.

Ma réaction, c'est que faut des icones SVG pour les saisies ! Sinon c'est TOP ! Bravo à vous.
Poster
Collaborator

oui pour les icones svg c'est prévu lorsque la 3.3 sortira :) on fera alors une branche de saisies compatible que 3.3, car on veut aussi purger le code

oui pour les icones svg c'est prévu lorsque la 3.3 sortira :) on fera alors une branche de saisies compatible que 3.3, car on veut aussi purger le code
maieul referenced this issue from a commit 2 months ago
maieul closed this issue 2 months ago
Poster
Collaborator

Voilà, suite aux remarques de syntax d'Eric c'est intégré et envoyé.

J'enverrai dans l'après midi une information à ce sujet sur la liste.

Agenda et CVT upload sont deja catégorisés.

Voilà, suite aux remarques de syntax d'Eric c'est intégré et envoyé. J'enverrai dans l'après midi une information à ce sujet sur la liste. Agenda et CVT upload sont deja catégorisés.
Sign in to join this conversation.
No Milestone
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.