Zeste de Savoir et le futur du front

Je maintient que je ne suis pas persuadé qu'utiliser un framework soit la solution. Pour moi ce sera comme ce qui a été gais actuellement : ce sera le choix des dev front qui s'occuperont du front au jour le jour.

disclaimer : je ne vais pas être poli dans la suite.

En fait c'est relativement simple, si vous accepter quelque chose proche de ma proposition, à savoir réorganiser et documenter mon code, je le fais. S'il s'agit de porter le site sur un framework, je quitte dès à présent le développement car tout ce que ferais sera de toute façon refait, autant que je ne perde pas mon temps.

Fuck Alex, tu fais chié. J'essaie de rester calme depuis des mois mais la j'en ai marre. On discute, on débat, on essai de voir les avantages et les inconvénients. Et toi tu te pointe en mode "faites ce que je propose sans discuter sinon…"

Pour moi le sujet a atteint encore un point de non retour a cause de ton incapacité a te remettre en question ou accepter des compromis. J'ai envie de pousser vers un framework juste pour te faire chier quand je vois ça. Mais je vais uniquement arrêté de te lire dans ce sujet.

Et toi tu te pointe en mode "faites ce que je propose sans discuter sinon…"

Tu interprète mal. Je dis que soit je fais ce que j'ai proposé, soit je laisse la main à qui souhaitera faire ce qui aura été décidé mais aura été différent de ce que je propose.

Il n'est pas question de "ne pas discuter" : on fait que ça, et j'essaye d'apporter des solutions aussi. Simplement, si la solution adoptée ne me plait pas, je n'aurais pas envie de le faire donc je ne le ferais pas. Rien ne m'y oblige, je préviens simplement que je ne passerais pas du temps à faire quelque chose qui me déplaît. Je fais ce projet par envie, si ça devient une corvée, alors je dis non.

Ça serait sympathique de ne pas voir chacune de mes phrases comme des mises en demeure. Je ne met pas en demeure le projet, mais mon service au sein du projet. C'est quand même totalement différent.

Si même quand je dis "je n'ai pas envie de le faire parce que ça n'est pas ma philosophie" et je me fais encore traiter parce que ça ne me plait pas et que je n'ai pas envie de le faire, ça ne me donne pas non plus envie de continuer à participer. Saches d'ailleurs que moi aussi je fais des efforts, je reste calme et j'accepte la critique et les suggestions qui me plaisent.

Aussi, j'aime cette faculté de chacun à mettre de côté tout le reste pour insister sur mes points négatifs. En l’occurrence, j'enrichie la discussion mais on trouve encore le moyen de me dire que je fais chier (infinitif, "er" pas "é").

Je suis bénévole, comme chacun ici, et je suis un de ceux qui a donné le plus de son temps à ce projet. Si j'ai envie de partir, je pars. Par bonne conscience je reste pour permettre une transition. Si je fais vraiment chier, la transition sera plus nette.

Voilà, j'espère avoir clarifié mon point de vue, et j'espère qu'on arrêtera de me percevoir comme une victime ou un méchant à chacune de mes participations. Je suis lassé de ce projet, je souhaite simplement passer à autre chose au plus vite sans pour autant laisser ce projet dans la mouise. Donc la solution doit me plaire et être rapide ou alors je laisserais effectivement ce projet dans la mouise.

PS : Ceci est une réponse HS mais nécessaire à ce qu'on arrête de digresser sur ma personne plutôt que sur les volontés du projet et mes volontés personnelles (c-à-d passer à autre chose).

Bonjour tout le monde,

Le feu du débat s'est calmé et j'ai le temps de faire un premier bilan sur ce topic, alors on est partis.

En "résumé"

On a besoin d'une doc la plus complète possible

Je crois que tout le monde est à peu près d'accord avec ça non ? En tous cas ça revient de partout, et pas seulement ici.

Ça inclus aussi une méta-doc de type "comment contribuer".

Je propose de partir sur le système de rédaction de la doc dont a parlé Javier (i.e. co-écrire la doc avec Alex et un dev novice). Pour moi c'est la priorité n^o 1.

Le besoin de développeurs front à court et moyen terme

Rappel : le point de départ de cette discussion, c'est parce que Alex-D a annoncé qu'il restait loin du projet dès que la nouvelle page d'accueil serait prête. Le but de cette discussion, c'est de trouver comment faire pour remplacer Alex-D en développeur front principal. Donc, l'option de dire "on attend, on peut gérer le tout venant" n'est pas une réponse.

Il nous faut donc au moins :

1. Quelqu'un capable de gérer les urgences même en cas d'absence d'Alex-D. Que cette absence soit prévue ou non.
2. Quelqu'un capable de gérer les impacts sur les ZEP qui arrivent.
3. Quelqu'un capable de former la personne qui va reprendre le rôle de développeur principal front, puisque Alex-D a déjà prévenu qu'il prenait du recul après la page d'accueil.

