Bonjour, je m'appelle Dmitry Karlovsky et j'ai des nouvelles pour vous. Eh bien, comme nouvelles, un nouveau regard sur la chose habituelle sous la forme d'un autre article. Vous y accéderez probablement à partir de n'importe quel fil d'actualités. Ou vous ne l'obtiendrez pas si les nouvelles sont publiées au mauvais moment. Peu importe à quel point cet article vous intéresse.

La chose est de savoir comment les bandes sont formées et comment l'utilisateur interagit avec elles. Et ici, malheureusement, comme d'habitude, la solution la plus simple est extrêmement mauvaise. Voyons pourquoi.

Méthodes de consommation

Supposons qu'un utilisateur nous demande une liste de certaines entités. La façon dont l'utilisateur verra ces entités dépend de ses objectifs. Il y a deux façons de consommer:

1. Recherche active. L'utilisateur recherche quelque chose de spécifique. Il applique un filtrage et un tri pour réduire la sortie, après quoi il numérise séquentiellement les matériaux, vérifiant chacun d'eux. Il est important que la liste que vous consultez ne change pas pendant le processus de visualisation, sinon vous pouvez facilement ignorer ce que vous recherchez.

   
   

2. Recherche passive. L'utilisateur ne recherche rien de spécifique. Au contraire, il veut que le service examine ce que ce service a et affiche à l'utilisateur quelque chose qui l'intéressera. Ici, il est juste important de montrer à l'utilisateur les matériaux les plus pertinents à l'heure actuelle pour un utilisateur particulier. Et ce qu'il a déjà vu n'est pas du tout à montrer.

   
   

Ainsi, les fils de nouvelles sont conçus uniquement pour la consommation passive de ces mêmes nouvelles. Oui, l'utilisateur peut limiter la gamme des intérêts à l'aide de filtres, mais il ne recherche pas de nouvelles spécifiques, car il ne le sait probablement pas encore et est allé dans le flux pour en savoir plus. Et sa satisfaction dépend du nombre de documents plus intéressants (pertinents) qu'il voit et du nombre de documents inintéressants qu'il voit.

Critères de pertinence

De nombreux facteurs peuvent influencer la pertinence. Par exemple, la modification de la priorité d'une tâche qui vous est affectée dans le gestionnaire de tâches est une nouvelle très importante, qui doit être montrée à l'utilisateur dès que possible. Même si après cela, il y avait des commentaires d'une douzaine d'autres tâches.

Mais il existe des critères généraux, tels que:

1. Visibilité. Si l'utilisateur a déjà vu cette nouvelle et y a réagi d'une manière ou d'une autre (défilé, supprimé, marqué comme lu, est allé dans les détails, etc.), la deuxième fois, il ne veut pas la voir.
2. Pertinence. Certaines nouvelles perdent leur pertinence avec l'avènement de nouvelles plus récentes sur le même sujet. Par exemple, d'après les informations sur le changement de statut de la tâche, seule la dernière est intéressante, reflétant l'état actuel.
3. Date Les nouvelles fraîches sont souvent plus intéressantes. Et certaines vieilles nouvelles ne sont plus si intéressantes qu'il vaut mieux ne pas les montrer du tout (par exemple, les nouvelles que l'eau chaude a été coupée il y a un jour).

Rubans dans la faune

Dans la grande majorité des cas, les fils de nouvelles sont constitués par la publication de documents triés par date de création, de publication ou de modification. Autrement dit, les autres critères de pertinence (plus importants) ne sont tout simplement pas pris en compte. En fin de compte, cela conduit à l'insatisfaction des utilisateurs. Quelques exemples pour illustrer:

Flux VKontakte

L'utilisateur ouvre les actualités pour la première fois et les affiche de manière séquentielle - tout va bien ici. Après un certain temps, une notification apparaît en haut que quelques nouvelles récentes sont apparues. Et puis il a un choix délicat:

