Pas mal, mais maintenant l'affichage est un peu large et donc le texte un peu petit.
En mode paysage, c'est nickel, en mode portrait, un peu petit:

Est-ce "un peu petit" ou "trop petit" ? Je veux dire : est-ce que ça reste lisible sans devoir zoomer, à l'instar d'autres sites web, ou ce n'est pas le cas ?

Je peux éventuellement passer à 550 pixels au lieu de 600, mais descendre à 500 ou moins n'est probablement pas une bonne idée (par exemple, les conversations de la messagerie interne nécessitent déjà 450 pixels).

Essaie 500 px, et je posterai une image en retour.
Actuellement, c'est trop petit.
La lecture n'est pas agréable.
Dans la toute première configuration, c'était optimal, la police était pile poil à la bonne taille pour être lisible facilement sur un téléphone portable sans fatiguer et sans forcer avec les yeux.
Donc essaie un 500 px et je te donnerai mon avis

J'aime beaucoup les nouvelles icônes de mise en forme, plus simple, plus sobres et plus compréhensibles (je me plantais toujours entre IMG et URL)

PetitCalgonDonc essaie un 500 px et je te donnerai mon avis

Voilà

PS : Marcant, si tu lis ceci, je serai en retard pour la Nascar ce soir

GuybrushPS : Marcant, si tu lis ceci, je serai en retard pour la Nascar ce soir

Comme je viens de lire ce message, je viens de lancer la Nascar, au pire, on reviendra en arrière si vraiment y a un truc à voir ^^

lexpage.net/posts/tags/ <- bug, il faut une recherche sur un pattern vide alors que c'est la page pour lister tous les tags (et en plus, après avoir manipulé l'URL pour arriver là, j'ai vu le lien à droite qui existait déjà)

Tchouhttp://lexpage.net/posts/tags/ <- bug, il faut une recherche sur un pattern vide alors que c'est la page pour lister tous les tags (et en plus, après avoir manipulé l'URL pour arriver là, j'ai vu le lien à droite qui existait déjà)

J'ai pas compris ton message En quoi la page bug ?

Globalement, beaucoup, mais pas mal sont juste de l'interface ... même le principal, du reste ! :)

Principal grief : la partie "Résultats de la recherche" quand tu arrive sur la page. Non, quand tu arrive sur la page, t'as 0 résultat de ta recherche, c'est évident.
Ensuite, je viens de voir que c'est du JS pour charger l'input, mais pas pour afficher les résultats. Détail, mais tu es dans un mi-chemin : le comportement classique est que tu clique sur un tag, tu es redirigé vers le résultat directement (en html), OU si tu veux le faire en JS, tu charge en AJAX.
Là, tu es dans un entre-deux pas top niveau ergonomie, car dans le cas le plus fréquent de cliquer sur UN tag, tu as 2 manips à faire. Bon point cependant : tu as une URL avec les tags. Avoir l'URL qui se modifie en JS quand tu clique sur le tag serai l'étape suivante bienvenue. D'autant que le soucis de cliquer sur un lien et donc ne pas avoir le focus sur l'input emmene à des conneries genre je clique, ah non je veux supprimer, j'appuie sur retour arrière, je retourne à la page d'avant.

Pire : je veux les tags "actualité", je clique avec ma souris dessus. Je veux valider, j'appuie sur enter ... REEEUH, l'input n'a pas le focus, donc j'ai rajouté un second "actualité" à l'input mais je n'ai pas lancé ma recherche.

Cliquer une seconde fois sur un tag ne l'efface pas de ta recherche, mais l'ajoute deux fois. Tu n'as pas de mécanisme pour vider le contenu de l'input en une seule fois, qui permettrai de pallier à ça.

Tu as aussi, indépendamment de l'interface, un soucis avec les données : "actualité" est sensé être un tag, ne retourne aucun résultat. "breve" est annoncé avec 2 résultat mais n'en retourne qu'un. C'est pas un soucis d'un résultat qui glisse car v3 avec 1 résultat retourne un résultat.


