Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Réflexion sur une v2 #354

Open
linsolas opened this issue Oct 10, 2019 · 5 comments
Open

Réflexion sur une v2 #354

linsolas opened this issue Oct 10, 2019 · 5 comments

Comments

@linsolas
Copy link
Contributor

Bonjour tout le monde,

Le site commence à dater un peu, malgré une refonte visuelle d'il y a 2 ans. Les principaux grieffs de la version actuelle :

  • page lourde à charger (merci les 180Ko de JS de données 😱);
  • un peu trop fouillie
  • pas d'administration des données - l'intégration ou la modification d'un bagger se fait via des PR sur le gros fichier JS avec un risque, en plus, de casser le JS et donc le site.

Les améliorations que doit (ou que devrait) apporter cette v2 :

  • Meilleure gestion des données :
    • Stockage des données sur ES ? /cc @dadoonet
    • Possibilité d'enregistrer un nouveau bagger via un formulaire
    • Offrir la possibilité de modifier soi-même son profil ?
  • Refonte du site :
    • Nouvelle homepage
    • Page pour trouver un bagger listant les villes, pour éviter d'avoir tous les baggers d'un coup, ou alors une liste plus simple.
    • Page par ville - liste de tous baggers de cette ville.
    • Page par bagger - une page pour un bagger;
    • Page de news, infos, revue de presse, témoignages;
    • Page pour les lieux acceptant les BBL.

Je complèterais la liste avec les réflexions que vous amenerez sur ce billet 😉

@abelards
Copy link
Contributor

  • OK pour changer le gros JSON mais qui d'autre l'utilise ? (des applis mobiles ?)
  • OK pour des fonctions dynamiques mais ça pose la question d'avoir un serveur.

Je pense qu'on peut répondre à beaucoup de griefs tout en restant "simples", avec un générateur de site statique.

  • on peut tout laisser sur GitHub
  • on peut conserver l'ancien JSON
  • on peut proposer de nouvelles pages
  • la modif de profil se fait sur un seul markdown ou autre

Je connais Jekyll mais je serais ravi de tester Hakyll, Hugo, Hyde ou Middleman.
J'imagine que si 180ko de JS est un souci, on ne veut pas de gros framework front ?

@linsolas
Copy link
Contributor Author

Hello,

Merci pour tes retours.
On peut rester simple en effet. On peut imaginer que l'intégration d'un nouveau bagger se fasse par une issue Github - en utilisant le bon template - qui serait ensuite traitée par une Github App (je suis devenu expert en développement de Probot 😉 ) pour faire la modification sur le fichier JSON.

De cette façon, on pourrait même imaginer avoir 1 JSON un peu global, et un fichier ensuite par bagger pour le détail (à voir si ça fait du sens, l'idée n'étant pas de requêter 300 petits fichiers JSON pour remplacer 1 gros). Ca peut être intéressant si on utilise ce fichier par bagger que dans la page dédiée au bagger...

Le framework n'est pas forcément un souci, on peut faire du React (PReact) pour gérer le site si on veut, après tout on a mis déjà plein de trucs en place (dont VueJS pour la page baggers.html).

@dadoonet
Copy link
Member

Bonjour

Avant de parler technique, j'aimerais qu'on discute des besoins. Je vais donc exprimer ici "mes" besoins, ce qui ne veut pas dire que ce soit complet et que cela s'applique à tout le monde.
Puis je vais exprimer "ma" vue technique, hautement discutable :)

Besoins

Simplification de l'ajout/modification/suppression des speakers et talks

Aujourd'hui nous passons par un système de PR qui oblige un "admin" à valider les modifications avant de pouvoir les rendre visibles.
Avoir un selfcare qui permet à chacun de gérer ses informations rendrait le service encore plus fluide.

Pour cela, il faut techniquement envisager un système d'authentification permettant de donner les droits au speaker de modifier son profil et ses talks. Et des droits plus étendus d'admin éventuellement pour que les admins puissent également intervenir.

Internationalisation