Le mot-clef est backup. C'est pour ça que je ne ferai pas la prochaine MEP moi-même mais que ce sera quelqu'un d'autre, que j'épaulerai autant qu'il en aura besoin.

À court et moyen terme, le front ne sera pas intéressant

Ou très peu. Parce que bien qu'on ait des ZEP dans nos tuyaux, ce qu'on a à court et moyen terme, c'est très majoritairement du bugfix et et petites améliorations (nouvelle page d'accueil – ce qui reste petit fonctionnellement à l'échelle du site –, un peu de dynamisme, etc.)

Pire : Zeste de Savoir n'est pas, ne sera pas, et ne sera probablement jamais une single-page application. Parce que fonctionnellement ce n'est pas une application qui gagnerait à ça : c'est un site très majoritairement éditorial (contenus très fixes, forums en réalité très fixes aussi). Cela dit, ce genre de technique peut devenir intéressante pour certaines parties du site, je pense notamment aux outils de rédaction.

Le framework, ou pas

J'ai l'impression que la moitié des intervenants ont vu le mot framework et on à moitié pêté un câble en oubliant tout le reste du premier message et en imaginant je ne sais trop quoi. Franchement, en lisant certains messages, c'est vraiment l'impression que j'ai.

Rappel : Cette idée n'est qu'une option parmi d'autres. Je ne la privilégie pas. Je ne privilégie rien. Zeste de Savoir est dans une position problématique à moyen terme, et elle doit trouver une solution, et celle-ci doit être pragmatique et non dogmatique.

Quelques détails et points particuliers

Spécificité des besoins, grille et évolution du design

J'ai l'impression qu'outre la quantité de travail (et tout ce que ça implique : régressions, …), le 2^èmeplus gros argument contre l'utilisation d'un framework est le fait que ZdS soit spécifique au niveau de son design, qu'il ne rentre pas vraiment dans une grille donc dans le cadre d'un framework, etc.

Question brutale et naïve : est-ce vraiment un problème bloquant ? Dans quelle mesure ne pourrait-on pas améliorer ce design de façon à ce qu'il rentre dans des standards plus communs et faciles à maîtriser sans pour autant devenir générique ?

D'une manière générale, le front pour moi est un projet d'ingénieur : il marche, il fait ce qu'on lui demande, il est optimisé, il est sûrement techniquement très beau (je n'ai pas les compétences pour en juger). Mais du coup il est fragile et y toucher peut vite devenir délicat. Pour moi on a fait clairement une erreur ici en privilégiant la beauté de la chose face au pragmatisme qu'aurait été de prendre des solutions les plus communes possibles quitte à perdre un peu en optimisation.

De l'exigence dans un projet communautaire

Je comprends qu'on puisse demander des trucs, râler si c'est pas fait, gueuler sur des promesses non tenues, hurler à cause d'incompréhensions, pleurer pour des mésententes, rager parce que le connard qui a fait la MEP ne s'est pas relu et a poussé un paramètre foireux, grommeler parce qu'on a pas une fonctionnalité qui poutre ou piaffer d'impatience devant sa réalisation toujours trop longue.

Par contre, il est une chose que l'on ne peut pas se permettre dans un projet communautaire et bénévole sans passer pour un abject égoïste, c'est exiger.

Nous sommes tous bénévoles, nous sommes tous libres de participer à ce projet, et nous avons tous d'autres préoccupations. Nous sommes donc tous là pour avancer ensemble sur ce projet et trouver des solutions quand il y a des problèmes (et surprise, il y aura toujours des problèmes).

J'ai vu passer des phrases dans ce topic qui ressemblent beaucoup trop à des exigences à mon goût – ou à son cousin germain, le chantage.

Attention à la pertinence des exemples

Si vous donnez un exemple, vérifiez ce que vous avancez. Exemple avec ceci, où l'on parle des frameworks :

Selon la façon dont on comprends le passage que j'ai mis en italique, on peut comprendre :

• Que Alex-D n'a pas utilisé Bootstrap sur le ZdS, ce qui relève d'un choix parfaitement sain,
• Que Alex-D n'a pas utilisé Bootstrap alors que ça lui avait été demandé par son supérieur, ce qui relève probablement de la faute grave.

J'ai toujours un peu du mal avec ce genre d'arguments ambigus, surtout si on corrèle ça avec la notion de confiance envers la personne avec qui on travaille.

Kje, si ce n'est pas de l'ironie ou de la mauvaise foi, je ne comprends pas. De même pour ton dernier paragraphe indécent, SpaceFox.

D'un point de vue (très) extérieur et désintéressé, je trouve votre Alex-bashing inutilement blessant et souvent hors-sujet. Et j'ai beau suivre de loin plusieurs topics de la Dev Zone, je ne comprends toujours pas ce que vous cherchez à prouver puisque tout semble clair entre vous et que le point de non-retour a déjà été franchi.

