Opinions sur le classement par date ?

[Alkarex]

Avec la version 0.7 bêta actuelle #327 , les articles sont triés selon la date de leur insertion dans la base de données, plutôt que la date déclarée par le flux.

Ce nouveau classement par date est particulièrement adapté au rafraîchissement automatique (par Cron), et s’accommode des flux utilisant des dates de publications dans le futur, dans le passé, et indéfinies.
Cela permet aussi de facilement implémenter le "marquer tout comme lu" de manière robuste sans risque de toucher des articles ajoutés en arrière plan par le rafraîchissement automatique. Idem pour la future API de synchronisation.

Je pense que c'est assez proche de ce que font certains services en ligne comme Feedly.

Néanmoins, l'affichage résultant n'est peut être pas optimal pour les utilisateurs rafraîchissant rarement leurs flux.

Est-ce qu'il y a des avis ?

Parmi les pistes d'amélioration, voici quelques idées :

• Offrir une possibilité d'utiliser un service Cron Web, par exemple pour ceux sur hébergement mutualisé n'ayant pas la possibilité d'avoir un Cron local. Certains hébergements mutualisés offrent tout de même des Cron, comme OVH.
• Changer l'affichage des articles pour les trier par date déclarée. Il faudrait alors sûrement corriger la date déclarée pour un certains nombre de problèmes (en particulier les dates fortement dans le futur), ce qui ferait perdre l'information originelle. Cela compliquerait un tout petit peu la procédure de "marquer tout comme lu". Il faudrait aussi mettre un index SQL sur e.date.
• Offrir une option pour choisir le type de classement par date.

[AmauryCarrade]

Je pense qu'il faut conserver l'ordre par date de publication et non de réception, sauf dans le cas où la date de publication est indéfinie. C'est plus logique.

Le « marquer tout comme lu » (et ses acolytes “antérieur à x jours”) pourraient quant à eux se baser sur la date de réception, pour éviter de marquer comme lu des flux non reçus avant, ou sur la date de publication, pour éviter une trop grosse différence avec la réalité en cas de mise à jour occasionnelle – ce point en option, active pour ceux qui ont un cron et inactive pour les autres. Je pense personnellement que c'est la meilleure solution. Mais ce n'est que mon avis.

[Alkarex]

Quelques infos de plus.

J'ai oublié de mentionner que la pagination (division des articles provenant de la base de données en plusieurs pages) est simple et rapide dans le cas actuel (date d'insertion dans la base), alors qu'elle est pas mal plus lente et bien plus compliquée un utilisant la date déclarée qui n'est pas unique, entre autres inconvénients.

Un cas extrême pour se représenter le problème principal est lorsque nous avons 10000 articles en base de données, tous avec la même date déclarée. Il faut toujours faire la pagination. Cela se fait par exemple en concaténant la date déclarée à la date d'insertion, pour assurer l'ordre voulu et l'unicité CONCAT(e.date, e.id), mais c'est lent et pas indexable (ou alors il faut créer un autre champ). Il faut aussi plus d'information pour se souvenir de la position dans la pagination (à l'heure actuelle, il suffit de se souvenir du plus petit ou plus grand e.id, selon l'ordre d'affichage choisi).

Autre point : Pour les flux utilisant des dates fortement dans le futur (par exemple des annonces d'événements à venir), ces flux restent alors en tête de liste pendant de potentiellement longues périodes.

Et les flux utilisant des dates dans le passé disparaissent de l'affichage dès qu'ils ont été lus, si on utilise le tri par date déclarée.

Dans le cas d'un tri par ordre d'insertion, combiné à l'utilisation d'un Cron tournant par exemple toutes les heures, la précision du tri est de l'heure. Même des flux grand-public comme Le Monde ont des erreurs de date d'une heure ou plus, et le Cron fait du coup mieux.

[aledeg]

Au lieu de vouloir concaténer les valeurs date et id, tu peux les utiliser directement en faisant un tri sur la première valeur puis sur la seconde, Tu ajoutes un index sur les 2 colonnes dans cet ordre et pour te souvenir de la position, tu utilises l'id qui de toute façon est unique.

[Alkarex]

Cela marche mal lorsque par exemple des articles sont ajoutés par le cron, ou marqués comme lus / non-lus dans une autre fenêtre / autre navigateur / API.
P.S. : le concat était utilisé dans la 0.6 afin de pouvoir avoir un WHERE pas trop compliqué et pas trop lent, mais n'est bien sûr pas souhaitable. Il faut aussi respecter tous les autres filtres de la vue en cours (recherche, lu/non-lu, favoris, etc.). La pagination marchait, mais ne supportait pas les mises à jour par cron ou autres, et était pas mal plus lente que maintenant.

[AmauryCarrade]

Petit retour après essai.
Personnellement, j'ai tendance (actuellement en tout cas) à actualiser mes flux manuellement. Et avec ce nouveau tri, j'ai en gros, dans le flux principal, mes articles classés par flux (voir ici). Pas terrible...

Alors oui, ce nouveau tri peut être intéressant lorsque les flux sont actualisés régulièrement via un cron, mais lorsqu'ils le sont manuellement, franchement je trouve que le tri n'est pas pertinent.

Une option résolverai le problème.

[Alkarex]

Le problème n'est pas tant de faire une option ou pas. C'est plutôt que le tri par date déclarée ne marche pas tel quel quand on regarde dans les détails, et même après correction des problèmes principaux, l'implémentation correcte et robuste du tri par date déclarée/corrigée est difficile et lourde.

Aussi, je cherche des alternatives qui gardent les avantages techniques du tri actuel, tout en limitant le problème décrit par @Bubbendorf.

Voici une suggestion d'une telle alternative :

• Lors d'un rafraîchissement des flux (qui se fait flux par flux, peut-être partiellement en parallèle dans le futur) :
  1. Conserver les nouveaux articles dans une structure temporaire (par exemple une table temporaire en BD, ou un tableau en PHP - risques pour la mémoire -, voire un fichier temporaire sur disque).
  2. Trier ces articles par date déclarée (avec ou sans correction de date, plutôt sans a priori)
  3. Insérer les articles en BD comme nous faisons maintenant, c.a.d. incluant la date d'insertion.
  4. Vider/supprimer la structure temporaire.
• Garder ensuite le tri actuel basé sur la date d'insertion.

Avantages :

• Si tous les flux déclarent leur date (ce qui n'est pas obligatoire), et ce correctement (ce qui est souvent faux), et fournissent comme date la date de parution de l'article (ce qui n'est pas le cas par exemple pour les événements dans le futur), alors le tri est naturel, comme attendu intuitivement, et indépendant de la fréquence de rafraîchissement (cron ou manuel).
• Si certains des flux ne respectent ces attentes, alors cette approche corrige les effets indésirables majeurs (évite par exemple que certains articles avec des dates dans le futur restent en tête de liste).
• Conserve la majorité des avantages techniques du tri actuel.
  • Requiert peu de changements de code

A priori, cela répondrait aux attentes de ceux qui demandent un tri plus proche de la date déclarée (?)

Inconvénients :

• Ajoute une étape intermédiaire avant l'insertion en BD, ce qui accroit légèrement la charge de travail, et augmente les risques d'erreurs.
• Les articles ne sont disponibles qu'à la fin du rafraîchissement complet, plutôt que d'être mis à disposition tout au long du rafraîchissement.

[Alkarex]

Le développement se fera dans un bug dédié #530 et devrait satisfaire les différents besoins exprimés ici.

[Alkarex]

Une implémentation du tri plus naturel est disponible. Tests bienvenus #1470