Oui tout à fait d’accord avec toi, la fiche permet de répondre à la plupart des cas. Les deux cas pour lesquels j’ai écrit sont en effet assez spécifiques :
-
mon cas : un grist de gestion de clés, où les utilisateurs (qui peuvent être des très jeunes, des personnes âgées etc) peuvent remplir un formulaire d’emprunt de clés. J’aurais trouvé ça chouette qu’ils aient à côté du formulaire la vue sur la liste des clés. Idéalement, j’aurais aimé un petit module tout simple où ils puissent faire leur choix, avec un gros bouton « valider ». Je trouve que dans ce cas la fiche n’est pas adaptée (pas d’intérêt de naviguer d’une ligne à l’autre, le bouton « plus » est tout petit, puis l’ux pas top pour l’accessibilité)
-
le cas de de @mathieugimenez : un grist où on enregistre l’historique des modifications sur une colonne - pour l’instant il n’y a pas de possibilité facile d’enregistrer les logs des évènements sur un document. Comme contournement on peut mettre en place un formulaire qui permet à l’utilisateur de soumettre plusieurs réponses, lui permettant ainsi de « modifier » son choix. On peut donc avoir plusieurs lignes pour chaque utilisateur avec un « NOW() » pour récupérer la date de soumission. Puis on fait une table groupée pour avoir la liste d’utilisateurs uniques et définir la dernière réponse de chaque utilisateur (le résultat « modifié »). Un exemple ici : Ex - Historique des modifications - Grist
Et le besoin c’était que les utilisateurs, en même temps qu’ils modifient leur réponse, aient une vue sur l’impact de ces modifications sur la table (donc d’avoir le form à l’intérieur du grist).
Ce cas-là ne serait pas gérable avec une fiche qui leur permettrait de modifier directement leurs données dans la table.