Projet

Général

Profil

Actions

Souhaits #1775

fermé

Display of core and dynamic fields and their information

Ajouté par Johan Cwiklinski il y a 10 mois. Mis à jour il y a 9 mois.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
IHM
Version cible:
Début:
25/01/2024
Echéance:
% réalisé:

100%

Temps estimé:

Description

See https://forums.galette.eu/d/11-dicussion-sur-la-nouvelle-plateforme-galette-100

With 0.9.6:
Dynamic field information with Galette 0.9.6.1

With 1.0:
Dynamic field information with Galette 1.0.0

2 requests here:
- display dynamic information before field itself, as it was in 0.9.6,
- being able to ask a field to take the full width


Fichiers

clipboard-202401250913-1deoh.png (17 ko) clipboard-202401250913-1deoh.png Dynamic field information with Galette 0.9.6.1 Johan Cwiklinski, 25/01/2024 09:13
clipboard-202401250914-etwzm.png (12,5 ko) clipboard-202401250914-etwzm.png Dynamic field information with Galette 1.0.0 Johan Cwiklinski, 25/01/2024 09:14
Capture02.JPG (89,5 ko) Capture02.JPG Frederic CROZET, 22/02/2024 08:10
Capture01.JPG (72,6 ko) Capture01.JPG Frederic CROZET, 22/02/2024 08:10
register-before_after.png (198 ko) register-before_after.png Guillaume AGNIERAY, 23/02/2024 12:02
add_member-before_after.png (264 ko) add_member-before_after.png Guillaume AGNIERAY, 23/02/2024 12:03
config_core_fields.png (76,4 ko) config_core_fields.png Guillaume AGNIERAY, 23/02/2024 12:03
config_dynamic_fields_list.png (64,3 ko) config_dynamic_fields_list.png Guillaume AGNIERAY, 23/02/2024 12:24
config_dynamic_fields_modal.png (77,6 ko) config_dynamic_fields_modal.png Guillaume AGNIERAY, 23/02/2024 12:24
core-fields-new-ui.png (190 ko) core-fields-new-ui.png Guillaume AGNIERAY, 27/02/2024 00:51

Mis à jour par Guillaume AGNIERAY il y a 9 mois

Johan Cwiklinski a écrit :

2 requests here:
- display dynamic information before field itself, as it was in 0.9.6,

Well, on this one, the fact is that in 1.0 the fields are displayed in a 3 columns grid whereas in 0.9 they were displayed in a single column.
Moving information above the field would result in unaligned fields on the same line of the grid. Which, I think, could more easily lead in situations where it could be worse regarding readability and usability of the form.