J'ai conscience de me mêler de ce qui ne me regarde pas, mais franchement, votre volonté de prolonger ce vaudeville, semblable à ceux d'une autre époque, devient lassante.

De même pour ton dernier paragraphe indécent, SpaceFox.

Je me pose une vraie question quant à ce que signifie le paragraphe dont je parlais dans ce "paragraphe indécent". Parce que pour moi il n'est vraiment pas clair sur ce que Alex a voulu dire par là, et que ça me pose vraiment un problème de travailler avec quelqu'un si ce quelqu'un utilise comme argument le fait qu'il se met en position de faute grave vis-à-vis de son employeur pour des raisons dogmatiques (en supposant que ce soit la signification de cette phrase, ce que je n'espère pas).

Et quand j'ai une question, je la pose. Quoi de plus normal ?

Maintenant, il semblerait que demander une précision relève de l'indécence et que soulever un point qui peut contrarier Alex relève de l'Alex-bashing. Alors on fait quoi ? On fait semblant d'ignorer les problèmes ? Je ne pense pas que ça fonctionne.

Edit : Clarification du début et de la fin de mon propos.

@Graphox : écoute perso j'en ai mare qu'on me taxe de bashing contre Alex dès que je ne suis pas d'accord avec sa façon de faire. Pourtant autant sur ce sujet que sur celui des outils front, en me limitant aux recent, le fond de mes propos va dans son sens.

Ce que je ne comprend pas c'est qu'on fait un sujet pour s'organiser pour son départ annoncé et que dans ces conditions il nous impose de suivre sa vision de la suite, sans possibilité de discuter d'alternative. Je lui demandais pas d'accepter un framework, je ne pense pas que ce soit une idée, mais je ne suis pas persuadé que sa solution soit mieux ou la meilleur.

Sérieux j'en ai marre d'être le méchant parce que je n'aime pas qu'on m'impose un truc. Je remarque d'ailleurs qu'il y a seulement deux personnes sur ce sujet qui ont tenté de nous imposer des choses, les deux dev front. Et si j'ai réagi c'est que c'est loin d'être la première fois.

Donc c'est bon j'ai autre chose a faire que de faire le méchant. Moi aussi je laisse tomber le dev de zds. Et pour le markdown dans les pdf, soit je vous met en place rapidement un convertisseur HTML vers pdf pour utiliser notre parseur actuel, soit vous vous debrouillez je part immédiatement sans plus aucun dev.

Pourrait-on se recentrer sur le sujet initial sans apporter ses problèmes personnels ou professionnels à la discussion, déjà bien compliquée ? Merci

J'ai pas envie de rentrer dans le débat "méchant"/"pas méchant", ce n'est pas le but du sujet (qui est résumé dans le post de SpaceFox et dont il faudrait s'intéresser et trouver un consensus). Par contre, il n'aura fallu qu'un post pour que le débat se réchauffe et ça, ce n'est pas acceptable. Le but du post de SpaceFox, dernier paragraphe compris, n'était pas de relancer une embrouille, peu importe laquelle. Il essaye juste de faire avancer cette discussion, de répondre à des problématiques réelles/réalistes et ce serait bien de s'y intéresser.

J'en reviens là à mon propos ici. Les esprits échauffés nuisent à la discussion et il est assez apparent qu'au niveau dev, on est un peu à bout de nerf. Ce serait donc génial si l'on pouvait éviter de chercher à lire entre les lignes, en faisant des procès d'intention et juste discuter du problème soulevé. Il s'agit avant tout de projeter ce qui doit être fait avant de savoir comment le faire. Ce sujet est là pour répondre à un problème.

J'en ai ras le bol des personnes qui parlent d'Alex-bashing dès que l'on contredit Alex. Alors certes certaines phrases peuvent être déplacées (je suis d'accord avec Graphox sur le dernier commentaire de SpaceFox par exemple), mais il faut aussi comprendre le ras le bol de certains.

Aujourd'hui, c'est la 3ème fois qu'Alex fait un départ sur un coup de tête, mais qu'il revient… alors si vous voulez voir du Alex-bashing, je peux vous en faire, mais Kje passera pour Barbie et le Lac des cygnes à côté… parce que bon, jusque là dans le débat je l'ai trouvé juste et neutre (si on omet sa phrase d'énervement).

Donc, si vous avez un problème avec du Alex-Bashing (ou autre), deux solutions :

• Vous en parlez à la personne en privé
• Vous venez remplir ma boite à MP pour vous plaindre (vous pouvez aussi la remplir de messages d'amour)

Pour revenir au débat :

Je trouve intéressante l'idée d'une écriture de doc en binôme avec Alex pour assurer la pérennité du projet. Parce que, même si Alex compte suivre le projet de loin, on n'est jamais à l'abri d'un événement privé (genre, on fait quoi s'il se casse les deux mains au ski ?) qui pourrait être emmerdant.

