Revenir à l'accueil

Marques-pages internes d'articles

Publié le 27 du 08 2018

Il m’arrive très souvent de trouver que “le web” est assez mal utilisé en règle général. Par exemple, je trouve ça vraiment triste que les articles “en ligne” de journaux n’exploitent pas la notion de “documents riches” pour présenter leurs articles. Pourtant, il existe beaucoup de projets intéressants (comme The Gamma ou The pudding) qui démontrent l’intérêt des documents riches.

Pourtant, malgré mon dépit, mon blog n’est pas vraiment un exemple d’interactivité ! Dans cet article, je vous propose de découvrir l’implémentation d’une fonctionnalité qui fait directement écho à ma dernière publication !

Cet article est dans un format très différent de ce que j’ai pu rédiger auparavant, il présente une fonctionnalité liée “à ce blog”. Les motivations sous-jacentes, les inspirations et quelques commentaires divers et variés !

Après la publication de mon dernier article, en plus des retours orthographiques, beaucoup de personnes m’ont fait remarquer qu’il était fort long. Que j’aurais peut être dû le fragmenter en plusieurs parties. Maintenant qu’il est publié, je trouvais ça un peu dommage de le découper, d’autant plus que mon objectif était de fournir une base “théorique” pour d’éventuels articles futurs. Un autre retour récurrent portait sur l’absence de playground pour observer le comportement du code. Ce n’est, hélas, pas (pour le moment) la thématique de l’article

Un ami, Mehdi, m’a très justement fait la réflexion que, pour être consommé dans son entièreté, il fallait prendre facilement plus d’une heure. Donc que la fragmentation de l’article aurait permis de rapidement “reprendre la lecture” là où on l’aurait laissé. Bref, d’utiliser la découpe en plusieurs pages comme manière de découper sa lecture.

L’objectif de cet article est de présenter une fonctionnalité que j’ai implémenté (tout en écrivant cet article) pour permettre de rendre la reprise de lecture plus facile et de motiver certains choix lié aux fonctionnalités ajoutées !

La fonctionnalité est déjà observable “en haut à gauche” de l’article. Il est composé d’une jauge qui indique la progression de la lecture et quand “on revient sur un article”, un bouton “Reprendre la lecture” apparait pour renvoyer à la dernière rubrique que l’utilisateur à entâmée.

Sur le choix de Hakyll

Initialement, pour garder un contrôle total sur ce que je pouvais développer, j’ai décidé d’implémenter, à la main, tout mon système de publication. Comme souvent quand je travaille sur un projet personnel, j’ai tâché de faire quelque chose de très générique, qui pouvait faire tout ce à quoi je pensais (et potentiellement extensible à gogo). Le projet, qui devait être un simple générateur de blog statiques est devenu titanesque, à tel point que 3 mois après avoir démarré le développement, je n’avais toujours rien d’utilisable ! (Logique.)

En suivant les conseils de plusieurs personnes, j’ai décidé d’utiliser temporairement (aha) une solution déjà existante pour démarrer l’exercice de rédaction. J’ai choisi Hakyll, parce qu’en plus d’être développé en Haskell (qui est un langage que j’aime quand même bien), il était présenté comme très flexible. En effet, Hakyll n’est pas un générateur de blogs statiques, mais un générateur de générateur de blogs statiques ! En plus, comme Hakyll utilise Pandoc pour générer les documents HTML, je pouvais facilement choisir un langage de markup suffisament expressif pour écrire tout ce que je voulais.

Je ne regrette absolument pas mon choix, à tel point que pour le moment, il n’est pas question de migrer mon blog vers une solution artisanale. Cependant, je n’ai pas oublié mes envies de “construction de documents riches”, et comme Hakyll est très flexible, je peux facilement ajouter des fonctionnalités pour améliorer la navigation.

Une lecture resumable (que l’on peut reprendre)

Nos navigateurs nous permettent facilement de sauvegarder des pages via les marques-pages. Cependant, comme lorsque l’on utilise un marque-pages pour un livre, ces derniers ne sauvegardent “que” la page. Bien qu’il soit possible de ruser avec des ancres, l’objectif d’un marque-pages est de pouvoir facilement revenir sur une page spécifique.

Les marques-pages du navigateur ne solutionnent pas le problème des articles trop longs. De plus, généralement, on édite rarement un marque-pages.

S’inspirer de Netflix

J’ai un avis assez mitigé sur l’expérience utilisateur de Netflix. Il y a certaines choses que je trouve vraiment géniales, d’autres que je trouve contre-intuitives à souhait.

