Un Framadate avec interface améliorée

Depuis que je me souviens, Framadate ne semble pas avoir tellement évolué. Même que j’avais commencé une alternative il a y 10 ans je crois que je nommais Kyucan. Cette implémentation est tombée dans l’oubli depuis mais le projet me turlupinait encore…

Démo 2018

(ancien URL: https://kyucan-xlxagwhaac.now.sh/ - maintenant sur https://millette.github.io/kyucan/)

Ça requiert le JavaScript (avec peut-être éventuellement une version plain HTML) et c’est une démo très limitée pour voter sur un événement existant (ne cherchez pas l’interface pour créer un autre événement). De plus, les résultats vont nul part, c’est vraiment juste pour obtenir du feedback à propos de l’interface pour voter et soumettre de nouvelles dates. Notez que je n’ai pas trop fait attention à l’aspect responsive encore.

Les sources

Les sources (commit hash bbc884c0e1eafc2ac09c566728170cabc20d2298) sont sur GitHub:

Comme j’aime bien tester différents stacks, ici je suis revenu à Riot (genre de React), Bulma (genre de Bootstrap) et Parcel (genre de webpack), mais ces choix ne sont pas dans le ciment. Ça me permettait de tester un nouvel environnement et en même temps, c’est une expérience de développement rapide.

Suggestions ou commentaires

Si vous avez des suggestions pour l’interface ou pensez à des fonctions qui manquent à Framadate, ça va me faire plaisir d’essayer ça.

Intéressant.

  • J’aime le fait que le participant puisse ajouter des dates et heures.
  • Je pense que le “gradateur” de préférence est un peu “overkill”; 3 boutons Oui, Non, Peut-être suffiraient selon moi, comme Framadate, mais avec option pour ajouter une raison au “peut-être” (ex: “si je trouve une gardienne”, “ok mais je serai dispo jusqu’à 10 h”, “ma douce va me bouder si j’y vais là”…)

Merci Bruno (@bpruneau),

Le gradateur, c’était une façon d’obtenir des résultats plus précis sur les dates, mais je crois que tu as raison de dire que c’est overkill.

J’ai mis des boutons radio à la place et je retiens ton idée de mettre une raison. Ça pourrait être un commentaire générique, peu importe la préférence (oui/non/possiblement).

Nouvelle version

(anciens URL https://kyucan-zpactlwccp.now.sh/ (précédemment https://kyucan-bvpzzacmty.now.sh/ - maintenant sur https://millette.github.io/kyucan/)

La version v0.0.1++ est en ligne à un nouvel URL (now.sh ne permet pas les mises à jour, tout y est immuable). Ça permet en même temps de comparer les versions au besoin.

Questions

  • Est-ce que ça aiderait si on pouvait ordonner les dates ou serait tout autant overkill?
  • Est-ce que ça aiderait si je retirais le bouton 2e étape ou dit autrement, sans demander de confirmation?

Quelques commits plus tard, j’ai une version déployée sur GitHub:
https://millette.github.io/kyucan/

On peut voter sur un exemple:
https://millette.github.io/kyucan/#vote/ab0ba928d740c604

Notez que la DB est simplement https://www.jsonstore.io/ et permet à quiconque d’éditer (même effacer) le contenu dès qu’on connait le endpoint. C’est une solution temporaire pour Kyucan. Il n’y a pas non plus de page de résultat encore, mais au moins l’URL ne changera pas pour chaque déploiement.

J’aimerais bien savoir ce que vous en pensez :slight_smile:

  • Oui, il faut ordonner les dates.
  • La seconde étape a d’utile qu’elle permet d’afficher plus succinctement les choix de l’utilisateur sans les contrôles. Cependant, pour rester clair, il faudrait cacher l’étape 1 (mettre un bouton à l’étape 2 pour revenir à l’étape 1).
  • Sur un cellulaire, je clique sur ajouter une date, et il s’affiche le frame pour ajouter une date mais le curseur s’en va en haut du formulaire, au champ Nom. Un peu tannant…

Pas sûr de te suivre… L’instigateur passera par les 2 étapes (descriptions, title, etc. et ensuite donner les premières dates (aka voter)), tandis qu’un invité ne passe que par la 2e étape (soumettre des dates et/ou voter).

Là je n’ai fait aucun effort de responsiveness encore mais c’est dans les plans.

Merci encore pour tes commentaires, j’apprécie beaucoup ton attention.