Je n'ai pas regardé récemment le code du front, mais ne serait-il pas envisageable de passer, progressivement, sur un système de grille perso en utilisant les conventions de nommage d'un framework existant ?

Si je pose la question, c'est qu'actuellement, je fais partie des personnes qui voudraient participer, mais honnêtement quand j'ai fait ma journée au TAF, fait mon heure de voiture pour rentrer, fait ce que j'ai à faire chez moi, j'ai pas envie de me taper un code pas totalement documenté et perso. Par contre, si j'arrive et que je vois des col-sm-3 bon même si c'est un framework made in ZdS, je sais où je vais et ça démotive moins.

L'avantage est double :

• On a un framework qui collerait aux spécifications du projet (pas besoin d'overrider Boostrap comme ça)
• On profite d'une base de doc, et cela facilite grandement l'intégration de nouveaux dev front.

Voilà voilà

Je vais commencer par réagir sur le résumé de Spacefox

On a besoin d'une doc la plus complète possible

On est d'accord sur ce point. Je compte, je pense, participer à la réalisation de cette doc.

Le besoin de développeurs front à court et moyen terme

Je n'ai pas, pour ma part, décidé de quitter le projet. Je vais donc essayer de plus m'investir, simplement parce que je n'ai pas envie que le ZdS et que le travail d'Alex tombe en ruine

Je ne maîtrise pas autant Photoshop qu'Alex (autrement dit, je ne pense pas pouvoir (re)designer une page de A à Z comme l'a fait Alex), mais je pense pouvoir intégrer ce genre de pages, gérer les urgences / les ZEPs à venir, et créer de nouvelles pages en me basant sur l'existant.

