« Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données

Posté par . Édité par palm123, Benoît Sibaud et Xavier Claude. Modéré par Xavier Claude. Licence CC by-sa
37
1
juin
2016
Bureautique

Fourmilieres, un outil qui vise à permettre la création de formulaires (à la Google Forms) vient de sortir en version 1.0. Il est placé sous licence Apache v2.

L'outil a été créé après quelques recherches et le constat qu'aucune des alternatives existantes n'était réellement satisfaisante.

Fourmilieres se veut être une interface la plus simple possible pour générer des formulaires, y répondre et visualiser les réponses. La philosophie générale étant de limiter les complexité exposée à l'utilisateur au maximum.

Stockage des données

Le système est basé sur Kinto (licence Apache v2 aussi), une base de données prévue pour être interrogée depuis des navigateurs Web. L'API exposée est en HTTP, ce qui permet une interface avec d'autres systèmes de manière assez simple.

Il est par exemple possible d'interroger la base de données pour avoir l'ensemble des réponses en ligne de commande.

L'interface utilisateur est décorrélée du stockage des données : à terme il sera possible de spécifier sur quel serveur les données doivent être envoyées lors de la création du formulaire.

Format de description du formulaire

Une fois les différents champs ajoutés et configurés, une description du formulaire est générée. Un des points notables est le choix de JSON Schema comme format de représentation des données. D'un point de vue technique, l'outil devient un moyen de générer du JSON Schema, que vous pouvez ensuite utiliser dans d'autres outils.

Futur du projet

Le projet en est encore à ses balbutiements, mais plusieurs évolutions sont prévues, notamment en terme d'expérience utilisateur (UX).

