Journal Un générateur de formulaire qui vise à remplacer google forms

Posté par  . Licence CC By‑SA.
Étiquettes :
28
1
nov.
2014

TL,DR: on est en train de développer un remplaçant à google forms, dispo sur https://spiral-project.github.io/formbuilder/

Y'à de ça quelques années maintenant, lors des rencontres django-fr à Montpellier, on s'était mis en tête, avec quelques copains, de réfléchir à un remplaçant pour google forms.

Depuis quelques semaines, on travaille sur la dernière partie, l'interface utilisateur, qui permet de construire des formulaires, de les remplir et de faire des rapports. C'est en javascript, écrit avec du React.js et est conçu de telle manière qu'il est possible de rajouter différents "backends" pour choisir ou stocker les données.

En parlant de stockage, la première brique logicielle de ce projet un peu ambitieux, c'était la partie serveur, qui permet de définir des modèles de données et de faire de la validation sur les données qu'on envoie, et de la recherche également.

Ce serveur, c'est "daybed" (le nom venant du fait qu'on utilisait CouchDB uniquement comme stockage au démarrage), et permet de faire de la validation de données, notamment de données géographiques, ce qui peut ouvrir sur des cas d'utilisations sympa.

Je suis assez friand de retours sur ce qu'on à fait, ce que vous voudriez voir réalisé via ce projet et tout autre commentaires.