De plus, si ça ne dérange pas trop Alex, je risque de le consulter de temps en temps, si j'ai besoin de conseils ou d'aide (puisque l'on parle depuis le début sur Skype ensemble ; ce qui je pense nous a permis… bah de correctement travailler ensemble, et qui fait de moi aux yeux de certains "l'exception qui confirme la règle", par rapport au fait que je maîtrise relativement bien le front à l'heure actuelle). Autrement dit, je pense que l'expertise d'Alex ne sera jamais loin.

À court et moyen terme, le front ne sera pas intéressant

J'en ai conscience. Je vais essayer à moyen/long terme essayer d'y remédier, de réfléchir à comment réorganiser le front en prévision de l'API.

Et même, si vraiment le front m'ennuie, il reste des tonnes d'issues intéressantes à traiter, qui sont classées dans l'ancienne "Lettre au père noël". Je pense notamment à la mise à jour automatique des dates relatives, des @mentions dans l'éditeur, de l'éditeur lui-même, du mode nuit, … etc.

Le framework, ou pas

Je n'ai pas personnellement pété un câble en voyant le mot Framework. J'utilise régulièrement moi-même bootstrap et foundation. Ma réaction, c'était plutôt: "Qu'est-ce qu'ils pensent vraiment ?". Pour moi, de base, repartir de zéro et tout adapter pour un framework ne réglerait pas le problème de documentation, et de la facilité/de l'accessibilité de la partie front du site. J'ai expliqué, et Alex a fait de même, en quoi l'utilisation d'un framework n'est pas la bonne solution.

Si l'on s'est focalisé la dessus, c'est d'abord parce que c'est le choix à faire que tu demandais dans ton premier message, et ensuite parce que j'étais en accord avec le reste du message. Les outils, le front pas intéressant, le manque de doc, la mauvaise réputation du front… Tout ça, j'étais d'accord avec toi (ou alors il y a un débat autre part, pour les outils), donc je n'ai pas commenté point par point ton message. D'où la focalisation sur l'utilisation d'un framework.

Spécificité des besoins, grille et évolution du design

Je ne dirais pas que le front est fragile. Pour moi, il est juste fait pour ce site, et pour rien d'autre. On ne développe pas de framework destinée au grand public, mais bien ce site en particulier. C'est vrai que du coup, le développement d'une page complètement neuve, avec un design à imaginons 4 colonnes demanderais plus de développement avec le code actuel que avec la framework X ou Y. Mais créer une nouvelle page, avec cette même mise en page (sidebar + contenu), et qui ressemble niveau design à ce qui est existant sur le site devient presque trivial. Par exemple, je me souviens avoir complètement refait la page des galeries. J'ai pu rapidement réutiliser le style de liste qu'il y a sur le forum / les MPs, les boutons, et la liste des utilisateurs, comme dans les MPs. Du coup le style spécifique au galerie en vue liste (je parle pas de la vue grille, qui elle est spécifique à cette page) est vraiment maigre.

De l'exigence dans un projet communautaire

Si tu fais référence à mes demandes par rapport à l'API dans me premier message, je n'exigeais rien de personne. Je pensais juste exprimer le fait qu'a mon sens, l'API permettrait de rendre le front intéressant, et que je serais très heureux le jour où elle arrivera.

Si tu fais référence à la réaction d'Alex par rapport à l'utilisation d'un FW. Je comprends que vous ayez mal réagi, et que vous voyez ça comme du chantage. Mais comprenez le point de vue d'Alex. Il est sur le point de partir. Ca fait des mois qu'il en parle, pourtant il est encore en train de re-designer la page d'accueil. Et la, on lui annonce que l'on va implémenter à son départ quelque chose qu'il a refusé depuis le début pour X raisons, et ainsi foutre en l'air une partie de son travail. C'est peut-être pas à ce point, mais le passage à un framework demanderait une réécriture quasi-complète.

C'est certes pas à la même échelle, mais c'est comme si on disait (je ne suis pas sérieux, je précise…) "si vous pouviez changer de framework, parce que django ne permet pas ceci ou cela, et il est nécessaire pour nous de pouvoir faire ça". On est d'accord que c'est idiot, bien que pas impossible. Je suis sûr que techniquement vous pourriez changer de framework, et même réutiliser du code, mais je sais que vous ne le ferez pas, parce que c'est juste une perte de temps, et complètement impensable. A notre échelle, ça reviens presque au même.

Je crois que je vais recevoir quelques -1 à cause de cette partie, mais je ne sais pas comment expliquer autrement, puisque nos autres tentatives de pourquoi l'utilisation d'une framework n'est pas une bonne idée n'ont pas l'air d'été comprises. Bizarrement, le message de Stranger (qui est sûrement, plus apprécié par le monde qu'Alex et moi) qui explique que le basculement vers un framework est surprenant à ce stade du projet reçois +11, et aucun -1. Quand Alex ou moi-même rédigeons un message qui explique avec les raisons technique pourquoi un framework ne résous pas tout, on se reçois des -1, et que 3 ou 4 "+1". Ce n'est pas pour me plaindre que je dis ça, ni pour accuser qui que ce soit de bashing, mais je ne comprends juste pas. J'ai l'impression que les arguments qu'on avance ne sont pas pris en compte. C'est peut-être de la paranoïa, mais c'est ce que je pense.

Attention à la pertinence des exemples

Je ne crois pas que se focaliser sur une partie ambiguë des propos d'Alex fera avancer les choses.

Par rapport au message de kje:

écoute perso j'en ai mare qu'on me taxe de bashing contre Alex dès que je ne suis pas d'accord avec sa façon de faire. Pourtant autant sur ce sujet que sur celui des outils front, en me limitant aux recent, le fond de mes propos va dans son sens.

J'étais il y a quelque mois le principal (et peut-être l'un des seuls) défenseur d'Alex face aux méchants devs backs (c'est en partie ce que je pensais au début, en caricaturant beaucoup). Maintenant, j'ai pris un peu de recul, je me rends compte qu'Alex a pu, et peut être désagréable, et j'ai découvert récemment que je pouvais l'être aussi. Voir à un niveau au dessus. Je m'en suis excusé, je regrette, on en parle plus.

Maintenant, on parle de solutions pour remplacer Alex. Il participe au débat, et explique pourquoi l'une des solutions envisagée n'est pas la bonne, et fait comprendre qu'il n'aidera pas à faire la transition si le choix le moins logique à ses yeux est fait. En réponse, il a de la rage, et des gens qui se concentrent sur une petite partie de ses propos. Je ne veux pas, et je ne vais pas faire passer qui que ce soit comme le méchant, mais j'aimerais que certains se rendent compte du problème de notre point de vue. A aucun moment Alex ou moi-même dans ce thread avons rédigé de message de rage dans l'optique de râler sur quelqu'un. L'objectif de mes messages depuis le début dans ce thread a été essentiellement d'exposer mes arguments pour ou contre les solutions proposées, pour faire avancer les choses. J'ai l'impression qu'Alex avait les mêmes objectifs dans ses messages. Et pourtant, on s'éloigne du sujet, et on commence à débattre d'Alex-bashing.

Par rapport au dernier message de devock:

Je n'ai pas regardé récemment le code du front, mais ne serait-il pas envisageable de passer, progressivement, sur un système de grille perso en utilisant les conventions de nommage d'un framework existant ?

En fait, avec le design actuel, je ne sais pas si une grille soit réellement utile. Je m'explique:

La mise en page général de toutes les pages, c'est sidebar + contenu. La sidebar, et le contenu ont une taille fixe (respectivement 400px et 960px sur les grands écrans). En général, une grille utilise des tailles en %. Il faudrait donc soit passer sur une largeur max fixe (comme la plupart des FW le proposent), soit avoir une taille flexible pour au moins la sidebar (ce qui peut être potentiellement pas beau ; en tout cas j'ai du mal à l'imaginer…).