1. Continuez à parcourir le flux
2. Rembobinez le fil au début pour voir les dernières nouvelles (ce qui n'est pas un fait plus pertinent).

Étant donné que la bande est quasi-infinie, et l'onglet du navigateur ne peut pas vivre éternellement, et personne n'a annulé la curiosité. Tôt ou tard, l'utilisateur sera de nouveau au "début" de la bande. Ok, faites défiler vers le bas. Rien ne présage des ennuis, quand soudain les nouvelles que l'utilisateur a déjà vues commencent à continuer. Et là encore, l'utilisateur n'est pas un choix délicat:

1. Enrouler rapidement et rapidement la bande, en réduisant le trafic Internet dans le tuyau, en espérant terminer les nouvelles qu'il n'avait pas encore vues.
2. Lecteur sur bande et faites autre chose.

Il s'avère que chaque fois que l'utilisateur n'a pas reçu de nouvelles, il ne les voit jamais. Mais ils pourraient être intéressants pour lui. De plus, ils pourraient être critiques et changer radicalement sa vie.

Ce problème est si typique qu'il est juste de lui donner un nom spécial. Que ce soit le «syndrome de conscience fragmenté».

Accueil Habra

L'OFS est ici aggravé par la pagination. Lors du basculement entre les pages, l'utilisateur voit les actualités de la page précédente. Et s'il s'attarde un peu plus longtemps sur une page, il peut facilement obtenir quelques pages de «massacre» d'affilée. J'ai décrit ce problème plus en détail dans une note sur la Pajinisation .

Youtube

Dans le "recommandé" donnez juste 18 vidéos souvent effrayantes et c'est tout. Pour voir quelque chose de nouveau dans les recommandations, vous devez supprimer manuellement tout ce qui n'a pas suscité d'intérêt. Bien sûr, un utilisateur rare le fera. Dans les "abonnements" - ils trient simplement par date, à cause de laquelle les anciens, mais peut-être intéressants pour les clips utilisateur, ne le verront jamais. A moins qu'il ne tombe sur eux dans le "recommandé".

Racine du problème

Lorsque l'utilisateur a ouvert le flux pour la première fois pour la première fois, il n'a qu'un seul point de réception des nouvelles - immédiatement après la précédente. Il les regarde et soudain, un deuxième point d'entrée apparaît - quelque part au-dessus. Et il est difficile de dire où les nouvelles sont plus pertinentes. Quand, après une pause, il revient, il marque immédiatement au moins deux points: le début de la bande et l'endroit où il a fini de regarder l'actualité la dernière fois. Et puisque en privé l'utilisateur n'a pas la possibilité de regarder les actualités avant d'être visionnées précédemment, ces points de réception des actualités se multiplient et se multiplient.

Solution

Le point de réception des informations pertinentes ne doit être qu'un. Dans le même temps, les informations les plus pertinentes en temps réel devraient y être reçues. Parmi toutes les actualités, on distingue les groupes suivants:

1. Visible. Les nouvelles que nous avions précédemment saisies pour lui et qu'il voit maintenant à l'écran.
2. Vu. News que l'utilisateur a déjà regardé et fait défiler. Lorsque la nouvelle quitte la zone visible, vous pouvez la marquer en toute sécurité comme lue.
3. L'histoire. Une liste de nouvelles générée pour un utilisateur spécifique. Cela inclut à la fois les nouvelles que l'utilisateur a déjà consultées et celles qu'il regarde en ce moment.

Idéalement, même le rechargement de la page ne devrait rien changer à la liste des actualités. Lorsque l'utilisateur demande plus de nouvelles (en cliquant sur le bouton ou en faisant défiler vers le bas), nous sélectionnons une autre partie des nouvelles les plus pertinentes du moment et les mettons dans l'histoire. Ainsi, l'utilisateur a une idée claire de la bande comme étant quelque chose d'intéressant et qui ne change pas. Tout ce qu'il a jamais vu est dans l'ordre dans lequel il l'a vu. Et en se secouant, il obtient constamment quelque chose d'intéressant, sans se soucier que quelque chose va manquer. Certes, il peut être nécessaire de remonter longtemps s'il y a beaucoup de nouvelles.

Pertinence

La chose la plus simple, bien sûr, est simplement de considérer les dernières nouvelles plus pertinentes. Mais vous pouvez laisser l'utilisateur aider le service à comprendre ce qui l'intéresse et ce qui ne l'intéresse pas. Vous pouvez le faire en ajoutant la possibilité de supprimer des nouvelles. Si l'utilisateur ne se contente pas de faire défiler les actualités, mais de les supprimer pour ne pas obstruer son histoire, ce type de nouvelles ne l'intéresse pas et ces informations peuvent être utilisées pour une compilation ultérieure.

API

Puisque notre histoire est reconstituée et vue depuis la fin, nous ne pouvons pas utiliser la pagination traditionnelle, car les informations sauteront alors constamment entre les pages. De plus, la demande de 100 500 pages pour le SGBD peut être trop lourde. Par conséquent, pour l'échantillonnage des données, nous utiliserons des ancres. Pour ce faire, nous indiquerons les données suivantes dans la demande:

1. Ancre L'identifiant de l'actualité à partir de laquelle les données doivent être retournées. Si l'ancre n'est pas spécifiée, la dernière nouvelle lue est prise comme ancre.
2. Décalage. Le nombre de nouvelles à échantillonner. Ce nombre peut être positif, puis les nouvelles reviennent après l'ancre. Ou négatif, puis les nouvelles reviennent à l'ancre.

Si le biais est négatif, mais qu'il n'y a pas de nombre nécessaire de nouvelles avant l'ancre, il renvoie simplement combien il en coûte. Par la différence entre le nombre de ceux demandés et le nombre de visiteurs, le client peut comprendre que nous sommes au début de l'histoire.

Si le biais est positif et qu'il n'y a pas de nombre nécessaire de nouvelles après l'ancre, alors l'histoire est complétée au nombre requis avec les nouvelles les plus pertinentes pour le moment. Si les nouvelles sont complètement terminées, alors encore une fois, nous retournons combien et le client détecte la fin de la bande.

Script de requête

Nous ouvrons la bande, nous n'avons pas encore d'ancrage:

GET /feed?offset=5 

Nous faisons une demande de nouvelles non lues:

 SELECT FROM history WHERE user = 123 AND read_at NOT NULL ORDER BY id ASC limit 5 

L'utilisateur voit une sélection de nouvelles non lues sur lesquelles il s'est arrêté la dernière fois:

 [ { id : 3232 } , { id : 5343 } , { id : 7346 } , { id : 9825 } , { id : 9967 } ] 

L'utilisateur se balance pour voir les nouvelles qu'il a vues la dernière fois:

 GET /feed?anchor=3232&offset=-5 

 SELECT FROM history WHERE user = 123 AND id < 3232 ORDER BY id DESC limit 5 

 [ { id : 323 } , { id : 329 } , { id : 544 } , { id : 843 } , { id : 898 } ] 

L'utilisateur secoue pour voir quelque chose de nouveau:

 GET /feed?anchor=7346&offset=5 

 SELECT FROM history WHERE user = 123 AND id > 7346 ORDER BY id ASC limit 5 

Si vous recevez un peu de nouvelles, nous sélectionnons le nombre nécessaire des plus pertinentes qui sont absentes dans l'histoire et les ajoutons à l'histoire, après quoi nous retournons tout ensemble:

 [ { id : 38574} , { id : 47246} , { id : 52378} , { id : 69238} , { id : 73294} ] 

Réalisations dans la faune

Si vous connaissez des services qui implémentent des flux de cette manière ou d'une manière similaire, je serai heureux de publier des liens vers eux ici afin que les lecteurs puissent apprécier la commodité de cette approche.