Les petits pixels...

Et heureusement, le principe de la page de notification est de lister toutes les notifications, pas uniquement celles non lus. Du coup si on triait par date ascendante, on aurait quelques pages à passer avant d’arriver aux récentes (82 dans mon cas).

Je pense que ça mérite un paramètre. Il faudrait réfléchir à la valeur par défaut.

Perso les deux devraient avoir le même ordre (chronologique inverse), étant donné qu’elles affichent le même genre d’infos (filtrées pour le menu).

Et surtout c’est en cohérence avec ce que les autres sites font (Facebook, LinkedIn, etc.) donc facile à comprendre.

+1 viki53, et une option pour ça me semble complètement overkill.

Je rapporte un retour fait dans les commentaires d’un article.

Je ne fais pas de développement d’interface, mais si une personne a des idées pour améliorer ça, qu’elle se manifeste !

Problème des tailles en % il me semble.

Un détail a attiré mon attention : le titre (au sens HTML du terme) quand on édite un tutoriel.

Pourquoi une majuscule à chaque mot ?

Edit : ah oui, j’oubliais le plus important. Quand on édite un tuto ou un article, les liens pour éditer une sous-partie sont super bien placés et parfaitement intégrés… Mais pour éditer l’intro, la conclusion ou l’image associée, le lien Éditer est dans le bloc de gauche et c’est pas super intuitif. Peut-on envisager une lien d’édition additionnel soit tout en haut (au niveau du titre), soit à la même position que celui pour les sous-parties mais au niveau de l’intro ?

suis-je le seul à avoir un problème avec les aperçus ? Ils sont très long à générer ou je dois cliquer plusieurs fois sur le bouton.

Ces derniers temps, j’ai un peu le même ressenti, mais je m’en suis accommodé.

J’ai l’impression que c’est plus le cas pour les longs textes (quand on édite un tuto ou un article, par exemple). Mais c’est assez aléatoire, et j’avais fini par me convaincre que c’était du côté de mon internet que ça se passais. Y’a rien dans la console développeur, en tout cas, donc j’imagine que la requête au serveur zmd est bien réalisée.

Même les textes avec 3 mots prennent beaucoup de temps pour se générer ou je suis obligé de cliquer 20 fois sur le bouton.

il semblerait que pour l’aperçu, il faille un double click. Si quelqu’un a le temps de créer un ticket, ça serait bien.

Par contre ça m’embête, c’est un problème qui est sensé avoir été réglé, faites bien une recherche sur les issues github avant de créer un nouveau ticket, il n’est pas impossible qu’un cas similaire se soit déjà présenté.

Pour faire un aperçu de la citation ci-dessus, un clique à suffit et c’était immédiat. Apparemment, le délai est variable. Il me semble ne jamais avoir eu le soucis avant et c’est récent.

Non, ça fonctionne avec un seul clic. Je doute même que cliquer plus d’une fois serve à quoi que ce soit ou envoie une requête vers le backend, à moins de modifier le texte de l’éditeur.¹

@A-312, j’ai jamais eu le problème, première fois que j’entends ça et je suis très curieux de savoir pourquoi ça se produit chez toi plus souvent que chez d’autres.

Peux-tu tester un truc : avant de cliquer sur Aperçu, place ta souris sur le bouton (il se grise légèrement), attends entre 0.5s et 2s, et click. Vois-tu une différence ?

[EDIT] 2e question importante A-312 : est-ce que tu as constaté ça dès l’arrivée de zmd, ou seulement depuis 2–3 semaines ? Quand on a lancé zmd, on est parti avec 3 serveurs parce qu’autant être large au cas où la charge avait été supérieure à ce qu’on évaluait. Depuis on a scale down à 1 seul serveur. Comme node c’est single-threaded, il se pourrait qu’aux heures de pointe il y ait un délai petit (genre 0.5s) qui rendre l’utilisation pénible.

Alors, j’étais sur mon notebook via Chrome et j’étais en train de rédiger mon tutoriel. Le problème était très prononcé quand j’utilisais mon portable en clé 3G (il avait toutes les barres). Je sais que par expérience utiliser ma connexion via mon portable peut poser des problème avec les requêtes XHR (ajax).

Je doute même que cliquer plus d’une fois serve à quoi que ce soit ou envoie une requête vers le backend, à moins de modifier le texte de l’éditeur.¹

@A-312, j’ai jamais eu le problème, première fois que j’entends ça et je suis très curieux de savoir pourquoi ça se produit chez toi plus souvent que chez d’autres.

Peux-tu tester un truc : avant de cliquer sur Aperçu, place ta souris sur le bouton (il se grise légèrement), attends entre 0.5s et 2s, et click. Vois-tu une différence ?