J'ai lancé dans ma boite le même principe de BBL dans d'autres pays. J'aimerais donc beaucoup pouvoir leur proposer également ce service dans les autres pays.
Deux possibilités pour cela, rendre brownbaglunch.fr complètement international, autrement dit on y verrait les speakers de tous les pays, avec gestion des talks en plusieurs langues, ...
Ou on documente notre plateforme et on permet à chacun de faire un fork par pays.
Je préfère de loin la première solution. Notamment pour mes propres besoins, l'idée de pouvoir parler dans des pays autres que la France à l'occasion de déplacements me plait beaucoup. Pour cela, il faut faire venir d'autres speakers, d'autres entreprises sur notre site.

Recherche geo localisée

J'aimerais que chaque speaker indique sur une carte sa localisation et son rayon de couverture. Non pas en terme de texte comme actuellement mais avec de vraies coordonnées géographiques (lat, lon, range). Ou en dessinant un polygone sur une carte pour cibler la zone d'action du speaker.

Ainsi, une entreprise qui cherche qui elle peut inviter, pourrait plus facilement trouver les speakers qui peuvent venir dans leurs locaux.

Alerting

Une entreprise pourrait vouloir être informée lorsqu'un nouveau talk/speaker est disponible dans sa région. Notamment utile pour les entreprises qui font des BBLs très régulièrement. En couplant, du texte libre, des tags, de la localisation, on devrait pouvoir fournir ce service.

Notes / Revues / Avis

Pas nécessairement fan des notes, mais peut-être que de laisser la possibilité aux entreprises de commenter le ressenti sur la session serait utile. Libre ensuite au speaker de publier ou non un avis.
Cela a un inconvénient toutefois. Les nouveaux speakers risqueraient peut-être d'être moins visibles...

Entreprises

De la même façon que nous avons des speakers, nous avions commencé à ajouter des entreprises hosts, de façon à ce que les speakers puissent venir proposer leurs sujets.
On peut poursuivre cette idée avec également un selfcare. Peut-être nécessitant pour le coup une gestion un peu plus fine des droits. Plusieurs employés pouvant gérer l'accueil, quid des départs, ...

Reporting

Nous pouvons envisager du reporting en fonction des data que nous avons. Et partager cela sur notre site web. L'évolution du nb de speakers, les visites sur notre site, le nb de talk, par ville... Bref à imaginer.

API

Bien que semblant technique, je pense que nous devons d'abord penser en terme d'API afin de rendre notre site intégrable dans d'autres services, ...
Donc avoir des API propres me semble utile.
Un autre service auquel je pense est en fait notre frontend. Web aujourd'hui, mobile demain ?
Faisons en sorte que notre front n'utilise que des API documentées et publiées.

Technique

Plateforme

Nous avons aujourd'hui deux entreprises qui nous fournissent effectivement une plate-forme où nous pouvons déployer nos services:

Languages

Il faut choisir le language le plus adapté en fonction de la couche (back ou front ou API).
Pour la back, j'ai une préférence pour Java pour plusieurs raisons:

  • Le nombre de dev qui peut contribuer du coup à ce projet, sa maintenance, son évolution
  • Les frameworks existants (Quarkus, Spring boot, Keycloack, VertX, ...)
  • Le support par clevercloud de Java
  • Ma propre expérience (mais ça ne compte pas ici)

Pour le front, je ne suis pas un dev front, donc je préfère que les nombreux experts ici proposent effectivement leurs visions. Sachant qu'avec des API, on pourra de toute façon aussi avoir plusieurs "front" suivant le terminal (web, mobile...)

@ygrenzinger
Copy link
Contributor

Si on se concentre sur l'aspect perf et éviter le gros JSON difficile à découper, un site statique comme le propose @abelards permettant de découper mieux le contenu est pas bête ;)

Ptet que GatsbyJS peut être intéressant ? https://www.gatsbyjs.org/packages/gatsby-plugin-local-search/?=search
https://www.gatsbyjs.org/docs/adding-search/

Pour aller plus loin, avec tous les besoins auquel pense @dadoonet , clairement ça serait intéressant de poser de solide bases :)

A voir si on peut intégrer la gestion du back / users directement dans un ES (sorte de CMS API) et mettre le reste dans un gatsbyjs

Je propose des idées. Je dis ptet des conneries :)

@dadoonet
Copy link
Member

dadoonet commented Jan 7, 2020

Hello all!

D'autres avis ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants