motercalo Modification versus publication - www.yacs.fr

Skip to main content Help Control Panel

 

Communauté «   Développement «   Suggestions de fonctions «   Notifications, emails, newsletters «  

Modification versus publication

3
votes
Rate it
Améliorer la publication judicieuse des modifications...

Actuellement, chaque modification d'une page génère l'enregistrement d'une nouvelle version qui se retrouve en tête des listes présentant les dernières publications et des envois de mails aux personnes surveillant la page.

Or, si l'on a juste retouché une virgule, c'est gênant de mettre en première ligne la page retouchée alors qu'elle n'a pas vraiment évolué (et de déranger inutilement les "surveillants" de la page).

Pour éviter cela, au moment d'enregistrer la page, l'éditeur peut cocher la case "Ne pas enregistrer la date de modification". Dans ce cas, la page est considérée comme n'ayant pas été modifiée.

Mais dans ce cas, la date et heure de l'intervention de l'éditeur n'est pas mémorisée, ni son surnom. Je trouve cette "perte" d'information gênante car la date de dernière mise à jour donne une indication importante sur la fraîcheur des infos qu'elle contient.
Et la citation de l'éditeur comme dernière personne ayant retouché la page est également une marque de respect pour son travail.

Pour pouvoir mémoriser correctement les modifications de la page sans générer des affichages et des mails inutiles, je suggère de dissocier la notion de modification de la notion de publication (de présentation au public).

Toute modification serait systématiquement mémorisée dans la table. Par contre, seules les publications seraient remontées dans les listes des dernières publications et via les mail de surveillance.

Concretement, lorsque l'éditeur juge que les modifications sont significatives et qu'il s'agit d'une nouvelle version majeure de la page alors il lui suffit de re-publier celle-ci.

Dans les listes de dernières publications et pour les mailings informant les "surveillants", seules les publications et re-publications seraient prises en compte.
Les simples modifications seraient uniquement remontées aux propriétaires et éditeurs de la page.

Concrètement, il faudrait que le lien "publier" reste présent sur les pages déjà publiées afin de permettre de les re-publier.
Une case à cocher "Publier de nouveau" pourrait également venir remplacer la "Ne pas enregistrer la date de modification" devenue inutile.

 

Comments

J.Juraver - on Feb. 28

Je suis assez d'accord sur le principe.

Il y a en outre la notion de versioning qui peut s'avérer importante, lorsqu'il y a notifiation d'une modification, qu'il ne faut pas perdre : je pense par exemple à un mode wiki, où l'on aime à comparer différentes versions d'une page, ce que yacs sait très bien faire mais le réservé aux éditeurs de section.

Il serait utile d'ouvrir cette fonctionnalité de visualisation de type "merge" lorsqu'on se trouve dans un wiki yacs, et là en revanche on conserverait les notifications de modification. Idéalement, on peut, comme la plupart des moteurs de wiki, imaginer de caractériser une modification comme mineure ou majeure, auquel cas les notifications seraient étagées en conséquence.



Je ne m'attarde pas, j'ai mon yacs en double file...
Yacs.tel Yacs.pro Wikipedyacs
Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Click to slide Suggestions les plus plébiscitées

Bernard Paques - on Mar. 2

Cette discussion est à la fois intéressante et importante. Intéressante, parce qu'elle est susceptible d'apporter de nouvelles bonnes idées pour améliorer l'interface de yacs, et pour maîtriser le flot des notifications. Importante, parce qu'il faut trouver une formulation à la fois puissante et simple à comprendre, et éviter le syndrôme de l'usine à gaz.

A mon avis, même la publication à répétition est trop compliquée pour la plupart des utilisateurs. Ce que nous pourrions rajouter à l'interface, tout simplement, c'est une case à cocher pour signaler les modifications mineures, qui ne justifient pas l'envoi de notifications, ni la création d'une version séparée de la page.

Si la case n'est pas cochée, le comportement serait le même qu'aujourd'hui.

Si la case est cochée, toutes les opérations habituelles s'appliquent, sauf les notifications et la création d'une version.

Dans les deux cas, la date d'édition serait mise à jour. S'il faut préserver l'ordre des pages malgré ces changements, une possibilité est d'utiliser l'option articles_by_publication pour trier les pages par date de publication, et non par date de modification.

 


Jmarc - on Mar. 2

Bernard : l'option articles_by_publication (que je ne connaissais pas) est parfaite pour solutionner le probleme d'affichage en tête de liste à chaque modification !

Par contre, si l'on souhaite refaire passer en tête de liste un article profondément modifié pour inciter les visiteurs a aller le relire, il faudrait pouvoir modifier sa date de publication (ou mieux, cliquer sur un lien pour la re-publier).

Ta proposition de case à cocher pour signaler les modifications mineures (et éviter les notifications intempestives) me va tout à fait

Dans mon cas, je dirais qu'il faut qu'elle soit cochée par défaut (toute modification est considérée comme mineure sauf si l'éditeur précise que c'est une modification majeure en décochant la case).

Mais idéalement, il faudrait que chaque webmaster puisse choisir au niveau du site si, par défaut, cette case doit être cochée ou décochée.


Alain Lesage - on Mar. 6

J'aime bien la solution à laquelle on semble en arriver. En complément avec la non-notification des brouillons, ca va régler un truc qui m'agaçait depuis un bout de temps.

Tout comme Jmarc, j'apprécierais que la case soit cochée par défaut (a priori, j'aurais carrément inversé la logique de la case suggérée par Bernard, et considéré toute modification comme "mineure", à moins que la case soit cochée). Après tout, une fois la page publiée, les modifcations ne sont-elles pas généralement mineures ?

La sugestion de laisser le choix au webmestre offre le meilleur des deux mondes, mais a l'inconvénient de complexifier encore un peu plus le panneau de contrôle.

Quant à la possibilité de republier si on veut changer l'ordre d'affichage avec l'option articles_by_publication, ne peut-on pas simplement utiliser la fonction "dater" pour modifier la date de publication ?


J.Juraver - on Apr. 9

Que fait-on avec cette suggestion d'amélioration ? Est-elle envisagée pour yacs martin final ou pour plus tard ?



Je ne m'attarde pas, j'ai mon yacs en double file...
Yacs.tel Yacs.pro Wikipedyacs
Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Click to slide Suggestions les plus plébiscitées

Download yacs