Il me semble toujours que Feuille de Route et Manuel de Rédaction du site sont très proches, chacun ayant des avantages. Cela vaudrait peut être une fusion ou une réflexon au moins pour les rapprocher.
Avantages de feuille de route :
L’information n’est pas stockée dans un article et il n’y a donc pas à le retirer du flux
Accessible et modifiable côté publique
Avantages de Manuel de rédaction du site
Dans le privé, peut s’afficher dans la page tout en gardant l’accès à celle-ci
Modifiable directement dans le privé
Ce qui manque peut être dans les deux :
Une configuration simple des autorisations : qui peut lire ? qui peut modifier ? (à ce sujet, le plugin tickets fournit un bon exemple de configuration des autorisations, par statut ou par liste d’auteurs).
salut,
plus je réfléchi et plus je me dis qu’il n’est pas utile de les fusionner, je vois pas pourquoi on devrait avoir le manuel sous la main si on veut juste une feuille de route, ça me semble aller dans le sens contraire au mouvement de dégraissage…
Pour un rapprochement… ? qu’est-ce que ça pourrait être ?
Pour le manque de configuration simple des autorisations je suis bien d’accord, et je vais regarder de près le plugin tickets.
Pour la feuille de route aussi, je me demande si le fichier IMG/feuillederoute.php ne devrait pas être supprimé quand on désactive le plugin… ? quelle serait la bonne pratique ?
Le 19 février 2013 02:10, chankalan <chankalan@free.fr> a écrit :
Pour la feuille de route aussi, je me demande si le fichier
IMG/feuillederoute.php ne devrait pas être supprimé quand on désactive le
plugin... ? quelle serait la bonne pratique ?
Non pas à la désactivation.
Mais devrait être supprimé à la désinstallation.
Le plugin manuel du site est surtout inintéressant pour le listage des faq des autres plugin que l’on réalise :
ce que ne fait pas feuille de route à priori.
salut,
merci d’expliquer un peu…
en fait l’un ne remplace pas l’autre, la question n’est pas là, ils se complètent, ou en tout cas ne remplissent pas les mêmes usages, mais est-ce qu’on les met ensemble dans le même paquet ?
salut,
merci d’expliquer un peu…
en fait l’un ne remplace pas l’autre, la question n’est pas là, ils se complètent, ou en tout cas ne remplissent pas les mêmes usages, mais est-ce qu’on les met ensemble dans le même paquet ?
Excuse j’ai été un peu bref au réveil, même pas dit bonjour en plus ^^.
je viens de tester feuille de route que je n’avais pas encore eut le temps de regarder : c’est un outil de développement qui est simple pour le moment mais qui a toute sa raison d’être et qui pourrais je trouve évoluer car il répond a un besoin et pourrais être agrémenté d’autres fonctionnalités : pourquoi veut tu le fusionner ou le mettre dans un autre paquet ?
il pourrait servir d’interface de jonction avec Ticket (que je n’utilise pas) ou un outil de suivi de bug et permettre un édition en front plus simple qu’un outil de ticket (j’ai cru comprendre que c’était un souhait récurent d’utilisateurs un formulaire simple de dépose de ticket de Bug ) , mais peut-être que le souhait est-il que le plugin reste simple et sans autres ajouts ??
Le plugin manuel du site est surtout inintéressant pour le listage des faq des autres plugin que l’on réalise :
ce que ne fait pas feuille de route à priori.
thunderbird a corrigé a l’insu de mon plein gré : il fallait comprendre : le plus in manuel site est surtout intéressant (le contraire quoi)
je reprends mes propos : je suis plutôt d’accord, il n’est pas nécessaire de fusionner les deux plugins…
j’aime bien la sobriété de feuille de route, j’aimerais qu’on puisse la garder, et même en ajouter car la présence de la feuille en partie privée n’est pas forcément utile, je suis prêt à retirer le bouton privé… qu’en dites-vous ?
mais ajouter des réglages d’autorisations me semble une souplesse utile
– les tickets
dans une première approche de la fonction « feuille de route » j’ai tenté d’utiliser les tickets et de les gérer dans une boîte modale, de la même manière, mais j’ai vite trouvé que c’était au-dessus de mes besoins
mais si c’est nécessaire, les tickets ont déjà des squelettes publics, il faut peut-être réfléchir à un bouton d’édition dans une boîte modale ? pour les gérer en même temps et dans la même fenêtre que le parcours du site public… (mais actuellement on peut très bien ouvrir deux onglets dans son navigateur, un pour parcourir le site, l’autre avec les tickets…)
Ils sont très similaires. Cela ne signifie pas qu’il faille les fusionner ou les mettre dans le même paquet.
Par contre, il a moyen de faire évoluer Feuille de Route.
Tous deux ont pour vocation à fournir un texte modifiable, accessible depuis le public et/ou le privé, et hors du flux éditorial.
Ensuite, la question de savoir ce qu’on y met dans ce texte est fonction du besoin de chacun. Ce qui différenciera ces différents besoins c’est notamment qui peut lire et qui peut modifier. Car la distinction public/privé n’est pas forcément pertinente. L’éditorial se fait à la fois dans le privé et le public avec les crayons. Le développement du site se fait aussi des deux côtés.
En résumé, en faisant évoluer Feuille de Route de la manière suivante :
Meilleure interface dans le privé (reprise du celle du public, inspiration de Manuel de Rédaction) qui permet d’avoir accès à l’info tout en gardant l’accès à la page en cours.
Configuration pour dire qui peut lire et qui peut modifier (et éventuellement si affichae privé/public/les deux)
Pas certain qu’il soit nécessaire de reprendre les autres éléments de config de Manuel du site pour éviter d’alourdir la configuration
il sera suffisament générique pour être utilisé en fonction des besoins de chacun, que l’on souhaite une liste de tâches, des notes de développement, des règles éditoriales etc.
On peut même envisager l’utiliser pour des notes de développement en phase de mise en place qui seront transformées en notes éditoriales en phase de production, avec éventuellement un réglage différent concernant qui peut lire et écrire entre ces deux phases
oui c’est sur : ça peut perturber certains : de plus sur certains sites tout se passe entre admin pour la conception du site et les rédacteur ne sont pas concernés par le coté « technique ». - autant on peut aussi considérer un cas ou tous le monde peut lire, mais que seul le webmestre ou admins pourraient éditer. A++ Arnaud B.
Je comprends mieux…
qu’en privé la feuille de route soit plus comme le manuel du site, pourquoi pas, pour utiliser la feuille comme le manuel…
Est-ce qu’il faudrait dissocier l’usage de la fonctionnalité, pour utiliser ce texte comme on veut, une feuille de route ou un manuel, ou un post-it si on veut l’appeler comme ça… ?
Peut-être faudrait-il pouvoir créer un texte à chaque besoin, et décider d’un bouton en privé et/ou public et des autorisations qu’on veut pour chacun…
Ce serait une API de création et d’édition de texte hors publication ?
je dis ça mais je sais même pas si c’est réalisable…
Le 19 février 2013 11:43, chankalan <chankalan@free.fr> a écrit :
Ce serait une API de création et d'édition de texte hors publication ?
je dis ça mais je sais même pas si c'est réalisable..
A minima, on gère un seul texte. Auquel cas, c'est peu de modif sur la
version actuelle (à savoir appliquer dans le privé, la même surimpression
que celle utilisée dans le public) et ajouter les deux fonctions
d'autorisation.
Et ça reste simple.
Gérer deux ou trois feuilles différentes max, complique un peu les choses
mais ça reste jouable. Mais est-ce vraiment utile ?
Gérer un nombre non connu de feuilles complique sérieusement le bousin.
Il me semble que la première option (juste une seule feuille) est largement
suffisante en premier lieu.
Le 19 février 2013 11:43, chankalan <chankalan@free.fr> a écrit :
qu'en privé la feuille de route soit plus comme le manuel du site,
pourquoi pas, pour utiliser la feuille comme le manuel...
Est-ce qu'il faudrait dissocier l'usage de la fonctionnalité, pour
utiliser ce texte comme on veut, une feuille de route ou un manuel, ou un
post-it si on veut l'appeler comme ça... ?
Ben pas forcément. Même si je l'utilise comme une séries de note de dev,
j'en ai besoin autant dans le privé que dans le public. Car je passe par
les deux interfaces lorsque je créé un site.
Il n'y a pas de raison de proposer uen fonctionnalité différente selon
espace public ou privé.