Les requêtes s’envoyait plusieurs fois quand je cliquais dessus et le bouton ne se grisait pas. Là je suis sur mon PC principale, le bouton aperçu se grise et cliquer plusieurs fois dessus ne change rien.

(Je viens d’essayer avec mon chromebook, je peux lancer 3 fois de suite en spammant le bouton de l’aperçu des parties des tutoriels).

[EDIT] 2e question importante A-312 : est-ce que tu as constaté ça dès l’arrivée de zmd, ou seulement depuis 2–3 semaines ? Quand on a lancé zmd, on est parti avec 3 serveurs parce qu’autant être large au cas où la charge avait été supérieure à ce qu’on évaluait. Depuis on a scale down à 1 seul serveur. Comme node c’est single-threaded, il se pourrait qu’aux heures de pointe il y ait un délai petit (genre 0.5s) qui rendre l’utilisation pénible.

Depuis une semaine, voir 5–6 jours mais je n’avais pas la même connexion.

Le fonctionnement est : au survol du bouton, demander à zmd d’envoyer l’aperçu s’il n’y a pas déjà l’aperçu généré et correspondant au contenu de la boite. Au clic, si le texte a été modifié depuis la génération du dernier aperçu, demander un nouvel aperçu et l’afficher. Sinon, afficher l’aperçu déjà généré. (Les aperçus ne sont pas stockés dans le navigateur, il y en a qu’un seul qui remplace le précédent en cas de nouvel aperçu.)

Je viens de voir le comportement dans l’onglet réseau de mon inspecteur de code, ça ne fonctionnait pas du tout comme ça. Et je n’avais pas l’aperçu en live.

Les requêtes s’envoyait plusieurs fois quand je cliquais dessus et le bouton ne se grisait pas. Là je suis sur mon PC principale, le bouton aperçu se grise et cliquer plusieurs fois dessus ne change rien.

Sur ton téléphone ?

(Je viens d’essayer avec mon chromebook, je peux lancer 3 fois de suite en spammant le bouton de l’aperçu des parties des tutoriels).

Navré d’insister mais je veux être 100% sûr de ce que tu dis ici : Sur ton chromebook, si tu écris un truc dans l’éditeur puis que tu cliques 3x de suite en spammant un bouton d’aperçu, tu vois 3 requêtes partir ?

C’est à dire tu fais ça : https://imgur.com/a/5gikCig

Mais chez toi ça balance une requête par clic alors que chez moi ça se comporte bien ? Tu peux me montrer ?

Depuis une semaine, voir 5–6 jours mais je n’avais pas la même connexion.

Dans ce cas on va scale out le server zmd, revenir à 2 process.

Si si, ça fonctionnait comme ça depuis un bon mois. Ça fonctionne toujours comme ça. C’est bien simple, ça n’a pas changé, c’est le comportement de l’aperçu dans la v27.

Je peux le faire sur le forum mais il me faut un long sujet ou une plus mauvaise connexion.

EDIT :

https://github.com/zestedesavoir/zds-site/blob/ae1f94d073ea2534b22c944814f94c6a5f840051/assets/js/ajax-actions.js#L296

Je n’ai jamais utilisé always, mais si j’ai bien compris la documentation ça équivaut à done ou à fail. Alors que normalement cette ligne devrait être avant $.ajax (où en tout cas avant que la requête ajax soit lancé).

EDIT 2 : Après avoir regardé le code plus attentivement ce n’est pas aussi simple, peut-être rajouter une nouvelle variable et condition.

Ah oui tiens, si je dis à chrome qu’il est un Slow 3G, il fait pareil.

peut-être rajouter une nouvelle variable et condition.

Bien vu, il va en effet falloir modifier le code si on veut régler le bug. Je vais regarder ça. Il se peut que l.296 à 282 règle ça. On verra.

(pour information, j’ai été obligé de remonter la liste des messages postés par @cepus pour retrouver cette conversation, ni le moteur de recherche interne ni Google ne m’ont aidé…)

Je confirme que c’est précisément le test ici https://github.com/zestedesavoir/zds-site/blob/ae1f94d073ea2534b22c944814f94c6a5f840051/assets/js/ajax-actions.js#L298 qui pose problème : pour une raison X ou Y, le serveur était lent tout à l’heure (400 ms de ping sur une fibre sans charge), donc au lieu d’avoir :

1. Survol du bouton → envoi de la requête
2. Réception de la réponse
3. Click → MàJ de l’aperçu

J’ai eu :

1. Survol du bouton → envoi de la requête
2. Click → Rien parce que pas de nouvel aperçu
3. Réception de la réponse mais on en fait rien parce pas le bon évènement

Ça améliore vraiment la réactivité de façon perceptible de faire la requête au survol et pas au clic ?