Produits Entr'ouvert » w.c.s.

‎Le problème que tu évoques c'est de devoir laisser tomber / abandonner une démarche en cours parce que certaines données sont manquantes et qu'il faut passer par une autre démarche pour les saisir.
Ergonomiquement ça peut être démotivant oui.

Si la saisie de cette démarche est importante (perte d'argent si pas fait, par exemple), l'utilisateur va pester mais il va aller au bout, si il y arrive.

Le cas d'ouvrir dans un nouvel onglet, je n'y crois pas (mais il faudrait tester).
Je pense que les utilisateurs prennent le plie d'ouvrir un lien dans un nouvel onglet seulement si après plusieurs essais déplaisants ils se rendent compte que dans ce cas-là, la fonctionnalité est profitable. Ça nécessite l'apprentissage d'une habitude dans un cas précis et redondant. Donc non valable pour une interface qu'on utilise une fois par an.

Exemple de parcours problématique sans ouvrir dans un nouvel onglet :

• Le user rempli sa démarche, il manque un enfant
• Il suit le lien qui l’emmène vers une nouvelle démarche
• Il saisit les données de la nouvelle fiche et là
  • soit il fait back plein de fois, avec toutes les alertes de revoie des données de formulaire
  • Soit il récupère la page dans l'historique (balaise), mais dans ces 2 cas la page est possiblement récupérée dans le cache, dans sans feedback de ses modifs.
  • Soit il a noté le numéro de la démarche (balaise)
  • Soit il recommence la démarche initiale (certainement le plus probable) en pestant sur l'argent public dépensé dans une appli mal branlée.

Ce que tu proposes Pierre serait ergonomiquement intéressant, que ce soit un popup ou autre n'a pas d'importance à ce niveau.

L'idée 1 serait de pouvoir charger une démarche courte et complémentaire en parallèle d'une autre dans le même écran, permettant de la saisir et de venir compléter à la volée les infos de la première démarche.

Techniquement, il faudrait pour cela pourvoir charger une demarche en ajax, la valider en ajax et injecter son résultat au bon endroit dans la première démarche. Rien de tel n'existe.

L'autre solution, serait d'avoir directement dans la démarche initiale, les champs de formulaires permettant de créer la nouvelle fiche. Champs masqués par défaut qui viendraient s'afficher à la demande. Et si les champs sont remplie, la demande créé la fiche.

Et je ne suis la bonne personne pour te dire si c'est faisable ou pas.

Une dernière idée, dans la cas d'une saisi de fiche à partir d'une nouvelle démarche (cas actuel) mais provenant d'une démarche précédente, réussir à le rediriger là où il vient (la démarche précédente). Le faire retomber sur ses pattes.

Ma préférence va à la popup, pour garder le contact visuel avec le travail d'origine. Certes ça réduit l'espace d'affichage de l'info mais on arrive bien à afficher les infos sur mobile, alors...

Du côté du fonctionnement de l'admin django, on a :

• ouverture en vraie fenêtre popup de navigateur
• stylée pour avoir uniquement le formulaire (…&_popup=1)
  • c'est quelque chose qui pourrait sans doute être facilité ici via #49405
• à la validation, fermeture de la popup, ajout/sélection nouveaux id/text dans la liste

comme on ne peut saisir des fiches que dans le backoffice (?), je limite ce ticket au backoffice, lorsque le user a les droits d'édition sur la card à sélectionner ?

et je vois des tests en erreurs, je revois ma copie ..

Petit rebasage à faire après #52934; à part ça tout ok, deux remarques :

+<a class="add-related" id="add_form_{{ widget.name }}" 
+    href="{{ widget.add_related_url }}?_popup=1" 
+    title="{% blocktrans with card=widget.get_title %}Add another {{ card }}{% endblocktrans %}">
+</a>

pour l'accessibilité/navigation il vaut mieux avoir un vrai contenu, je serais pour plutôt avoir <a class="add-related pk-button" ...>+</a>, (d'un test rapide ça ferait un petit désalignement avec le select2 devant mais je préfère chercher ensuite à ajuster ça.

+            if carddef and carddef.can_user_add_cards(get_request().user):
+                kwargs['add_related_url'] = carddef.get_backoffice_submission_url()

j'ajouterais une vérif get_request().is_in_backoffice().

ok je fais les deux: vider le footer et le masquer en css, comme on fait pour le header

On a une fenêtre plutôt qu'une popup c'est négociable ?

Sauf configuration particulière de ton navigateur c'est une fenêtre popup; mais oui c'est une vraie fenêtre popup, pas un affichage dans la page même, il y a trop de contexte navigateur à avoir; on a adopté la même méthode sûre (utilisée dans l'admin django).

Quand on utilise grid sur une liste, le "+" semble repoussé sous le champ même s'il y a de la place pour l'afficher (cf capture mes deux champs liste ont des grid-2-3)

Je regarderai cet aspect, #53192.

Si on a sur le même écran [...]

#53194.

Frédéric Péters a écrit :

c'est une vraie fenêtre popup, pas un affichage dans la page même, il y a trop de contexte navigateur à avoir; on a adopté la même méthode sûre (utilisée dans l'admin django).

De mon point de vue comme on est dans un contexte métier et pas grand public, on pourrait se permettre d'avoir quelques exigences concernant la conf du navigateur. Mais je ne mesure pas leur étendue pour avoir un contexte nous permettant d'avoir sereinement une "vraie" popup.

Merci pour les tickets créés.

quelques exigences concernant la conf du navigateur

J'ai peut-être laissé penser des choses en parlant de ta configuration de navigateur, et il est sans doute nécessaire de définir les termes étant donnés qu'on parle me semble-t-il de juste totalement différente avec "vraie popup".

• vraie popup : fenêtre du navigateur, qui apparait normalement hors du système d'onglets, par-dessus la fenêtre actuelle.
• fausse popup : bout d'HTML inséré dans une page pour dessiner un titre et un contenu et des boutons.

Techniquement il est nécessaire de passer par une fenêtre spécifique, on ne peut pas pourra pas pourrait pas assurer le fonctionnement des formulaires dans une fausse popup.

(là où la configuration du navigateur intervient c'est que je peux imaginer des extensions type "absolument tout ouvrir dans des onglets" qui viendraient perturber les choses)

Question pratique: comment on fait pour accéder à cette fonctionnalité ? il faut configurer quelque chose ? c'est uniquement possible en saisie-back-office ? c'est uniquement sur la saisie de fiche ?

"Pour faciliter la conception d'applications métier, nous avons modifié en backoffice le comportement des champs de type liste qui sont alimentés par des fiches. Lorsque ces champs sont configurés pour être utilisés en autocomplétion, il y a maintenant un bouton '+' à côté de la liste qui permet d'ajouter une nouvelle fiche sans avoir à quitter le formulaire ou la fiche en cours de saisie. La nouvelle fiche enregistrée viendra remplir automatiquement le champ de la fiche ou du formulaire que l'on est en train de compléter."

Et précision supplémentaire il faut avoir les droits (rôle) nécessaire pour la fiche concernée.

Pierre Cros a écrit :

"Pour faciliter la conception d'applications métier, nous avons modifié en backoffice le comportement des champs de type liste qui sont alimentés par des fiches. Lorsque ces champs sont configurés pour être utilisés en autocomplétion, il y a maintenant un bouton '+' à côté de la liste qui permet d'ajouter une nouvelle fiche sans avoir à quitter le formulaire ou la fiche en cours de saisie. La nouvelle fiche enregistrée viendra remplir automatiquement le champ de la fiche ou du formulaire que l'on est en train de compléter."

oui, si je pose la question c'est que j'ai bien testé dans ces conditions (et que ça ne marche pas). Je n'ai pas vérifié les droits d'accès.