Dans les évolutions à venir qui semblent intéressantes:

  • l'ajout de champs de type géographique : possibilité de placer un point sur une carte, ou de tracer des formers sur un fond de carte ;
  • la possibilité de sélectionner l'emplacement du serveur de données lors de la création du formulaire : un même outil pourra alors servir à générer des données vers des serveurs différents ;
  • une revisite de l'interface utilisateur afin d'être plus simple à appréhender par les utilisateurs.
  • # Kinto

    Posté par (page perso) . Évalué à 7.

    Sympa de voir un projet basé sur Kinto, qui est développé par Mozilla (et bien d'autres maintenant). J'ai découvert personnellement le projet avec l'entretien de Tarek Ziadé de chez Mozilla et j'ai été intéressé de voir qu'il était maintenant utilisé par Firefox.

    • [^] # Re: Kinto

      Posté par . Évalué à -4.

      Oh putain, Tarek, sous ta moustache, tu n'as pas changé!

  • # Framaforms ?

    Posté par . Évalué à 9.

    Je félicite l'équipe pour le projet.

    Pour gagner en visibilité, ne serait-ce pas intéressant de se rapprocher de l'initiative de "dégoogleliser" internet initié par Framasoft (ça semble bien dans le thème ;-D) ?

    Mes deux cents,

    • [^] # Re: Framaforms ?

      Posté par . Évalué à 3.

      J'aurais dû vérifier avant de poster mais Framaforms existe déjà (mais en version alpha).

      • [^] # Re: Framaforms ?

        Posté par . Évalué à 4.

        Très bonne idée: des discussions sont en cours (on ne connaît pas encore l'issue de celles ci par contre)

    • [^] # Re: Framaforms ?

      Posté par (page perso) . Évalué à 0.

      Oh oui, syouplé, vite-vite des Framaforms ! Je vais donner plein de sous à Frama* pour aider à le faire, et quand ça sera fait, j'aurai enfin les arguments pour obtenir que mon association professionnelle contribue aussi.

      Cette semaine encore, j'ai été contraint et forcé de demander à des centaines de collègues d'aller remplir un formulaire de l'Ooggle, quelle humiliation, grrr !

      Intendant, donc méchant, mais libre !

  • # La présentation oublie des infos essentielles

    Posté par . Évalué à 10.

    Si je veux installer un logiciel sur un serveur, j'ai besoin de savoir quelles sont ses dépendances, et donc quelles technologies il utilise. Entre PHP/Symfony et Haskell/Yesod, il y a un gouffre. Et puis je préfère installer des trucs donc je comprends le code.

    Ici, c'est du NodeJS. Pas de serveur web nécessaire. Et si JavaScript est désactivé dans le navigateur, on a une page intégralement blanche. Dans mon navigateur par défaut, certes vieux et plus maintenu mais malheureusement sans équivalent moderne, j'ai une erreur JavaScript fatale quand je veux créer un formulaire.

    J'ai du mal à comprendre l'engouement pour ces développements "tout JS" par rapport au bon vieux principe client-serveur page par page du web, éventuellement mâtiné d'un peu d'asynchrone (AJAX-AJAJ). D'accord c'est amusant d'essayer de nouvelles techniques, mais qu'est-ce que c'est fragile, même au niveau de l'écosystème NodeJS.

    • [^] # Re: La présentation oublie des infos essentielles

      Posté par . Évalué à 10.

      Bonjour,

      Deux points donc à discuter: le fait de définir les dépendances clairement (1) et le fait d'avoir des applications clientes en JavaScript pur dans le navigateur (2).

      1. Effectivement j'aurais du l'indiquer dans la dépèche :-) Ceci dit, au niveau du serveur tu n'a pas besoin d'installer du node.js, tu peux simplement servir des fichiers statiques, ce qui permet de l'installer très facilement un peu partout. Node.js est utilisé pour développer et tu en aura besoin si tu souhaite contribuer au projet par contre.

      2. J'ai personnellement foi (peut être à tort) dans un avenir ou les applications sont écrites pour des navigateurs qui exécutent du JavaScript.

      La raison principale que j'y vois est les interfaces résultantes qui ont tendance à être plus faciles à appréhender par les utilisateurs (plus facile de faire de l'interaction avec les utilisateurs sur certains aspects).

      Je vois bien sur des faiblesses associées à ce modèle, notamment pour les personnes qui ont noscript installées (ce qui est le cas par default dans TorBrowser par exemple). D'ailleurs, si on souhaite aller plus loin dans cette discussion, ce qui me dérange est principalement le fait que les applications Web ne sont pas signées et validées par quiconque avant de s'afficher aux utilisateurs, ce qui pose des soucis de sécurité dans un cas d'attaque MITM ou d'un serveur compromis.

      J'avais d'ailleurs écrit quelque chose à ce sujet il y a quelques temps: https://blog.notmyidea.org/web-distribution-signing.html

      Ce problème n'est malheureusement pas résolu sur le Web et se passer de JavaScript est un pansement: il faut s'attaquer au souci plutôt. En attendant, je préfère faire avec :)

      • [^] # Re: La présentation oublie des infos essentielles

        Posté par . Évalué à 2.

        Ceci dit, au niveau du serveur tu n'a pas besoin d'installer du node.js, tu peux simplement servir des fichiers statiques, ce qui permet de l'installer très facilement un peu partout.

        Il faut quand même installer un serveur Kinto, non ? Surtout que si j’ai bien compris, aujourd’hui il est forcément sur le même serveur.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: La présentation oublie des infos essentielles

          Posté par . Évalué à 1.

          Non ce n'est pas nécessaire. D'ailleurs actuellement ce n'est pas le cas (le serveur kinto utilisé est hébergé ailleurs que les fichiers statiques). Cela est possible grâce à l'utilisation de CORS.

          • [^] # Re: La présentation oublie des infos essentielles

            Posté par . Évalué à 2.

            Non ce n'est pas nécessaire. D'ailleurs actuellement ce n'est pas le cas (le serveur kinto utilisé est hébergé ailleurs que les fichiers statiques). Cela est possible grâce à l'utilisation de CORS.

            Tu veux dire qu’il est sur un serveur public Kinto ? Lequel ? Qu’est-ce qui assure la confidentialité de mes données ?

            C’est idiot, mais si je suis suffisamment intéressé au fait que mes données ne soient pas chez google pour ne pas utiliser forms, je veux savoir où elles sont, et comment elles sont sécurisée.

            Note que je comprends que ce sont des détails, surtout que c’est une version 0.1, et que c’est prévu dans la roadmap. Mais disons qu’un peu plus de détails au niveau de la comm ne ferait pas de mal ;).

            Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

      • [^] # Re: La présentation oublie des infos essentielles

        Posté par . Évalué à 6.

        Nos expériences divergent sur le tout JavaScript et les interfaces résultantes qui ont tendance à être plus faciles à appréhender par les utilisateurs. Il y a deux semaines, une amie, qui travaillait avec moi sur un Framapad, a réalisé que ses deux heures de travail de la veille n'avaient pas été enregistrées. Je vous laisse imaginer la crise. Depuis, on est passé sur du wiki, parce que là le serveur nous dit si nos modifications ont été enregistrées.

        Plus généralement, JS est trop souvent un truc qui ne sert qu'à ajouter des gadgets clinquants en ralentissant la page. Des sites statiques par nature, comme ceux du NYTimes ou du Monde, sont bien plus réactifs quand on les débarrasse de ça. Et certaines pages toutes bêtes mettent 10 secondes à se charger alors qu'une page HTML+CSS serait instantanée. Alors d'accord, sans JS je perds les carrousels et le défilement des pages est géré nativement par mon navigateur web, mais j'y vois plutôt un avantage.

        Quand je remplis un formulaire et que je touche "backspace" sans focus, je peux revenir à ma page, le navigateur a conservé ce que j'ai déjà saisi… sauf si la page est dynamique en JS.

        Bref, mon problème n'est pas la sécurité, c'est que JavaScript implique souvent lourdeur et fragilité, et que c'est une tendance de fond du web. Et je rappelle que "Fourmilieres" a planté chez moi, même en activant le JavaScript.

        • [^] # Re: La présentation oublie des infos essentielles

          Posté par . Évalué à 4. Dernière modification le 02/06/16 à 18:45.

          Bonjour, je développe des applications web et pour moi il est incontestable que l'utilisation de JavaScript apporte beaucoup de souplesse dans la manière de coder.

          Avant pour générer des pages HTML je faisais des templates auxquels je passais des variables et la logique d'affichage était gérée par le langage de template avec des if et des boucles. Ce qui me gênait c'est que du coup le code HTML n’était pas net. Maintenant, je fais des pages HTML pures et dures et j'inclus un script js qui va se charger d'aller chercher les variables et de les placer sur la page et je trouve que c'est plus propre et plus souple comme ça.

          • [^] # Re: La présentation oublie des infos essentielles

            Posté par . Évalué à 2.

            Avant pour générer des pages HTML je faisais des templates auxquels je passais des variables et la logique d'affichage était gérée par le langage de template avec des if et des boucles. Ce qui me gênait c'est que du coup le code HTML n’était pas net. Maintenant, je fais des pages HTML pures et dures et j'inclus un script js qui va se charger d'aller chercher les variables et de les placer sur la page et je trouve que c'est plus propre et plus souple comme ça.

            Ça ça dépend du langage que tu utilises pour faire tes templates. Tu pourrais très bien manipuler des pages HTML façon DOM sur le serveur, en n'importe quel langage. Si tu veux des templates qui respectent le HTML façon XML, pour être toujours dans du HTML correct (« net », comme tu dis), tu pourrais utiliser le langage de template de Zope : ça a 15 ans (et c'est « mort » aujourd'hui).

            Voire pire (ou mieux, c'est selon), utiliser un langage de transformation comme XSLT : c'est exécutable aussi bien côté serveur que client, et c'est même sûrement déjà implémenté dans ton client web sans que tu le saches ! Et pourtant, ça n'a pas vraiment « pris ». Ou plutôt, on voit le NIH à l'œuvre, comme toujours.

            • [^] # Re: La présentation oublie des infos essentielles

              Posté par . Évalué à 1.

              J'ai utilisé Zope pour la première fois en 2001, en 2008 j'étais le développeur pour trois applis Zope2 en production. J'ai creusé le TAL/Metal. Puis on a essayé de migrer vers Zope3 sans succès. C'est un des pires frameworks que j'ai connu (les configurations en zcml à s'arracher les cheveux tant les messages d'erreurs étaient abscons). Il nous reste des reliques dans notre architecture, du ZCA qui fait chier parce que ça pète le contrôle de syntaxe de l'IDE.

              Zope est un bon exemple d'over-engineering comme ta proposition d'utiliser du XSLT, c'est déjà assez difficile de maitriser correctement le couple HTML/CSS et la il faudrait en rajouter une couche avec les difficultés à debugger que cela va engendrer alors qu'il existe des debuggeur correctes pour javascript inclus dans les navigateurs récents.

              • [^] # Re: La présentation oublie des infos essentielles

                Posté par . Évalué à 3.

                Je suis d'accord avec le fait que Zope est un exemple d'over-engineering complet : je m'y suis cassé les dents également. Mais je parlais juste du langage de template (TAL, j'avais oublié le nom) : le principe me semblait quand-même bien, d'avoir un document XML conforme, annoté correctement. C'est dommage que ça n'ait pas été repris dans un autre framework.

                Par contre, pour XSLT, je ne comprends pas ta critique : oui, HTML/CSS est déjà assez balaise à maîtriser, mais toi tu proposes de rajouter Javascript sans le préciser ! Ça n'est pas « pire » que XSLT, au contraire : le XSLT est beaucoup moins complexe, même si du fait de sa relative non-popularité, on va trouver plus de monde qui connaît le JS, c'est clair. Et « débugger » des templates, je ne vois pas trop où est la complexité, quel que soit le langage.

                • [^] # Re: La présentation oublie des infos essentielles

                  Posté par . Évalué à 1.

                  Pour revenir au contexte qui est que la dépendance du bon fonctionnement d'un formulaire est liée à l'utilisation de JavaScript, pour moi c'est une évidence. Je ne parle pas des formulaires ultras basiques. Imaginons un cas avec deux listes select ou les choix dans la seconde liste dépendent du choix fait dans la première. Sans JavaScript on va être obligé de rajouter un bouton submit si on rajoute un onchange="this.form.submit()" , c'est déjà du js en soi.

                  Pour ce qui est du XLST ma logique est la suivante:
                  Si je fais un site, il y a de fortes chances qu'il y ait des formulaires dedans.
                  Si je fais des formulaires un minimum évolué, j'aurai besoin de JavaScript.
                  Donc j'aurai besoin de JavaScript.
                  À partir du moment ou c'est déjà une dépendance, autant faire un maximum de choses avec et éviter les dépendances à d'autres technos.

                  La surutilisation de JavaScript, oui c'est énervant quand c'est utilisé pour afficher des trucs qui bougent dans tous les sens ainsi que pour les trackers, les pubs, etc.

                  Utilisé à bon escient, pour faciliter l'interaction avec l'utilisateur ça apporte un plus pour l'ergonomie du site. Faire des sites qui fonctionnent à la fois avec et sans JavaScript c'est beaucoup de boulot.

                  • [^] # Commentaire supprimé

                    Posté par . Évalué à -10.

                    Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: La présentation oublie des infos essentielles

                    Posté par . Évalué à 1.

                    Imaginons un cas avec deux listes select ou les choix dans la seconde liste dépendent du choix fait dans la première. Sans JavaScript on va être obligé de rajouter un bouton submit si on rajoute un onchange="this.form.submit()" , c'est déjà du js en soi.

                    Mauvais exemple : oui, il y aura toujours des choix dépendants, mais tu auras également toujours à faire une validation côté serveur. Donc autant laisser un formulaire sans JS avec toutes les possibilités et une indication que c'est à l'utilisateur d'être cohérent ; ça ne me choque pas quand il n'y a pas de JS que ça soit à moi de faire une partie du boulot. Après, oui, pour faire « bien », tu mettras du JS pour tes choix dépendants. Même si en général, j'ai de mauvaises expériences avec pas mals de formulaires de ce genre qui te « bloquent » quand tu veux modifier certains paramètres mais que ça n'est pas dans l'ordre que le concepteur avait imaginé… Il me semble que dans les bonnes pratiques des UI, la validation intermédiaire (qui a lieu lors des étapes d'un choix dépendant) n'est pas considérée comme idéale.

                    À partir du moment ou c'est déjà une dépendance, autant faire un maximum de choses avec et éviter les dépendances à d'autres technos.

                    Pas d'accord avec ce raisonnement : ça n'est pas parce que tu peux faire du JS qu'il faut en mettre partout où c'est possible. Une des bonnes philosophies du développement Web, c'est de se dégrader correctement ! C'est tellement évident pour moi, mais pas pour les devs récents, on dirait. Oui, c'est plus de boulot, mais c'est comme ça que le Web marche bien.

                    Utilisé à bon escient, pour faciliter l'interaction avec l'utilisateur ça apporte un plus pour l'ergonomie du site. Faire des sites qui fonctionnent à la fois avec et sans JavaScript c'est beaucoup de boulot.

                    Je pense que c'est beaucoup de boulot pour certains framework JS qui sont développés en s'amusant à tout réinventer. Ou ceux qui veulent combler les fonctionnalités de tous les vieux browsers en les réinventant à la sauce JS : du coup, ça casse toute « l'intelligence » que pourrait avoir le browser pour avoir une cohabitation JS/HTML-sans-JS harmonieuse. Franchement, quand je vois le nombre de sites dont les liens ne fonctionnent pas du tout sans JS (voire sans cookies !!) parce qu'ils n'ont pas de href correct dans leurs balises a (voire qu'ils n'utilisent simplement pas de a), c'est à pleurer ; et ne me dit pas que c'est plus de boulot de faire ça correctement… Faut naviguer un peu sans JS pour aller voir les dommages qu'a fait cette idéologie au Web.

                    • [^] # Re: La présentation oublie des infos essentielles

                      Posté par . Évalué à 2. Dernière modification le 06/06/16 à 08:04.

                      On ne parle pas de la même chose. Toi tu parles de l'accessibilité du web en général et de ta liberté de naviguer sans JS. Moi je suis plus dans un contexte d'applications web payantes avec un nombre d'utilisateurs limité. J'ai donc dans ce contexte des remontées directes de ce que demandent les clients et jamais un client n'a demandé à avoir un site sans JS.
                      Les demandes c'est plutôt plus de fonctionnalités: pouvoir filtrer ou rechercher dynamiquement dans un tableau de données, zoomer sur les graphiques, uploader/downloader plusieurs fichiers à la fois.

                      Après la question est aussi qu’elle est la limite acceptable en fonction des standards en cours et des temps de développement, c'est une lutte entre les besoins, les choix et les ressources.

                      tu veux en site sans JS => bon OK
                      sans cookie => on va mettre des tokens
                      en CSS 1.0 uniquement => #soupirs
                      en mode dégradé pour les modems 2400 bauds => gniiiiii
                      (je ne parle même pas des variations de tailles d'écrans et de dpi)

                      • [^] # Re: La présentation oublie des infos essentielles

                        Posté par . Évalué à 3.

                        Toi tu parles de l'accessibilité du web en général et de ta liberté de naviguer sans JS.

                        Oui c'est ça.

                        Moi je suis plus dans un contexte d'applications web payantes avec un nombre d'utilisateurs limité. J'ai donc dans ce contexte des remontées directes de ce que demandent les clients et jamais un client n'a demandé à avoir un site sans JS.

                        Forcément, il n'a aucune idée des principes du Web qui est de se dégrader correctement. C'est à toi d'adapter ses demandes à ces préceptes.

                        Les demandes c'est plutôt plus de fonctionnalités: pouvoir filtrer ou rechercher dynamiquement dans un tableau de données, zoomer sur les graphiques, uploader/downloader plusieurs fichiers à la fois.

                        Même si on pourrait argumenter sur plein de choses à propos des applications lourdes vs. le Web, je ne vois pas en quoi ces demandes vont contre ce que j'ai dit.

                        Après la question est aussi qu’elle est la limite acceptable en fonction des standards en cours et des temps de développement, c'est une lutte entre les besoins, les choix et les ressources.

                        Ça c'est effectivement la vraie question. Ce qu'il faut penser, et ce qu'on ne prend pas assez en compte, je trouve, c'est que l'accessibilité est une « externalité » qui n'est souvent pas prise en compte dans le choix : ça ne « coûte » rien aujourd'hui de faire un site 100% JS pourri. Ça ne va faire chier que trois clampins, qui sont en plus sûrement un peu handicapés (je me considère un peu comme ça, en fait, même si je n'ai pas de handicap physique), donc on s'en fout.

                        tu veux en site sans JS => bon OK
                        sans cookie => on va mettre des tokens
                        en CSS 1.0 uniquement => #soupirs
                        en mode dégradé pour les modems 2400 bauds => gniiiiii

                        Je suis prêt à discuter d'un juste milieu. Comme je disais plus haut, je suis prêt à accepter de devoir utiliser un browser gérant des normes un peu modernes, pour éviter trop de galères aux développeurs. Mais à la limite, tant que tu gardes un HTML correct, même la CSS je m'en fout que tu utilises des trucs très modernes pas trop supportés : ça ne m'empêchera pas de lire, même si c'est moche. Et ce HTML là, il n'a presque pas changé en 20 ans.

                        Et pour ta blague sur le modem 2400 bauds, c'est ironique comme c'est justement tu ne devrais pas t'en faire : si ta base HTML est bonne, les « chieurs » qui veulent l'accessibilité s'en contenteront et auront magiquement un contenu léger car ils auront laissé de côté ton JS éléphantesque.

                        (je ne parle même pas des variations de tailles d'écrans et de dpi)

                        Très bon exemple : c'est super vendeur de faire de la différenciation (pour iPhone, par exemple), alors que c'est à l'antipode de ce pour quoi a été fait le Web, et du coup les devs se cassent le cul d'une force pas possible pour nous chier des merdes de JS pour gérer ça. Mais laissez faire les browsers en HTML, merde !

                        • [^] # Re: La présentation oublie des infos essentielles

                          Posté par . Évalué à 1.

                          Quand tu dis, il faut que ça marche sans JS, il faut comprendre notre frustration en tant que développeur web.
                          On a attendu des années avec des navigateurs qui ne respectaient pas les standards à jongler avec les cas particuliers.
                          Les moteurs JS étaient lents et pour palier à ça il y avait des rustines propriétaires (activeX, plugin netscape, vm-java)

                          Aujourd'hui on a une norme de base cohérente HTML5/CSS3/EcmaScript5 et les navigateurs l'implémentent assez bien.
                          Cela fait quinze ans qu'on attendait ça, mais non on doit continuer à développer comme en 99.

                          Taquinons le goujon: WebSocket ?

                          • [^] # Re: La présentation oublie des infos essentielles

                            Posté par . Évalué à 2.

                            On a attendu des années avec des navigateurs qui ne respectaient pas les standards à jongler avec les cas particuliers.

                            Comme je disais, ça reste pour la présentation et pour les interactions riches ; pour « la base », ça a vraiment peu changé ! Et bien sûr que je ne demande pas à GMail de marcher sans JS…

                            Aujourd'hui on a une norme de base cohérente HTML5/CSS3/EcmaScript5 et les navigateurs l'implémentent assez bien.
                            Cela fait quinze ans qu'on attendait ça, mais non on doit continuer à développer comme en 99.

                            Non, pas comme en 99. Mais qu'un formulaire — fonction normalisée dans les premiers standards du Web ! — puisse marcher sans JS, ça me semble normal et même essentiel, même si bien sûr sans JS on manquera un paquet de « jolis » trucs.

                            Taquinons le goujon: WebSocket ?

                            Franchement, je connais peu et je ne vois pas ce qui se fait avec. Étant quelqu'un du réseau, voir réimplémenter un système de paquets au-dessus d'un réseau orienté contenu (à cause des firewalls de nazis) situé au-dessus d'un réseau vaguement circuit-paquet (à cause du NAT), ça me désole un peu.

                    • [^] # Re: La présentation oublie des infos essentielles

                      Posté par . Évalué à 2.

                      Tu poses les mauvais problèmes.

                      Javascript est devenu un prérequis en 2016 (un peu avant ça, mais bon). Un navigateur n’est pas un bête moteur de rendu html, mais plutôt une machine virtuelle pour applications js. Si ça ne te plaît pas, soit, mais dans ce cas, tu te coupes de beaucoup de sites. Sachant que l’argument de la sécurité n’en est plus vraiment un : les navigateurs ont énormément progressé de ce point de vue. Je regrette cela dit qu’il n’y ait toujours pas de norme pour la signature de code.

                      Et il y a plein d’arguments à ce que javascript soit un prérequis :
                      - le dev coûte moins cher (joue un peu avec un framework comme angularjs, c’est impressionnant ce qu’on arrive à faire rapidement)
                      - la charge serveur / la bp est réduite (oui, recharger une page html et faire tous les calculs – je ne parle pas de la validation de données, qui est indispensable, mais de calculs liés à la présentation – côté serveur, ça coûte, alors qu’on peut en faire plein côté client). C’est particulièrement critique quand tu embraques un serveur http dans un périphérique embarqué disposant d’une petite cpu.
                      - la séparation métier / présentation est généralement de fait améliorée (car usage de technos différentes pour les deux, moins de risques de mélanger les choses)

                      Les problèmes, quand c’est mal mis en œuvre, c’est très souvent que la navigation est cassée :
                      - aucun moyen d’accéder à une page en particulier / ajouter un favori
                      - back / next ne fonctionnent pas
                      - pas possible d’ouvrir un lien dans une nouvelle fenêtre

                      Mais ça c’est un problème de dev qui n’a pas fait son boulot correctement, pas un problème de techno (sachant que les framework js apportent des solutions simples à mettre en œuvre).

                      Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                      • [^] # Re: La présentation oublie des infos essentielles

                        Posté par . Évalué à 3.

                        Javascript est devenu un prérequis en 2016 (un peu avant ça, mais bon). Un navigateur n’est pas un bête moteur de rendu html, mais plutôt une machine virtuelle pour applications js.

                        C'est toi qui le dit. Parce que ça arrange ceux qui veulent contrôler l'interface utilisateur plutôt que ça soit l'utilisateur qui puisse dicter ses besoins. Ça colle bien au fait que ça rende les choses moins accessibles : c'est l'idéologie même de ce mouvement de casser le pouvoir de l'utilisateur.

                        Si ça ne te plaît pas, soit, mais dans ce cas, tu te coupes de beaucoup de sites.

                        Et, qu'en conclues-tu ? Ne trouves-tu pas ça dommage que des gens se coupent de sites à cause de leur conception qui va à l'encontre des principes de base du Web, comme bien dégrader ? Je suis sûr que même Berners-Lee n'accroche pas vraiment à cette tendance.

                        Sachant que l’argument de la sécurité n’en est plus vraiment un : les navigateurs ont énormément progressé de ce point de vue. Je regrette cela dit qu’il n’y ait toujours pas de norme pour la signature de code.

                        J'avoue que je ne comprends pas trop les arguments de sécurité, mais bon.

                        • le dev coûte moins cher (joue un peu avec un framework comme angularjs, c’est impressionnant ce qu’on arrive à faire rapidement)

                        Moins cher que quoi ? Que bien faire les choses ? Ah oui, ça, forcément, c'est comme ça partout, bâcler le travail et faire de la merde et s'en foutant des conséquences que ça a pour les autres, ça a toujours été (et ça l'est toujours) une technique en vogue et qui ne coûte pas cher. C'est censé être un argument pour toi ?

                        • la charge serveur / la bp est réduite (oui, recharger une page html et faire tous les calculs – je ne parle pas de la validation de données, qui est indispensable, mais de calculs liés à la présentation – côté serveur, ça coûte, alors qu’on peut en faire plein côté client). C’est particulièrement critique quand tu embraques un serveur http dans un périphérique embarqué disposant d’une petite cpu.

                        Ça, d'accord. Mais on a déjà essayé de normaliser des solutions pour le templating côté client : c'est XSLT. Mais tout le monde l'a oublié. Pour le reste, très bien, ne fait pas de mise en forme côté serveur, ça me va très bien : je m'en fous que ça soit moche, bien sûr que je fais des compromis quand je n'ai pas de JS.

                        • la séparation métier / présentation est généralement de fait améliorée (car usage de technos différentes pour les deux, moins de risques de mélanger les choses)

                        Houa, alors ça pas du tout par contre : aujourd'hui, côté client, on mélange aussi les choses comme on le faisait avant côté serveur. Les applications bien délimitée, ça n'est pas juste en disant que « je fais du JS » que ça va arriver magiquement. C'est comme tout, ça demandera un bon dev.

                        Mais ça c’est un problème de dev qui n’a pas fait son boulot correctement, pas un problème de techno (sachant que les framework js apportent des solutions simples à mettre en œuvre).

                        On est donc d'accord : ça n'est pas parce que c'est du JS que c'est magiquement « mieux ». Alors pourquoi, si on ne fait pas mieux, casser tout l'existant, l'accessibilité, voire les fonctions de base ?! Une des raisons pour lesquelles l'HTML est « rigide » niveau interaction (et la raison pour laquelle tant de gens sont tentés de mettre plein de JS), c'est aussi parce que ça évite de faire n'importe quoi à ceux qui n'y connaissent rien et font du dev à deux francs.

                        • [^] # Re: La présentation oublie des infos essentielles

                          Posté par . Évalué à 3.

                          Ça, d'accord. Mais on a déjà essayé de normaliser des solutions pour le templating côté client : c'est XSLT. Mais tout le monde l'a oublié.

                          Je vais poser une question bête, mais parles-tu d’expérience, as-tu essayé de mettre en place XSLT sur du web / sur quelque chose de conséquent ? Personnellement, j’ai travaillé sur des feuilles XSLT > 20k lignes de code, et plus jamais ça. De plus, c’est à des années lumière de JS en terme de fonctionnalités (rien que des opérations mathématiques non triviales, des substitutions de chaîne, un tri, sont une horreur).

                          De mon point de vue, ce n’est pas pour rien que tout le monde a oublié xslt : cette techno est une mauvaise idée.

                          Moins cher que quoi ? Que bien faire les choses ? Ah oui, ça, forcément, c'est comme ça partout, bâcler le travail et faire de la merde et s'en foutant des conséquences que ça a pour les autres, ça a toujours été (et ça l'est toujours) une technique en vogue et qui ne coûte pas cher. C'est censé être un argument pour toi ?

                          Moins cher de faire quelque chose de correct avec un framework type angularJs que si je dois faire la même chose avec une techno côté serveur. Cela dit, c’est peut-être exagéré de dire ça, peut-être que je peux avoir le même ordre de grandeur avec une techno de template côté serveur type django (mon expérience avec django, certes faible, me fait toutefois préférer le système angularjs).

                          Pour le reste, très bien, ne fait pas de mise en forme côté serveur, ça me va très bien : je m'en fous que ça soit moche, bien sûr que je fais des compromis quand je n'ai pas de JS.

                          Ça ne sera pas moche, ça sera inexploitable. Ajax sans javascript, ça ne peut pas marcher. Après, tu peux requêter toi-même les pages et récupérer le json (oui, on n’utilise plus xml même si le terme ajax est resté). Mais c’est un compromis que personne n’est prêt à accepter.

                          On est donc d'accord : ça n'est pas parce que c'est du JS que c'est magiquement « mieux ». Alors pourquoi, si on ne fait pas mieux, casser tout l'existant, l'accessibilité, voire les fonctions de base ?!

                          Tu postules qu’on ne fait pas mieux, et tu vas me sortir plein d’exemples où tu as raison. Mais il y en a aussi pléthore qui te donneront tort (on fait beaucoup mieux avec JS que sans). Et qu’à un moment, le mode « dégradé » n’est plus possible, car c’est tellement loin du mode pas dégradé que ça ne peut plus fonctionner. Ça en arrive à demander un développement spécifique, et comme ça coûte celui-ci n’est pas fait, sauf si la demande le justifie vraiment.

                          En attendant, ce qui est important, c’est surtout de ne pas casser les fonctionnalités utilisateur, comme :
                          - précédent / suivant
                          - les marques-pages
                          - les choix de navigation (nouvel onglet / nouvelle fenêtre)
                          - j’en oublie sûrement

                          Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                          • [^] # Re: La présentation oublie des infos essentielles

                            Posté par . Évalué à 3.

                            De mon point de vue, ce n’est pas pour rien que tout le monde a oublié xslt : cette techno est une mauvaise idée.

                            Oui, les critiques que tu cites sont bonnes. Mais c'est pour dire qu'on avait déjà pensé à quelque-chose qui permettait de soulager le serveur, et que c'était fait en s'intégrant plutôt « bien » au workflow XML. Mais c'est clair que sa syntaxe verbeuse et ses fonctionnalités de calcul et de manipulation de chaîne sont de très gros défauts. Cependant, je n'ai jamais retrouvé nulle-part le même facilité de manipulation d'arbre et de matching (avec choix du sélecteur le plus strict, vraiment quelque-chose de génial !) qu'il apporte.

                            Cela dit, c’est peut-être exagéré de dire ça, peut-être que je peux avoir le même ordre de grandeur avec une techno de template côté serveur type django (mon expérience avec django, certes faible, me fait toutefois préférer le système angularjs).

                            J'ai peu d'expérience avec les framework JS, mais je ne vois pas pourquoi ça ne se vaudrait pas. Un moteur de template c'est un peu toujours la même chose quel que soit le langage…

                            Ça ne sera pas moche, ça sera inexploitable. Ajax sans javascript, ça ne peut pas marcher. Après, tu peux requêter toi-même les pages et récupérer le json (oui, on n’utilise plus xml même si le terme ajax est resté). Mais c’est un compromis que personne n’est prêt à accepter.

                            Ça dépend pour quoi. Franchement, quand c'est juste pour afficher une ressource sur une page simple que tu as besoin d'Ajax (pour du templating, typiquement), il faut tout simplement supprimer cette requête inutile ! Et pas besoin de faire le calcul N fois côté serveur : tu caches le résultat, point barre, comme ça l'effort est économisé des deux côtés.

                            Par contre, si c'est pour une fonctionnalité « avancée », pourquoi pas, mais j'avoue rarement avoir de bonne justification pour ça. Plein de fois où je dois activer le JS, j'imagine tout de suite une manière de faire en statique pour le client, sans surcharge pour le serveur. Comme je dis à groumf plus haut, bien sûr que je ne demande pas à GMail de marcher sans JS, mais je parle de toutes les « applications » entre deux.

                            Mais il y en a aussi pléthore qui te donneront tort (on fait beaucoup mieux avec JS que sans). Et qu’à un moment, le mode « dégradé » n’est plus possible, car c’est tellement loin du mode pas dégradé que ça ne peut plus fonctionner.

                            Bah j'aimerais bien avoir des exemples, car mon coup de gueule est pour des exemples plutôt simples à chaque fois. Tiens par exemple, un contre-exemple, c'est l'Agenda du Libre : je viens de remplir un évènement http://www.agendadulibre.org/events/new, et bien c'est tout à fait faisable sans JS ! Et le mieux, c'est que même si j'active le JS au cours du remplissage, je ne perds même pas mon contenu car ils utilisent le JS juste comme il faut pour ne pas obstruer le fonctionnement du navigateur sur la mémorisation ! Franchement, ça c'est un super exemple de bonne dégradation. Bravo l'ADL !

                            En attendant, ce qui est important, c’est surtout de ne pas casser les fonctionnalités utilisateur, comme :
                            - précédent / suivant

                            Oui, avec les classiques redirections pour les POST, ne pas mettre l'état du client côté serveur pour faire je ne sais quoi « d'intelligent », et mettre à jour l'URL actuelle quand en JS on modifie l'état de la page. Rien que si déjà les devs respectaient ça, ça serait beaucoup mieux. Je ne sais malheureusement pas si ce sont des principes bien enseignés.

                            • les marques-pages

                            Oui, c'est lié au précédent. Ça me fait penser également au problème du JS qui se bind sur les évènements claviers sans vérifier le modifier, ou du coup mes raccourcis clavier (avec alt/control) font faire des trucs bizarre à la page (qui ne voit qu'un évènement pour la lettre)… assez énervant.

                            • les choix de navigation (nouvel onglet / nouvelle fenêtre)

                            Ça j'avoue ne plus trop le voir, peut-être que les navigateurs forcent de toutes façons un comportement correct maintenant.

                            • j’en oublie sûrement

                            Utiliser des a avec href pour les liens, il n'y a pas d'excuse (réécriture machin, tweaker le référencement blahblah) ; mettre des sources pour votre image, même en version pixélisée s'il le faut, mais ne pas charger les images uniquement en JS ; au moins essayer une fois votre site sans JS pour voir la galère que c'est pour certains ; ne pas utiliser du JS pour charger du JS (c'est fou ce que c'est la mode) car ça oblige à faire l'autorisation en plusieurs étapes (des fois ça monte à 5 ou 6 ; souvent, j'abandonne avant) ; ne pas recharger la page pour rien (même avec une balise meta !) ; je dois en oublier également…

                        • [^] # Re: La présentation oublie des infos essentielles

                          Posté par . Évalué à 2.

                          Je suis sûr que même Berners-Lee n'accroche pas vraiment à cette tendance.

                          Waouh, je ne pensais pas qu'il me donnerait raison si vite ; un article du mois dernier de lui indique :

                          “Even though it creates some trouble [to make content interoperable], the trouble is worth it,”

                          http://www.bookbusinessmag.com/article/what-the-inventor-of-the-world-wide-web-sees-for-the-future-of-ebooks/

                          OK, c'est dans le contexte des eBook qui s'intègrent au Web, mais pour moi c'est dans l'idée.

                      • [^] # Re: La présentation oublie des infos essentielles

                        Posté par (page perso) . Évalué à 5.

                        Je regrette cela dit qu’il n’y ait toujours pas de norme pour la signature de code.

                        On peut vérifier l’intégrité des sous-ressources avec une empreinte.

                        CPS également permet de faire beaucoup de choses en matière de sécurité.

                        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: La présentation oublie des infos essentielles

          Posté par . Évalué à 1.

          "Et je rappelle que "Fourmilieres" a planté chez moi, même en activant le JavaScript."

          Est ce que tu peux m'en dire plus ? Comment est ce que je peux reproduire le problème ? Merci !

  • # Super idée !!!!

    Posté par . Évalué à 3. Dernière modification le 02/06/16 à 14:00.

    Très beau projet, très bien léché.
    Déjà, je rajoute un lien que tu aurais pu inclure dans la dépêche qui permet de recueillir des suggestions pour les plus timorés d'entre nous:
    https://www.fourmilieres.net/#/form/cfd878264cec4ed2

    Sinon, j'ai plusieurs questions et suggestions:

    • Est-il possible de l'héberger facilement sur du Cloud Foundry ?
    • As-tu prévu de proposer de saisir une date ou des plages horaires sur certaine dates pour organiser des events ?

    Par ailleurs j'ai compris que l'hébergement Kino permettait d'accéder facilement aux données mais une extension pourrait peut-être d'écrire directement des webhooks en JS dans l'interface qui accéderaient aux données pour faire des calculs, des algos de sondages (Condorcet, …).
    Ca permettrait facilement de mettre en place des alternatives aux divers voteer, doodle et consorts.

    Dernière suggestion, il serait pas mal d'organiser un genre de marketplace qui permette de récupérer des template avec ce type de hooks.

    Pour l'inspiration, hormis Google Forms, voici une petite vidéo d'un plugin pour un produit qui fait un peu ce que tu évoques:
    https://marketplace.atlassian.com/plugins/net.artemissoftware.confluence.easyforms.EasyForms/server/overview

    Je te souhaite beaucoup de succès pour ce projet.
    ```

    • [^] # Re: Super idée !!!!

      Posté par . Évalué à 1.

      Est-il possible de l'héberger facilement sur du Cloud Foundry ?

      Je ne connais pas la plate-forme, donc je ne sais pas quoi te répondre. Je suppose que ça doit être faisable mais pour l'instant c'est du terrain inconnu !

      As-tu prévu de proposer de saisir une date ou des plages horaires sur certaine dates pour organiser des events ?

      C'est quelque chose qui est actuellement discuté et devrai être présent dans les futures versions.

      https://github.com/Kinto/formbuilder/issues/114

  • # Très bonne initiative

    Posté par (page perso) . Évalué à 2.

    C'est vrai que pour concurrencer Google Forms pour le moment il n'y avait pas grand monde… Donc c'est une bonne chose !

  • # json schema form

    Posté par (page perso) . Évalué à 3.

    Bonjour

    Le format JsonSchema Form est-il normalisé/documenté ?

    Le Json Schema semble l'etre mais pas son sous ensemble sur les formulaires.

    • [^] # Re: json schema form

      Posté par . Évalué à 1.

      Si tu parle des uiSchema qui sont attachés alors la réponse est non actuellement. Il me semble que certaines personnes sont en train e travailler sur le sujet, mais impossible de remettre la main sur un quelconque lien !

  • # alternative à google form comme formbuilder ?

    Posté par (page perso) . Évalué à 2.

    Bonjour,

    An allant m'intéresser à KInto, j'ai trouvé un lien vers https://kinto.github.io/formbuilder/#/ c'est le meme projet que le tien ?

  • # Un usage 2.0. Est-ce adapté ?

    Posté par . Évalué à 1.

    Bonjour,

    Voici un usage. Clairement du 2.0 au sens collaboratif.

    Dans le cadre de mon association, nous souhaitons proposer une plate-forme où les particuliers/associations/entreprises puissent constituer des jeux de données (exemple : la liste des magasins en vrac sur Nantes, les conseils pour réduire les déchets, un listing des initiatives locales).
    - l'idée est de laisser une grande autonomie : dans la création du formulaire, dans les personnes qui remplissent, remodifient les données.
    - il est souhaitable que des modérateurs vérifient ces données - les formatent…(chaque créateur de jeux de données doit choisir ses modérateurs).
    - la possibilité d'export au format CSV est un impératif.
    - le JSON est un plus car des applications pourraient récupérer plus facilement ces données.
    - le plus est de permettre plusieurs hébergements : ces informations seraient automatiquement synchronisées (il y a 1 ou 2 structures "capables" d'avoir un tel hébergement).

    Évidemment on attend la fonctionnalité de "champs de type géographique" avec impatience.
    Nous préciserons avec insistance l'usage recommandé des licences libres.

    Votre solution (Form fillers + Kinto) est-elle adaptée ?

    Merci.

Suivre le flux des commentaires

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