Enfin, un détail sur l'interface : avoir le nombre de résultats dans la même typo que le terme nuit à la lisibilité de ta liste. Avoir le "(2)" en plus petit, en gris de tes détails, allégerai l'interface. Et faudra voir quand on aura plus de données (de tags différents" pour voir si ça reste lisible ainsi, ou passer sur une logique graphique de tag-cloud pour grossir les résultats principaux ou pas.

Ah, t'aurais pas dû me dire de regarder en détails !

Voilà, j'ai adapté la page. J'irai presque à dire que je te déteste Tchou, pas à cause de tes commentaires, mais parce que ça concernait des bugs qui sont extrêmement pénibles et difficiles à localiser.

Dans l'ordre :
- La partie "Résultat" ne s'affichera pas s'il n'y a pas de recherche. Ca aurait du fonctionner déjà de base, si seulement la chaîne de recherche était "nulle" et non pas vide
- Le fait qu'un seul billet s'affiche quand on choisit "brève" était un beau petit bug : en fait, pour les besoins du test, j'avais fixé la pagination à 1 par page.... et la barre de pagination était mal chargée sur cette page, ce qui fait qu'elle ne s'affichait pas. Assez pénible à trouver
- Le nombre d'occurrences par étiquettes est maintenant indiqué en petit et en gris.
- Quand on clique sur une étiquette sur la page des étiquettes, elle est ajoutée au champ. Si on reclique dessus, elle est retirée. J'ai du passer par les regex en JS pour gérer ça proprement (et accessoirement résoudre le problème d'espace dans le champ). Et là, chouette chouette chouette, mais JS, Regex et Unicode ne font pas bon ménage... Donc si on clique/retire \b$tag$\b, ça ne marche pas dans le cas de "actualité", par exemple, parce que le "é" n'est pas une lettre pour JS, donc \b va matcher "actualit". Bref, je contourne en utilisant (\s|^)$tag$(\s|$) mais je trouve ça plutôt pénible
- Le fait qu'aucun billet ne s'affiche quand on faisait une vraie recherche sur "actualité" était dû à un souci au niveau de la regex en python... Grosso-modo, le champ est peuplé via r'regex_avec_$tag$_regex' du coté de Python. Le "r" initial indique que la chaîne est en raw (pour pas avoir a backslashé dans tous les sens, sachant que c'est de toute façon protégé par la suite). Le "hic", c'est qu'injecter un caractère unicode dans une chaîne raw, ça a l'air de considérer le caractère via son entité \xxx... et donc la mauvaise chaîne était recherché.

Mais normalement, c'est bon

Et là, j'ai juste regardé en détail UNE page !
T'aurais pas dû me demander "quel bug", j'avais juste tiqué sur le "résultat de votre recherche vide", ensuite j'ai testé la page comme je le ferai pour mes propres sites !

Allez, une petite autre : ici même sur une rédaction de message, je clique sur smileys, une div en overlay s'affiche. Je clique sur le smiley choisi, il s'insère dans le texte, mais ne ferme pas la div. Je ne sais pas si c'est un bug ou une feature, je te laisse le choix sur celle-là.

Ni l'un, ni l'autre. C'est un choix (mais je me suis pas vraiment posé la question). En général, quand je fais appel au panneau smiley (sur la v3 du moins), c'est pour insérer plusieurs smiley "spéciaux", donc j'aime bien que ça reste ouvert pendant ce temps... Cela dit, dépendant de vos retours, je peux ajouter de quoi fermer le panel automatiquement


Anca> Pour la version mobile, normalement la navbar n'est plus activable en "hover" mais uniquement en "click" comme dans le Bootstrap de base. Ca signifie qu'il ne faudra plus "appuyer" deux fois sur un menu pour le déployer (je suppose que tu avais remarqué ce petit "bug" ?). Je regarde actuellement pour faire en sorte de déplacer le minichat quand les colonnes "s'empilent". Pour l'instant, le minichat est juste caché, pour éviter d'avoir à scroller 500 pixels avant d'atteindre le début de la page. Dans l'idée, ce serait de le déplacer en fin de page, afin qu'il reste accessible mais sans gêner la navigation sur mobile...

[Edité : Bon, à priori, pas vraiment moyen de faire une media-query ou un check-state avec Bootstrap sans ajouter une librairie supplémentaire. J'ai donc modifié 2-3 trucs : en version mobile, le contenu du minichat est caché, et un bouton supplémentaire permettant d'afficher le minichat s'ajoute... Ainsi, le minichat est accessible, mais ne prend pas trop de place sur l'écran par défaut].