La fonctionnalité que je trouve vraiment excellent, c’est la possibilité de reprendre une vidéo en cours. Je la trouve terriblement pratique. L’objectif de l’amélioration ergonomique que je souhaite mettre en place sur mon blog est un instrument un peu similaire à cette fonctionnalité de Netflix, la possibilité de reprendre un article là où on l’aurait laissé !

Évidemment, il y aurait quelques différences avec la solution implémentée dans le player de Netflix, pour des raisons de supports. Il est évident qu’un article propose n’est pas identique à une vidéo. En effet, alors qu’un timecode est absolument objectif, la position de la page est relatif à plusieurs paramètres (par exemple, le coefficient de zoom de la page, ou la taille horizontale de la fenêtre de navigation).

Implémentation concrète

L’idée générale de l’extension est sauvegarder, dans LocalStorage une information liée à l’article en cours de lecture. On défini un article, dans LocalStorage via une clé unique construite sur base de l’URL de la page.

La première approche, un peu naïve, que j’ai mis en oeuvre pour cette extension était de stocker à chaque action de défilement, l’offset de la page. Soit le nombre de pixel défilé en hauteur. Cette approche fonctionne dans le meilleur des mondes. En effet, si entre la première session de lecture et la seconde, on modifie la largeur de la page, ou encore que l’article est édité, la “reprise” de la lecture risquerait d’envoyer vers une position assez aléatoire.

Après quelques expérimentations (par exemple, en utilisant un pourcentage de progression), j’ai décidé que j’allais utiliser les “titres de paragraphes” comme “étapes” de lecture.

Concrètement, a chaque fois que je fais défiler la page :

L’avantage de cette approche, est que la reprise de lecture ramène à la rubrique que le visiteur était en train de lire. Contrairement à une vidéo, il arrive parfois dans un article que la remise en contexte soit un peu plus compliqué. De ce fait, rédiriger vers la section que l’utilisateur était en train de lire permet de facilement recontextualiser la lecture “en cours de reprise”.

Choix liés à l’ergonomie

J’ai essayé au maximum d’éviter de tomber dans le piège “de vouloir automatiser” un maximum de chose. De ce fait, la reprise de la lecture est une action ponctuelle déclenchée par le lecteur. En effet, j’ai l’intime conviction que le fait d’automatiser la reprise de la lecture aurait pût être perturbant !

De plus, le bouton “reprendre la lecture” ne change pas de “cible” en cours de lecture, il est initialisé avec une “étape fixe”, celle définie au moment où l’on arrive sur l’article. L’objectif de cette “approche” est de permettre de reprendre la lecture à l’endroit où on l’avait laissé, même si le lecteur a re-navigué dans l’article.

Ajouts complémentaires

En plus de sauvegarder la dernière rubrique de l’article parcourue par le lecteur, j’ai ajouté une jauge de progression pour rapidement évaluer le temps nécéssaire à la lecture. Cette fonctionnalité est un peu gadget mais je trouve qu’elle permet, en plus, d’avoir un feedback très rapide sur le fait que le bouton “reprendre la lecture” déplace réellement dans le contenu de l’article.

Conclusion

Concrètement, cet article ne présente pas grand chose de très intéressant. Il s’agit juste d’un ajout destiné à faciliter la consommation de “grands” articles pour ce blog ! Les idées que j’ai souhaité véhiculer, en plus de décrire une fonctionnalité, sont :

Pas plus tard que ce matin, Robin me faisait remarquer que j’aurais peut-être dû utiliser Medium pour les avantages que la plateforme offre (la communauté, le référencement, l’ergonomie de rédaction). Personnellement, je trouve que Hakyll me permet de rédiger dans un workflow qui me convient, d’intégrer facilement du code, et d’ajouter des widgets pour tenter d’améliorer l’expérience utilisateur. C’est pour ces raisons que je n’utiliserai pas Medium pour ma page personnelle.

Travaux futurs

Comme pour cet ajout, je tâcherai d’implémenter de nouveaux widgets pertinents en fonction d’articles que je serai amené à écrire. Par exemple, des outils pour la visualisation de données ou des bac à sables interactifs pour la diffusion de code source.

Mon but n’est pas d’implémenter tout ce qui me semble utile, mais de tâcher d’être chaque fois motivé par un article, histoire de ne pas tomber dans l’over-engineering en voulant intégrer tout l’espace dans mon blog ! Ici, cette fonctionnalité répond à la longueur de l’article sur les monades.

Si vous avez des suggestions ou des remarques, n’hésitez pas à m’en faire part via les multiples moyens de me contacter ! A bientôt.

Cet article est terminé !
Si jamais vous avez des remarques, n'hésitez pas à écrire un commentaire ou à contribuer