Maybe we could let that choice up to the decision of the admin in the preferences ?
I mean : choose the grid or one column display, and/or display information above fields (or maybe in each field's configuration).

- being able to ask a field to take the full width

I don't think the idea here is to make a form "builder".
But this one is necessary, I agree.

In my opinion, this would require at the minimum :
  • a new setting to choose the grid size of the form (1, 2, 3, ... columns)
  • a new setting on each field to choose how many columns it occupies in the grid
  • a solution to deal with each field permissions on the form depending the user's role
On this last point, 3 solutions in my mind :
  1. without permission, the field is simply not displayed but the place it would have occupied is preserved (and thus visually empty)
  2. the fields with permissions restricted to group members and up are always grouped together below the fields visible to everyone
  3. create new settings screens to set the order and colum size in the grid of each field depending on the possible permissions (in other words, 1 new settings sreen to define the form displayed to group managers and up, and another to define the form displayed publicly and to common members

Do you see things otherwise ?

Mis à jour par Johan Cwiklinski il y a 9 mois

  • Tracker changé de Evolution à Souhaits

Guillaume AGNIERAY a écrit (#note-1):

Johan Cwiklinski a écrit :

2 requests here:
- display dynamic information before field itself, as it was in 0.9.6,

Well, on this one, the fact is that in 1.0 the fields are displayed in a 3 columns grid whereas in 0.9 they were displayed in a single column.
Moving information above the field would result in unaligned fields on the same line of the grid. Which, I think, could more easily lead in situations where it could be worse regarding readability and usability of the form.

Maybe we could let that choice up to the decision of the admin in the preferences ?
I mean : choose the grid or one column display, and/or display information above fields (or maybe in each field's configuration).

I'll have to think a bit more about that.

Honestly, all that seems quite complicated. Most of the time, display as it currently exists will just do the work, most of the users won't need that.
Also, this would break the "continuity" between core fields and dynamic ones.

Also, one of the goals that is already hard to reach is to make core and dynamic fields the same (so we can use dynamic fields along with core ones, add them on lists, ... ,... ,...). Adding special features on only dynamic fields will make that even harder, and I don't think we'll want to deal with such parameters with core fields.

I don't think the idea here is to make a form "builder".

No, that certainly not the idea :)

But this one is necessary, I agree.

Hum... Some may want that, but is this necessary? There is only one user that have complained about that until now.

In my opinion, this would require at the minimum :
  • a new setting to choose the grid size of the form (1, 2, 3, ... columns)
  • a new setting on each field to choose how many columns it occupies in the grid
  • a solution to deal with each field permissions on the form depending the user's role

Well... This is a form builder, isn't it? :D

As I've said at the beginning, I'll have to think again about the original issue; but I don't think I'm going to accept to do/maintain so complex changes. I did not have all implications in mind when I've openend this ticket ;)

Mis à jour par Guillaume AGNIERAY il y a 9 mois

Johan Cwiklinski a écrit (#note-2):

Guillaume AGNIERAY a écrit (#note-1):

Maybe we could let that choice up to the decision of the admin in the preferences ?
I mean : choose the grid or one column display, and/or display information above fields (or maybe in each field's configuration).

I'll have to think a bit more about that.

Honestly, all that seems quite complicated. Most of the time, display as it currently exists will just do the work, most of the users won't need that.
Also, this would break the "continuity" between core fields and dynamic ones.

Setting the grid size and the position of the information in Galette's main preferences won't break the continuity between core and dynamic fields. Those setting would be applied to both.

Also, one of the goals that is already hard to reach is to make core and dynamic fields the same (so we can use dynamic fields along with core ones, add them on lists, ... ,... ,...). Adding special features on only dynamic fields will make that even harder, and I don't think we'll want to deal with such parameters with core fields.

Those special features have to be added to both type of fields as both are concerned by the issue actually.

I don't think the idea here is to make a form "builder".

No, that certainly not the idea :)

But this one is necessary, I agree.

Hum... Some may want that, but is this necessary? There is only one user that have complained about that until now.

In my opinion, this would require at the minimum :
  • a new setting to choose the grid size of the form (1, 2, 3, ... columns)
  • a new setting on each field to choose how many columns it occupies in the grid
  • a solution to deal with each field permissions on the form depending the user's role

Well... This is a form builder, isn't it? :D

At this point, I wouldn't call that a form builder. But rather a fields organizer :D

As I've said at the beginning, I'll have to think again about the original issue; but I don't think I'm going to accept to do/maintain so complex changes. I did not have all implications in mind when I've openend this ticket ;)

Please have a look at PR#440

The first commit fixes the first part of the request (information position) and adds the possiblity to choose the member form grid size (applied to core and dynamic fields). The new settings were added in the "Parameters" tab of the preferences page.

The second commit implements the UI part of the minimum new property required on fields (core and dynamic) that would allow to handle how many columns the field occupies in the member form's grid depending on the value set in the preferences. This could be extented to add another property on all fields (core and dynamic) to define the information position field by field rather than globally.

Regarding my concern about the visibility setting of each field, I don't think it is necessary to deal with it. A simple workaround is to manually order the fields by visibility.

Mis à jour par Johan Cwiklinski il y a 9 mois

I'll take a look at the PR until the end of the week; thanks :)

Mis à jour par Frederic CROZET il y a 9 mois

Oui, en effet, c'est assez déroutant, notamment pour la fiche adhérent avec les infos sur une seule colonne et cette même fiche lors de sa modification en 3 colonnes (voir images ci-jointes).
C'est un peu déroutant car il y a également des décalages si le titre est trop long

Mis à jour par Johan Cwiklinski il y a 9 mois

Frederic CROZET a écrit (#note-5):

Oui, en effet, c'est assez déroutant, notamment pour la fiche adhérent avec les infos sur une seule colonne et cette même fiche lors de sa modification en 3 colonnes (voir images ci-jointes).

Pour le coup, la présente demande à l'origine ne concerne que le formulaire, pas l'affichage de la fiche elle-même.

C'est un peu déroutant car il y a également des décalages si le titre est trop long

Quel titre ?

Mis à jour par Manuel Her il y a 9 mois

Bonjour,
En attendant un code propre, vous pouvez ajouter cette ligne dans member_form.html.twig :

<style>.accordion .field, .accordion .column {width: 100% !important; } </style>

juste après :
{% block content %}

Manuel

Mis à jour par Guillaume AGNIERAY il y a 9 mois

Johan Cwiklinski a écrit (#note-6):

Frederic CROZET a écrit (#note-5):

Oui, en effet, c'est assez déroutant, notamment pour la fiche adhérent avec les infos sur une seule colonne et cette même fiche lors de sa modification en 3 colonnes (voir images ci-jointes).

Pour le coup, la présente demande à l'origine ne concerne que le formulaire, pas l'affichage de la fiche elle-même.

Oui. L' affichage de la fiche doit rester sur une seule colonne à mon avis. C'est la forme la plus lisible.

C'est un peu déroutant car il y a également des décalages si le titre est trop long

Quel titre ?

Les labels des champs je suppose.

C'est un défaut parmi d'autres inhérent à l'affichage systématique en 3 colonnes sans autre possibilité que de changer l'ordre des champs.
Mais cela dépendra toujours aussi de la largeur de l'écran utilisé.

Plus généralement, l'affichage du formulaire en grille systématique de 3 colonnes n'est pas toujours logique et peut compliquer son utilisation.
Un moyen de définir la place occupée par chaque champ dans la grille permettrait aux administrateurs de palier ces défauts et d'améliorer un peu les choses en fonction de leur propre configuration.

Le but des changements proposés vise à laisser plus de flexiblité selon les besoins (toujours très différents et variables dès qu'il est question de formulaire).

Donc déjà, pour les cas les plus simples, on peut assez simplement proposer à nouveau l'affichage par défaut sur une seule colonne dans les préférences. Et peut-être même en faire de nouveau l'affichage par défaut.

Dans ce cas précis, permettre de choisir globalement l'emplacement des infos des champs n'a aucune incidence sur les décalages que cela peut engendrer avec un affichage sur plusieurs colonnes.

Dans le cas de l'affichage en colonnes, le strict minimum demandé était d'afficher un champ sur toute la largeur.
Donc par extension, on peu en profiter pour demander à un champ de ne s'afficher que sur la moitié.
Et si tout le formulaire sur 1 seule colonne ce n'est pas assez, et que sur 3 c'est trop, autant en profiter pour permettre de choisir une complexité intermédiaire avec une grille de 2 colonnes :)

Là, j'en suis à un point où je peux définir la place occupées par les champs aussi bien pour les dynamiques que ceux du cœur. Pour une grille par défaut de 2 ou 3 colonnes. Ça ne nécessite en base de données que l'ajout d'un champ correspondant dans les tables respectives de chaque type de champ (pour le moment je n'ai pas encore poussé ces modifs sur la PR).

Exemple du formulaire d'inscription avant/après sur 3 colonnes par défaut :

Exemple du formulaire d'ajout d'adhérent :

Et de la même manière, il serait possible de choisir champ par champ la position des informations.
Dans ce cas plus besoin d'option globale dans les préférences. Par défaut elles sont affichées en dessous. Et selon le cas, le paramétrage (taille de grille, colonnes occupées), le contenu des infos en question, l'ordre des champs, etc., un admin pourra ajuster ça dans les options uniquement pour les champs qu'il voudra.

Je pense que les ajouts que j'apporte sont "corrects" d'un point de vue du modèle de données des champs et que ça n'introduira aucune différence entre les champs du cœur et les champs dynamiques.

Pouvoir choisir la position des infos pour les champs du cœur n'a aucune utilité actuellement puisqu'il n'est pas possible de les personnaliser. Mais si l'objectif est un jour que les champs du cœur et les champs dynamiques ne soient qu'une seule et même entité, a priori cela permettra de personnaliser les infos des champs du cœur, et donc leur position de la même manière, champs par champ.

La question maintenant c'est l'interface utilisateur.
Actuellement, pour les champs du cœur :

Pour les champs dynamiques :

Je m'avance certainement un peu vite, mais je pense que même en l'état il y a moyen de "fusionner" les 2 interfaces :
  • utiliser la présentation par onglets et la liste en tableau sur les champs du cœur,
  • appliquer la modification de l'ordre des champs par glisser-déposer aux lignes des tableaux et aux onglets,
  • modifier les propriétés personnalisables des champs du cœur dans une fenêtre modale comme c'est le cas pour les champs dynamiques.

Mis à jour par Johan Cwiklinski il y a 9 mois

  • Statut changé de Nouveau à In Progress
  • Assigné à mis à Guillaume AGNIERAY
  • Version cible mis à 1.1.0

Mis à jour par Guillaume AGNIERAY il y a 9 mois

Guillaume AGNIERAY a écrit (#note-8):

Je m'avance certainement un peu vite, mais je pense que même en l'état il y a moyen de "fusionner" les 2 interfaces :
  • utiliser la présentation par onglets et la liste en tableau sur les champs du cœur,
  • appliquer la modification de l'ordre des champs par glisser-déposer aux lignes des tableaux et aux onglets,
  • modifier les propriétés personnalisables des champs du cœur dans une fenêtre modale comme c'est le cas pour les champs dynamiques.

Pour la modification dans une modale, il manque pas mal de choses.
Mais pour le reste c'est bon :)

Mis à jour par Johan Cwiklinski il y a 9 mois

Guillaume AGNIERAY a écrit (#note-10):

Pour la modification dans une modale, il manque pas mal de choses.
Mais pour le reste c'est bon :)

Merci :)

Mis à jour par Guillaume AGNIERAY il y a 9 mois

  • Statut changé de In Progress à Résolu
  • % réalisé changé de 0 à 100

Mis à jour par Johan Cwiklinski il y a 9 mois

  • Statut changé de Résolu à Fermé
Actions

Formats disponibles : Atom PDF