Project

General

Profile

Actions

Souhaits #1775

closed

Display of core and dynamic fields and their information

Added by Johan Cwiklinski 9 months ago. Updated 7 months ago.

Status:
Fermé
Priority:
Normal
Category:
IHM
Target version:
Start date:
01/25/2024
Due date:
% Done:

100%

Estimated time:

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


Files

clipboard-202401250913-1deoh.png (17 KB) clipboard-202401250913-1deoh.png Dynamic field information with Galette 0.9.6.1 Johan Cwiklinski, 01/25/2024 09:13 AM
clipboard-202401250914-etwzm.png (12.5 KB) clipboard-202401250914-etwzm.png Dynamic field information with Galette 1.0.0 Johan Cwiklinski, 01/25/2024 09:14 AM
Capture02.JPG (89.5 KB) Capture02.JPG Frederic CROZET, 02/22/2024 08:10 AM
Capture01.JPG (72.6 KB) Capture01.JPG Frederic CROZET, 02/22/2024 08:10 AM
register-before_after.png (198 KB) register-before_after.png Guillaume AGNIERAY, 02/23/2024 12:02 PM
add_member-before_after.png (264 KB) add_member-before_after.png Guillaume AGNIERAY, 02/23/2024 12:03 PM
config_core_fields.png (76.4 KB) config_core_fields.png Guillaume AGNIERAY, 02/23/2024 12:03 PM
config_dynamic_fields_list.png (64.3 KB) config_dynamic_fields_list.png Guillaume AGNIERAY, 02/23/2024 12:24 PM
config_dynamic_fields_modal.png (77.6 KB) config_dynamic_fields_modal.png Guillaume AGNIERAY, 02/23/2024 12:24 PM
core-fields-new-ui.png (190 KB) core-fields-new-ui.png Guillaume AGNIERAY, 02/27/2024 12:51 AM
Actions #1

Updated by Guillaume AGNIERAY 8 months ago

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 ?

Actions #2

Updated by Johan Cwiklinski 8 months ago

  • Tracker changed from Evolution to 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 ;)

Actions #3

Updated by Guillaume AGNIERAY 8 months ago

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.

Actions #4

Updated by Johan Cwiklinski 8 months ago

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

Updated by Frederic CROZET 8 months ago

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

Actions #6

Updated by Johan Cwiklinski 8 months ago

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 ?

Actions #7

Updated by Manuel Her 8 months ago

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

Updated by Guillaume AGNIERAY 8 months ago

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.
Actions #9

Updated by Johan Cwiklinski 8 months ago

  • Status changed from Nouveau to In Progress
  • Assignee set to Guillaume AGNIERAY
  • Target version set to 1.1.0
Actions #10

Updated by Guillaume AGNIERAY 8 months ago

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 :)

Actions #11

Updated by Johan Cwiklinski 8 months ago

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 :)

Actions #12

Updated by Guillaume AGNIERAY 8 months ago

  • Status changed from In Progress to Résolu
  • % Done changed from 0 to 100
Actions #13

Updated by Johan Cwiklinski 7 months ago

  • Status changed from Résolu to Fermé
Actions

Also available in: Atom PDF