Les seuls autres endroits où une grille est applicable sont très localisés. Je vois par exemple le dropdown de la navigation du header (qui a 5 colonnes), la "vue grille" des galeries, les colonnes de l'accueil, et les colonnes dans la liste des articles. Ca fait peu, et je ne vois comment l'on pourrait adapter tout le design sur une ou plusieurs grilles…

Si un jour, dans une v42 l'on prévoit un redesign complet, l'on pourra peut-être se baser sur une grille, et peut-être même sur un framework, mais à l'heure actuelle, je pense juste que c'est pas la bonne solution…

Si je pose la question, c'est qu'actuellement, je fais partie des personnes qui voudraient participer, mais honnêtement quand j'ai fait ma journée au TAF, fait mon heure de voiture pour rentrer, fait ce que j'ai à faire chez moi, j'ai pas envie de me taper un code pas totalement documenté et perso. Par contre, si j'arrive et que je vois des col-sm-3 bon même si c'est un framework made in ZdS, je sais où je vais et ça démotive moins.

Il est vrai que l'on peut réfléchir à renommer certaines classes avec des noms plus conventionnels. Avoir une classe "btn-default / btn-danger / btn-primary" au lieu de "btn-grey / btn-cancel / juste btn", ou encore "navbar" au lieu de l'élément "header" me parait pas déconnant. A essayer, je suis plutôt pour, si ça peux rassurer certains futurs contributeurs.

Voila voila, j'en ai mis du temps pour rédiger ce message, j'espère qu'il en valait la peine, et qu'il changera les idées de certains

J'aimerais savoir maintenant ce que vous pensez de l'utilisation d'un framework, maintenant que nos arguments contre sont relativement clairs, et si les solutions proposées (réorganisation du code, co-écriture de la doc avec un dev back, un investissement plus important pour ma part, et un renommage des classes pour avoir quelque chose de plus "conventionnel") vous conviennent. J'aimerais en particulier un retour de SpaceFox, de kje et si possible de firm1. Ce n'ai rien contre vous, mais il semblerait que vous êtes plutôt favorables à l'idée d'un framework, et j'aimerais mieux saisir vos arguments / votre point de vue

Sandhose

OK, digression.

À un moment, je vais finir par me demander quelle langue j'écris. Je vais donc préciser, encore une fois, que ceci :

c'est d'abord parce que c'est le choix à faire que tu demandais dans ton premier message

Et ceci :

Ce n'ai rien contre vous, mais il semblerait que vous êtes plutôt favorables à l'idée d'un framework, et j'aimerais mieux saisir vos arguments / votre point de vue

C'est tout simplement complètement faux :

Le framework du premier message n'est qu'une idée que j'avais mise parce qu'elle avait été déjà émise et sur laquelle j'émettais déjà des réserves importantes, cf la liste d'inconvénients du premier message.

Il n'est absolument pas question de choix entre mes idées ici, mais de trouver une solution à un problème et ceci peut impliquer les idées de n'importe qui. Pas la peine d'interpréter ou de lire entre les lignes : tout ce qui doit être écrit l'est écrit explicitement.

Fin de la digression, vous pouvez reprendre un débat normal.

@Sandhose : on peut appliquer un système de grille partout en fait, alors peut-être pas au sens strict de Boostrap, mais par exemple, le header c'est une ligne de 3 colonnes :

• La première avec le logo
• La deuxième avec le menu de navigation
• La troisième avec le menu membre (qui contient une ligne de quatre colonnes)

La ligne du dessous (avec le fil d'ariane), c'est une ligne avec deux colonnes (la sidebar, et la partie de recherche).

Bon je ne vais pas faire tout le site, mais l'idée est là : on peut tout grillager !

Donc on peut faire un système de grille, en reprenant des conventions de nommage d'un framework connu (Boostrap, Fondation ou autre) même si le rendu diffère (on n'est pas obligé d'utiliser le padding-left: 15px ou padding-right: 15px des colonnes de Boostrap, par exemple). Par contre, c'est clair que cela demandera peut-être des concessions sur le design (cela ne veut pas dire tout casser hein !)… quoi que si c'est bien réfléchi en amont, ça peut le faire.

Maintenant, c'est clair que cela ne peut pas se faire du jour au lendemain et que c'est à faire progressivement (pour justement ne pas tout casser) :).

J'insiste avec les grilles, mais je trouve que c'est un juste milieu entre : - Le passage à un framework - Un design trop from scratch qui peut en rebuter plus d'un

Maintenant à voir si une telle solution pourrait plaire à d'autres.

@SpaceFox: Dans ce cas, je vais préciser: j'ai donné mon avis sur une hypothèse que tu as émise. Et du coup, ton avis par rapport aux propositions qui ont été faites ? (vraiment, ça m'intéresse)

@devock: En fait, la plupart des endroits ou la grille peut éventuellement s'appliquer, c'est souvent 1 ou deux éléments aux extrémités avec des tailles fixes, et l'élément central qui prend le reste de la place.

Pour le header, par exemple, le logo et les notifs/login ont une taille fixe, et sont respectivement alignés à gauche et à droite. Après, le contenu central est flexible, et prend la place restante.

On est dans le même cas de figure pour la sidebar/contenu: la sidebar a une taille fixe, le contenu est centré par rapport à la largeur restante.

Or, tous les systèmes de grilles sont basés sur des colonnes à tailles égales… (en général 12 colonnes) Et pour le coup, c'est pas vraiment adaptable à notre design…

ça serait dommage que ce topic parte quelque peu en hors sujet. Il y'a des vrais problèmes de maintenance du front-end actuel, si on arrive à trouver une solution pour les résoudre à court, moyen, et long terme ce topic sera résolu.

A court terme, on dispose d'Alex-D pour s'en occuper, à moyen terme, on a plus rien (je considère que suivre le truc de loin n'est pas viable).

Ceci dit,pour répondre a certains points :

Là ça me fait un peu tiquer. J'en viens a me demander si l'argument en question contre un framework ce n'est pas plutôt "Je ne sais pas overrider proprement un Framework". Les Frameworks css sont aujourd'hui assez découpé pour te permettre d'overrider un composant sans avoir besoin de coller des ! important.

Dans la logique des choses, techniquement, tu prends un Framework et tu commences déjà par lui filer tes couleurs principales, et il ne te reste qu'a modifier le style de chaque composant spécifique (dropdown, fil d'ariane, etc). Une fois ceci fait, tu rajoute justes quelques classes spécifiques et tout est prêt et fonctionnel. L'avantage étant que tu n'a fais que modifier les composant et donc, le reste marchera toujours (tu évites donc une grosse partie de bugs). Donc le mec qui regarde le code et connait le Framework, retrouve ses petits et sait juste que tel élément du framework est maintenant stylisé différemment.

Aussi je pense que la charge de migration vers un FrameWork sera toujours peu élevée (et rentabilisée largement par la suite) que de devoir normaliser, documenter le code actuel pour qu'il se colle aux standards connus.

