Le 21 août 2013 23:04, Dsls <[email protected]> a écrit : > Ou aussi attendre l'avis des autres gens de la ml :)
Peuple de la ML, on vous bâillonne, c'est un déni de démocratie, à bas la dictatuuuure ! :-D Bon sérieusement, avant que chacun ici s'arme de chassepots et se sente obligé de choisir son camp jusqu'au bain de sang final, recadrons cette discussion. Les dév ont nommé cette branche "form-filters" en raison d'un travail technique sous-jacent important sur cet élément, mais la boîte à filtres en elle-même n'est qu'un faible enjeu sur le plan ergonomique. Les demandes de Gautier (ergo) et Laurent (accessibilité) – et du coup les miennes en tant que pilote de la refonte – pour les pages présentant des listes (de billets, de commentaires, de pages, de blogs…) portaient sur les points suivants : * Pouvoir ouvrir et fermer la boîte à filtres. * Ajouter éventuellement des filtres inexistants actuellement (charge à nous d'analyser d'autres critères qui seraient pertinents). * Que les choix de filtres soient maintenus tant que l'utilisateur n'en a pas fait d'autres (idéalement même en cas de déconnexion/reconnexion mais au minimum durant la session. * Permettre la personnalisation d'affichage ou non de telle ou telle colonne d'une liste. * Conserver ce choix de façon permanente, même après déconnexion/reconnexion. * Permettre le tri ascendant/descendant sur l'entête des colonnes. * Indiquer le nombre d'éléments trouvés résultant des filtres choisis C'est en travaillant sur les deux premiers éléments cités ci-dessus que des idées, apportées par les dev et notamment Bruno, ont été acceptées et se sont ajoutées, comme : permettre à un plugin d'ajouter ses propres filtres ; raffiner les filtres avec des critères pouvant être exclus ou multiples, ce qui permettrait des recherches du type : je veux les billets écrits par machin et bidule qui ont des pièces jointes mais ne sont pas dans la catégorie trucmuche (on se rapprochait du coup de la page de recherche des tickets sur le Trac). C'est là aussi qu'ont commencé à être soulevés des problèmes tels que "comment sait-on quand on ajoute un filtre que la liste qui est dessous ne l'a pas encore pris en compte (etc.)". On a fait une foultitude d'allers et retours de mails et de maquettes sur ce point précis pour aboutir à un résultat sinon unanime du moins recevant l'approbation du plus grand nombre et surtout de Gautier. D'après son enquête auprès des utilisateurs, les filtres sont peu employés et plutôt par un public "techno" ou alors de façon très ponctuelle (typiquement : retrouver les commentaires de Machin). Il estimait le tri des listes, le choix des colonnes et leur persévérance d'utilité plus générale, plus impérieuse aussi, mais sans devoir négliger les "technos" pour autant, d'où sa participation active à trouver les réponses aux questions concernant les filtres. Il y a un an et demi ou deux ans, la branche form-filters était en état pas encore très présentable mais "testable" et c'est alors que des problèmes ergo plus embêtants sont apparus : par exemple certains filtres n'étaient actifs qu'à la validation, d'autres se déclenchaient dès qu'ils étaient choisis. De ce dont je peux me rappeler aujourd'hui il me semble que ça n'était pas simple d'unifier les comportements. Certains autres points n'avaient pas encore été implémentés – pour autant qu'il m'en souvienne des discussions se tenaient entre dev sur la façon d'y procéder –, en particulier la "mémorisation" des choix de l'utilisateur pour les colonnes. Pour des raisons familiales, professionnelles ou personnelles des deux dev les plus impliqués (Bruno et Tomtom), les choses sont restées en l'état. Xave avait le désir de s'y atteler et a lui aussi été stoppé dans son élan par un vrai travail qui gagne des sous mais bouffe du temps. Et puis petit à petit tout s'est ralenti sur Dotclear, dont évidemment ce chantier. Pour la 2.6, les contours de la "mission" d'Ève qui nous a rejoints après le coup de Trafalgar du 42 est de nous aider à relancer la refonte ergo en s'occupant notamment de récupérer et corriger le travail fait sur la branche form-filters pour l'intégrer sur la version 2.6 en laissant de côté ce qui serait très complexe à mettre en place en l'état actuel mais qui pourrait plus tard être facilité par l'introduction de Twig et d'un autre chantier cher à Bruno, dcForms. On pourrait ainsi avoir d'ores et déjà des filtres et listes améliorés sans se contraindre à respecter tout le cahier des charges dès la 2.6 (elle-même pouvant progresser au fil des 2.6.x). Tout ça pour dire que cette boîte à filtres qui clignote en orange ou en vert à pois roses, osef un peu en vrai, et en plus on a des maquettes donc on peut commencer par là plutôt que perpétuellement détruire et reconstruire, et en plus c'est pour dans pas maintenant, donc bon. Perso j'arrête sur ce sujet tant que la 2.6 n'est pas sur les rails. Et sinon je trouve que l'idée de fading sur la liste émise par Lipki est bonne, malgré ses quatorze ans ;-) -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