(et bien sur, de vos contributions si vous vous sentez motivés!)

  • # bugs

    Posté par  . Évalué à 9.

    En mode administration d'un formulaire, quand on rouvre un formulaire qui contenait des champs requis, les champs sont toujours requis (ils ont notamment une astérisque), mais quand on clique sur l'un de ces champs pour le configurer, la case "required?" n'est pas cochée.

    En mode administration, cliquer sur un champ pour faire apparaître sa configuration ne fait pas disparaître les autres boites de configuration déjà ouvertes (et qui du coup peuvent se recouvrir), ce n'est pas pratique de mon avis personnel.

    En mode administration, l'infobulle du lien "mode utilisateur" en bas de la page n'est pas lisible car elle apparaît sous le bas de l'écran, et défiler l'écran fait disparaître l'infobulle.

    Si l'on ne change pas le libellé de 2 champs (et qu'ils s'appellent donc tous les deux "Label"), l'affichage de rapport reste vide alors qu'aucune erreur n'a été rapportée et qu'il y a bien des données enregistrées.

    Si l'on spécifie explicitement 2 fois le même libellé pour 2 champs, aucune erreur n'est affichée, mais en mode utilisateur la soumission du formulaire retourne un code HTTP 400, sans aucun retour visuel.

    En mode utilisateur, on n'a aucun message d'erreur si un champ requis n'est pas rempli, c'est dommage.

  • # Joli mais pas très intuitif

    Posté par  (site web personnel) . Évalué à 7.

    C'est très joli et a plutôt l'air de faire son boulot, mais l'interface d'édition n'est pas intuitive: On a par défaut un Form et un Paragraphe, et il faut cliquer sur les boutons à gauche pour ajouter un élément. Pour les différencier il faut passer la souris dessus pour voir les limites.. Mais ça ne montre que l'actuel pas les autres. Ça serait sympa d'avoir un cadre autour de chaque élément.

    2e remarque: Il aurait été plus intuitif d'avoir un élément fictif vide à l'endroit où on ajoute des éléments, qui contiendrait la liste des éléments ajoutables, de manière a ce que lorsque je clique sur "Add Paragraph", l'élément fictif devienne un paragraphe. Comme ça on sait où son paragraphe est ajouté. En plus de ça cet élément fictif pourrait être mis à n'importe quel endroit, de sorte qu'on ne soit pas obligé de rajouter à la fin (mais au milieu aussi). En plus de ça, dans la version actuelle si le formulaire est trop long la barre de boutons de gauche ne suit pas le curseur, du coup il faut scroller à chaque fois.

    Joli boulot en tout cas !

  • # Modèle de données pour les formulaires

    Posté par  . Évalué à 3.

    Bonjour,

    Je m'étais, il n'y a pas si longtemps, intéressé au sujet de la création de formulaire via une interface web.

    Côté stockage de la définition des formulaires, je pensais m'orienter vers un format XForms.

    En particulier pour l'aspect norme standardisée ( => interopérabilité) mais également, pour le côté xml qui permettait selon moi de générer de manière relativement simple des interfaces adaptées (HTML, SVG, txt, etc.).

    Comment cela est-il traité dans daybed ? Est-ce un modèle custom ?
    J'ai parcouru en diagonale les quelques liens et je n'ai pas trouvé.

    En tout cas, félicitations pour le projet. Il me semble que le sujet n'est pas aussi évident qu'il peut en avoir l'air au premier abord.

    • [^] # Re: Modèle de données pour les formulaires

      Posté par  . Évalué à 2.

      Pour l'instant on utilise un modèle custom, avec un travail en cours pour supporter json schema https://github.com/spiral-project/daybed/pull/195

      Pour XForms on ne s'est pas encore posé la question mais ça pourrait avoir du sens effectivement. En tout cas pour l'instant on essaye de garder le périmètre fonctionnel simple donc c'est pas pour tout de suite :)

      • [^] # Re: Modèle de données pour les formulaires

        Posté par  . Évalué à 1.

        haaannn, c'est exactement la remarque que je m'étais fais l'autre soir,
        une compat. json schema se serait vraiment super !

        Par contre, en termes de stockage, cela risque d'influer pas mal ?
        Me disant que faire du json schema avec un sgbdr, ce n'est peut être pas très naturel.

        En tout cas super initiative.

  • # Mettre de la sémantique

    Posté par  (site web personnel) . Évalué à 8.

    Ce serait intéressant que vous discutiez avec Jean-Marc Vanel qui écrit Sémantic Forms, le but est d'éviter de réécrire n fois nom, prénom, adresse, etc.. En utilisant des entités sémantique existantes, on peut générer automatiquement des formulaires à partir de modèles génériques.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Mettre de la sémantique

      Posté par  . Évalué à 2.

      Hello,

      sais tu si avec ces technos,
      RDF(S), OWL, SPARQL , JSON-LD

      je peux éventuellement comparer deux schémas et être capable de dire si ils sont
      équivalent
      compatible
      non compatible

      et alors, dans les deux derniers cas, leurs distances ?

      • [^] # Re: Mettre de la sémantique

        Posté par  (site web personnel) . Évalué à 4.

        Oui, car ils sont réduisibles à des arbres, donc tu peux faire de la comparaison d'arbree. Il y a plein d'algos pour ça.

        Mais je saurais que trop te conseiller de poser la question à Jean-Marc, il est très sympa, ce sera sûrement intéressant

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Wording

    Posté par  . Évalué à 3. Dernière modification le 03 novembre 2014 à 02:41.

    Bravo et merci, j'en aurai sûrement l'utilité bientôt ! J'essaierai de faire un retour.

    Je pense qu'il faudrait plus parler d'alternative que de remplaçant, les utilisations n'étant quand même pas vraiment les mêmes (grossièrement perso/pro).

    • [^] # Re: Wording

      Posté par  (site web personnel) . Évalué à 1.

      Je pense que Google Forms est utilisé aussi dans un contexte pro malheureusement, d'où l'idée de proposer une alternative.

      • [^] # Re: Wording

        Posté par  . Évalué à 2.

        Oui comme tu dis une "alternative", et pas un "remplaçant", terme qui semble un peu pompeux au vu des nombreuses fonctions qui séparent encore les deux projets.

  • # Export

    Posté par  . Évalué à 1.

    Peut-on exporter une image du formulaire (PDF par exemple) avec les données séparées dans un fichier XML ?

  • # Types de champ

    Posté par  (site web personnel) . Évalué à 2.

    Ce serait intéressant d’ajouter les types d’input de HTML5 qui comportent number, date, email, tel, url, etc…
    Ça peut être très pratique.
    Éventuellement avoir un équivalent de validation des valeurs en JS pour les cas où le navigateur supporte pas ces types, mais je me rends pas compte de l’état de l’implémentation de ces types dans les navigateurs actuels. Et ce ne sont que des validations coté navigateur donc faciles à tromper il faut de toutes façons revalider les valeurs renvoyées coté serveur pour être tranquille.

    http://www.w3schools.com/tags/att_input_type.asp

    • [^] # Re: Types de champ

      Posté par  . Évalué à 2.

      Carrement !

      C'est effectivement ce qui est prévu (utilisation des champs HTML5 pour la validation + validation coté JS via Daybed.js). On en est pas encore là mais l'objectif est bel et bien défini.

  • # Interface

    Posté par  . Évalué à 3.

    on travaille sur la dernière partie, l'interface utilisateur

    Je voudrais pas vous décourager, mais AMHA c'est le gros du boulot et de ce que j'ai pu voir rapidement, il y a encore pas mal de choses qui vont être impactant pour votre backend et votre modèle de données.

    En effet, pour le moment il me semble que vos formulaires se résument grosso modo à une série de question-réponse avec pleins de types de valeurs possibles. Si c'est bien le cas il manque toute la partie dynamique d'un questionnaire. C'est dommage d'avoir a écrire des question de la forme "Si vous avez répondu oui à tel question, […]". Ça peut par exemple être fait avec des conditions d'affichage pour chaque question.

    Plus que des données géographiques ça me semble être une fonctionnalité assez cruciale.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Interface

      Posté par  . Évalué à 3.

      Effectivement, c'est quelque chose qui peut-être très utile, mais ça ne fait pas partie du périmètre fonctionnel de la première version du projet.

      Aussi, le modèle de données proposé par le backend est assez flexible pour ajouter des dépendances ou ce genre de choses, mais le frontend n'expose rien de tel pour l'instant. Comme on dit, on préfère faire des pas de bébé, y aller petit à petit pour avoir quelque chose qui réponds à un besoin specifique (avoir des formulaires simples, sans trop de règles de validation) dans un premier temps, auquel on ajoutera du sucre visuel et fonctionnel par la suite.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.