Pour moi (comme je l'ai dis je ne sais plus ou), on développe ZdS certes, mais le projet ZdS peut très bien prétendre à une utilisation ailleurs que sur "zestedesavoir.com". J'insiste beaucoup sur une logique Framework Css et sur tout ce qui est flexibilité, évolutivité et parametrable à souhait.

Le front-end actuellement est pensé pour ne s'appliquer qu'au site zestedesavoir.com, ce qui n'est pas mauvais aujourd'hui mais ce n'est pas ce vers quoi on devrait tendre selon moi. On devrait tendre vers une solution qui offre assez de généricité pour que "zestedesavoir.com" tel qu'on le voit aujourd'hui ne soit qu'une implémentation de l'outil zds. Le site dans l'état actuel est très bien reproductible avec un système de grille par exemple, car les grilles sont génériques.

Si je prend le cas de la page d’accueil telle qu'elle se profile actuellement par exemple. Elle pars sur 3 colonnes. Si demain on a un autre site qui utilise ZdS pour disons présenter deux fils sur sa page d’accueil (des tutos et des sujets chaud), le design s'adaptera t-il ? sur toutes les plateformes ? Je n'en sais rien, mais comme c'est parti, on risque encore d'avoir du développement très spécifique là dessus.

En résumé, je ne vois pas l’intérêt de faire du spécifique (Framework maison) quand on sait qu'on peut faire du très générique (Framework connu et éprouvé) et ça constituerait un bon argument pour proposer ZdS à d'autre plateformes qui pourrait ainsi utiliser notre code sans toutefois que leur site ressemble exactement au notre.

Le site dans l'état actuel est très bien reproductible avec un système de grille par exemple, car les grilles sont génériques.

Non. On a déjà expliqué au moins 2 ou 3 fois pourquoi.

Vu l'orientation des idées, je vais donc designer et développer la page d'accueil et me retirer du projet. Les idées diffèrent, certains dev sont prêts à reprendre la chose si framework il y a, firm1 annonce que c'est rapide et simple à faire. Je n'aime pas les framework front pour des tas de raisons explicitées précedement. Je ne prendrais pas le risque de faire le portage.

Vu que l'idée d'un framework a l'air de revenir sans arrêt, ça finira par passer dessus. Je ne terminerais pas la documentation du front actuel. Je ferais le strict minimum pour que ce soit utilisable : c'est de toute façon voué à disparaître puisque trop spécifique et que ça ne plait pas.

En guise d'exemple ultime : Twitter n'utilise pas Bootstrap. Ironique non ? Pourtant ça semble être une solution miracle de flexibilité et de maintenabilité selon quelques-un d'entre vous. Pourquoi leur site, basé sur une grille n'utilise-t-il pas un outil qu'ils ont eux-même développé ? Je vous laisse y réfléchir et peut-être qu'en relisant les arguments avancés par certains ici vous comprendrez qu'un framework n'est pas du tout une garantie de flexibilité.

Cordialement, la direction.

Alex-D : je suis globalement d'accord avec toi sur l'utilisation d'un framework. J'utilise très régulièrement Boootstrap et Foundation pour des projets persos et il a fallut mettre les mains de la cambouis un jour pour apprendre à les utiliser. Sauf que eux avaient une doc très bien faite et détaillée.

Si tu veux qu'un continue à utiliser ton framework (et je suis à 200% pour) termine la doc comme il se doit et fait en sorte de répondre aux exigences des autres dev (je pense notamment au système de colonnes qui pour moi est indispensable).

Je trouve néanmoins ta réaction assez puérile.

De manière générale un framework maison sans documentation sur un projet à vocation opensource, c'est raté d'avance.

Alex, on a pas dit que le framework actuel ne plaît pas (pour ma part, je le trouve plutôt cohérent et clairement optimisé si on regarde aux performences versus Bootstrap ou Foundation), on songe juste au moment où, pour une raison X ou Y, le petit noyau qui maîtrise ce framework ne sera plus en mesure de le maintenir ou de le faire évoluer. C'est pas la même chose

On a déjà montré que changer de Framework ne changerait rien, et on a déjà proposé des solutions, qu'on allait mettre en place, à savoir:

• Réorganisation / séparation des fichiers, pour simplifier et clarifier le tout
• Co-écriture avec un dev back d'une doc plus complète
• Renommage de classes, pour rendre le code plus "conventionnel"
• Formation de quelques contributeurs "actuels" (j'entend par la, devs back qui connaissent un minimum d'HTML/CSS) au front

Le truc, c'est qu'on a déjà proposé ces choses, et certains continuent à nous proposer une solution que l'on veut presque à tout prix éviter… Si vous tenez à vous débarrasser le plus vite possible (je sais que c'est pas ce que vous voulez faire, du moins je l'espère…) de vos uniques devs front, vous êtes bien parti…

Dans les derniers messages, j'avais l'impression que le FW maison (j'aime pas trop l'appeler comme ça, mais soit.), couplé aux efforts qu'on était prêt à faire côté front était la solution qui convenais… Mais j'ai réellement le sentiment que certains tiennent à aller dans le sens inverse de ce que l'on souhaiterais, surtout dans un domaine qui, pour le moment, concerne essentiellement Alex et moi-même… Même SpaceFox disait que le framework n'était qu'une idée sur laquelle il exprimait des réserves…

J'ai franchement du mal à comprendre comment certains envisagent encore l'utilisation d'un framework, alors qu'Alex et moi-même sommes franchement contre, et que l'on propose, selon moi, suffisamment de solutions pour régler le problème d'accessibilité du front… Après, c'est clair que ça ne règle pas le problème de "c'est qui qui va s'en occuper", mais la, de notre côté, on fait tout pour qu'il y ai quelqu'un…

Et à court terme, ce quelqu'un risque d'être moi… Je dis ça parce que personne n'a, à l'heure actuelle, l'air motivé pour toucher ne serais-ce qu'un peu au front, et que je suis prêt, comme dit dans mes messages précédents, à m'investir plus. Mais honnêtement, si l'on choisi d'utiliser un framework, je n'aiderais pas a faire la transition, ne serais-ce que par respect pour le travail d'Alex. Ce n'est pas du chantage, mais si vous estimez que l'on peut facilement switcher sur un FW, faites le, et trouvez ces contributeurs que vous rêvez tant, et qui tomberont du ciel à partir du moment où vous intégrerez un framework…

Sandhose

Personnellement, je veux bien faire partie du "back qui aide à la doc".

On ignore pas l'énorme travail fourni jusque là, et c'est l'occasion de vous remercier encore une fois de l'avoir fait. Je ne crois pas qu'il ait été fait mention de mettre le CSS actuel à la poubelle et de partir sur un Bootstrap neuf. Non. Simplement la faisabilité de se baser sur certains éléments de frameworks connus et reconnus (comme le système de grille hyper modulable, pour ne citer que lui) tout en conservant toit le travail fourni jusque là.

Concernant une grille "maison", je crains que chaque sortie du nouveau Google truc ou iMachin engendre une QA approfondie sur le rendu du site. Rien que pour ça, reporter le travail sur la communauté Bootstrap ou Foundation me semble une valeur ajoutée (bien assez de la QA pour vérifier la compatibilité de notre CSS sur lesdits devices).