nud a écrit 906 commentaires

un cannard

\_o<

Oui par contre je suis pas très d'accord avec "La barre de navigation devrait prendre toute la largeur de l’écran et être plus petite (à l’image de la «version bureau» ou elle est très fine)." parce que si je demande des boutons bien carrés avec bordures et clicables c'est justement parce que j'ai du mal à cliquer dessus avec mes gros doigts actuellement.

Je crois qu'il faut que ça prenne tout l'écran pour éviter de pousser sur ce qu'il y a derrière, et qu'on s'assure que toute la hauteur de la barre est clicable (pas de marges inutiles) pour simplifier l'utilisation au doigt. Sur le desktop personne n'utilise les boutons sur la barre, tout le monde utilise son clavier je pense.

Et mon screenshot n'est pas chrome mais firefox mobile…

Ta réflexion sur les utilisateurs qui mentent m'a fait penser à Dr House qui part du principe que tout le monde ment … et ça m'a amusé.

En fait c'est redoutablement pertinent: dans le cas du Dr House on a des patients sans connaissances médicales qui ne peuvent pas exprimer correctement ce qu'ils vivent, et dans le cas du sysadmin, on a des clients sans connaissances informatiques qui ne peuvent pas exprimer correctement ce qu'ils vivent.

Mon boulot pourrait être qualifié de "devops" dans la mesure où je travaille sur des trucs à installer chez des clients. Je n'ai pas d'utilisateurs directs mais, de par l'installation de nos systèmes chez nos clients, nous sommes amenés à faire du support technique auprès des sysadmins qui gèrent lesdits systèmes.

Je n'irais pas jusqu'à dire que 99% des sysadmins mentent ou se moquent des explications, mais en toute honnêteté, une bonne partie des administrateurs systèmes se comportent d'une façon très similaire aux utilisateurs que tu décris. Pas tous, loin de là, certains peuvent faire preuve d'une très bonne volonté quand il s'agit de résoudre des problèmes, qui, après tout, les affectent au premier plan. Mais pour certains, la configuration se modifie toute seule par magie (alors que les logs pointent toujours le coupable), le réseau est doué d'une volonté propre, et la documentation n'a qu'une seule utilité: pouvoir se plaindre de son absence… mais en aucun cas la feuilleter en cas de souci. Certains ne s'intéressent tout simplement pas à l'aspect dûquel tu t'occupes.

Je pense que le problème n'est pas forcément lié au job, je pense qu'il est surtout lié au type de fonction. Á partir du moment où tu parles à un client, tu es condamné à revivre le même genre d'expérience. Et si tu étais dans l'administratif ou les RH, avoir un énième zigoto qui n'a pas lu le document explicatif qui va avec le formulaire et qui te répète que ça ne sert de toute façon à rien doit aussi égayer ta journée et revaloriser ton égo. D'ailleurs, est-ce que les RH, les supports techniques et les administrations ne sont pas souvent étiquetés de désagréables et condescendants ?

Et le pire, c'est qu'au final, l'utilisateur n'est peut-être pas de mauvaise foi. Un document explicatif mal compris, une opération réalisée par accident sans forcément le remarquer (genre un truc qui tombe sur le clavier et qui en profite pour enfoncer la touche "delete"), ou un comportement inattendu, un accident bête qui au final va passer pour une explication farfelue, ça peut arriver à tout le monde et ce n'est pas toujours de mauvaise foi. Et en tant qu'expert en ton domaine, effectivement, le premier commandement est de ne pas coire ce que l'utilisateur explique, même de bonne foi.

C'est avec Firefox mobile. Avec Chrome j'ai à peu près le même rendu que toi.

D'ailleurs pour la barre je suggèrerais de l'avoir en width:100% et avec des boutons < et > bien carrés avec des bordures (pour bien montrer où on doit mettre les doigts, c'est parfois un peu fastidieux)

Voici:

Il faut aussi se souvenir que l'écran fait environ 5cm sur 8.5 pour pouvoir se rendre compte. La police est certes nette, mais fort petite sur l'écran.

Moi le truc qui me bloque c'est le fait qu'avec firebug on voit les marges/padding/etc mais pas avec les devtools intégrés à firefox. Mais on m'a dit que ça allait changer sous peu.

Un des problèmes que j'ai rencontré dans mon utilisation de linuxfr sur mobile c'est aussi la taille "pattes de mouches" de la police. J'ai remarqué que la police semble plus petite sous firefox mobile beta que sous chrome mais je pense que c'est dû à une police par défaut différente (c'est dûr de vérifier…). Pour moi la police est vraiment à la limite inférieure du lisible sans mettre mon nez sur l'écran, et ça ne doit pas arranger les problèmes de vue des utilisateurs…

J'utilise un Sony Xperia P dont les spécifications d'écran sont:

• Résolution: 540x960 pixels
• Taille physique: 4.0 inches
• Densité de pixels: ±275 ppi

Je ne peux en toute honnêteté pas dire que le problème est généralisé car la lisibilité dépend probablement de la densité de pixels des différents modèles de téléphones et de tablettes. Cependant je crois qu'une taille un peu plus grande sur mobile ne pourrait faire que du bien. Par ailleurs le paramètre "text size" dans Firefox mobile n'a absolument aucune influence sur la taille du texte sur le site malgré que les tailles soient définies en em…

Surtout que Baldur's Gate (en tout cas le 2) fonctionnait nativement sous Linux.

Merci pour ta réaction.

Je suis d'accord que le problème est aussi au niveau du navigateur. Cependant tous les navigateurs utilisent les mêmes polices par défaut donc le problème se pose partout. En pratique rare sont les gens qui changent les polices par défaut du navigateur, ne fut-ce que parce que changer ces polices et leur taille rend illisible la moitié du web. Enfin en fait je crois que le bug est surtout dans la police, qui aurait pu faire de meilleurs choix au niveau du hinting.

Concernant la justification technique, juge par toi-même en affichant l'image suivante à sa taille réelle (en haut, DejaVu, et en bas, Open Sans):

Le problème se situe à certains points où la police "saute", donc oui si tu zoomes à 300% ta police sera parfaite. C'est généralement dérangeant uniquement au moment du "saut", pas pour des tailles plus grandes. Evidemment, le saut en question se trouve à l'endroit dérangeant, sinon ce ne serait pas drôle. Et le problème est bien lié au hinting, comme l'atteste le bout de screenshot en haut à droite, avec hinting désactivé (oui c'est une solution mais ça rend le texte bien moins lisible également, le texte est flou). Et bon, je ne suis pas sous Windows, mais sous Linux, avec Iceweasel (Firefox) 24.3.

Pour le contournement si la demande est implémentée, il est encore plus simple pour l'utilisateur avisé que le changement de police: il suffit de désactiver la possibilité pour les sites d'utiliser leur propre police, et en plus ça prendra effet pour tous les sites qui utilisent le même procédé (et les mêmes polices que celles proposées). De toute façon il s'agit évidemment au final d'une décision à vocation esthétique.

Notez bien que je n'émets pas d'avis particulier sur la police à utiliser, il est tout à fait envisageable d'en discuter. "Open Sans" me semble néanmoins un bon candidat vu sa popularité, et c'est pour cela que je l'ai utilisée dans la capture d'écran de ce commentaire.

Juste pour mentionner dans le contexte de cette entrée du suivi mon journal sur une config ansible pour créer une machine virtuelle "LinuxFR", et le dépôt git associé:

• Toi aussi installe ton propre linuxfr en trois lignes de bash… et contribue!
• Dépôt git

Apparemment on pouvait utiliser un disque luks sous windows avec FreeOTFE, mais ça a plus l'air trop maintenu (le domaine a l'air d'avoir disparu) et ça ne résoud pas le problème de l'ext3.

Tu devrais faire un patch plutôt que de donner un fichier css, car sinon la maintenance est impossible.

En plus les fichiers SCSS sont bien faits, il est probable que tu puisses tout simplement redéfinir les variables de couleurs et importer le style "parent". C'est ce qui est fait pour les différentes couleurs de RonRonnement. Voici RonRonnenent-Vert.css.scss pour l'exemple:

@charset "UTF-8";

$C_CLAIR: #E9E6E4;
$C_BANDEAU: #96BD0D !default;
$C_FONCE: #93877B;
$C_INTER: #93877B;
$C_BAS_FOND: #E4E4E4;
$C_FOOT: #D4D1CF;
$C_MIBLANC_MIFOOT: #E9E8E7;
$C_CONTAINER: #F9F9F9;
$C_MENU: #4C575F;

$C_BD1: transparentize($C_BANDEAU, 0.84);
$C_BD2: transparentize($C_BANDEAU, 0.67);
$C_BD3: transparentize($C_BANDEAU, 0.50);
$C_BD4: transparentize($C_BANDEAU, 0.33);
$C_BD5: transparentize($C_BANDEAU, 0.17);

@import '../RonRonnement';

Il est aussi possible de rajouter des bouts de CSS pour "recouvrir" les déclarations existantes. Ça fait des fichiers beaucoup plus courts et simples à maintenir.

Certes, mais ça implique de modifier la config de l'environnement de développement du dépôt linuxfr.org, qui utilise dlfp.lo, et je voulais éviter autant que possible toute déviation par rapport au dlfp officiel…

Et ma connaissance de ruby et de rails étant inexistante, je ne sais pas comment faire pour avoir une config dynamique qui n'imposerait pas la modification "par machine" d'un fichier suivi dans le git (le but est quand même de faciliter le développement donc il faut que le dépôt soit propre).

Ça veut dire aussi: patches accepted pour ceux qui savent comment faire :-) Une étape en moins dans la todo ça serait génial.

Les études sont plutôt exprimée en termes de nombre de caractères, pas en pixels. En voici une pour l'exemple.

Les 1350px ne sont pas une vérité absolue, ça s'appelle un compromis.

Zenitram, juste une petite question personnelle: qu'utilises-tu comme écran pour visiter linuxfr ? (taille et résolution)

LinuxFr rentre pour moi (ce qui n'a aucune importance ;-) ) dans la catégorie des sites qui se foutent des indications des utilisateurs

Ce n'est pas vrai, la taille de l'écran n'est pas une indication donnée volontairement par l'utilisateur, c'est juste un état de fait. Et il est également dangereux de considérer que l'avis de la minorité la plus vocale est celui qui est partagé par le plus grand monde. D'autant plus que ici les contre-arguments tendent sur l'idéologie et ne sont pas étayés visiblement par un cas pratique et les données y afférentes.

Je suis limite surpris que personne n'ait rouspété sur les autres changements cosmétiques de la CSS par défaut d'ailleurs.

L'entrée du suivi dit:

Je ne pense pas que le contre-argument souvent évoqué ("on peut naviguer avec une fenêtre qui n'est pas maximisée") ait une valeur parce que les navigateurs à onglets et les bureaux modernes en général (que ce soit gnome 3, kde 4 ou windows 8) ne poussent pas vraiment à l'utilisation de petites fenêtres.

La pratique, c'est qu'à part quelques power users (dont tu fais sans doute partie) s'amusent à avoir des petites fenêtres ou utilisent un gestionnaire de fenêtres à pavage, mais même ici, je suis certain que la majorité des gens utilisent généralement leur navigateur en plein écran.

Aussi, les gens utilisent des onglets, et s'il faut une taille différente pour chaque onglet, c'est ingérable: cela imposerait de redimensionner sa fenêtre en fonction de l'onglet sur lequel on se trouve pour avoir la taille idéale.

Je suis à fond pour une mise en page fluide et adaptative, mais il faut rester pratique.

Mais voila : un écran n'est pas un journal, je peux avoir une plus grosse police de caractères (par exemple).

Actuellement sur linuxfr la taille de la police est fixe. Si on passe à une taille de police relative à la largeur de l'écran (comme sur ce site par exemple) on peut alors imaginer une mise en page 100% fluide (modulo le problème des images).

Mais j'imagine que les gens vont se mettre à rouspéter que la taille des caractère va être trop grosse, bien qu'ils puissent la contrôler en redimensionnant la fenêtre. Ceci dit, les possesseurs d'écrans à haut dpi (genre écran 15'' en 1920x1080) dont je fais partie en seraient sans doute très heureux. C'est d'ailleurs la solution que je suggérais dans l'entrée du suivi :-)

Mais de quoi je me mêle? Si je règle la largeur de mon navigateur à 1000 px, c'est que je veux que le site s'affiche sur 1000 px.

En même temps le max-width est à 1350px, et sous cette largeur le comportement ne change pas d'un poil. Jusqu'à preuve du contraire 1000px c'est inférieur à 1350px.

Grosso modo ça ne concerne que les psychorigides qui possèdent un écran HD.

ça peut d'ailleurs être rigolo de passer à 30% quand les écrnas 4K apparaitront

Quand les écrans 4K apparaîtront, tu ne voudras sans doute pas avoir un site avec des lignes de 12 pixels de haut et de plus de 500 caractères de long.

Le problème est la taille physique des caractères. La taille dans la CSS devrait sans doute être relative à la taille en pixel de l'écran. L'entrée du suivi initiale (l'as-tu lue?) dit même:

Alternativement ou en complément, il serait envisageable de "zoomer" automatiquement la taille des polices et images afin d'obtenir le même résultat: la réduction de la taille des lignes mais c'est peut-être plus compliqué à mettre en œuvre de façon satisfaisante notamment en ce qui concerne les images si on veut que ça ressemble à quelque chose.

Je pense qu'il faut comprendre le max-width actuel comme un quick fix en attendant mieux.

Au moins ce ne sont pas des mis au bout des lignes comme les RFC que tu prends comme exemple.

Quelles sont les autres alternatives ?

Si on plonge un petit peu dans l'histoire, on peut retourner à l'époque où Gnome cherchait un langage de script à mettre en avant pour la version 3, afin d'éviter d'avoir 150 langages comme c'était le cas dans Gnome 2. C'est Javascript qui a été choisi, car l'un des critères principaux était le fait que le langage soit dynamique et ne vienne pas avec sa propre plateforme (comme python, perl, etc). D'autres langages qui correspondent à ces critères sont scheme/lisp et lua, mais en fait ça écarte de facto la plupart des langages "barbus" habituels comme python, ruby ou perl…

Bon, en pratique les applications écrites en python n'ont pas été réécrites pour autant…

Même si tout y est, je suis sûr qu'un peu de clarté ne ferait pas de mal.

checkthis.com n'a pas l'air d'apprécier le greylisting…

C'est pas censé être du SIP Lync?

Ça ne fonctionne pas avec les bons vieux clients SIP des familles, genre Ekiga, Jitsy et consorts?

Le danger d'une liste, c'est qu'on en oublie toujours.

GNOME sera présent au FOSDEM et organise quelques trucs comme chaque année, notamment un Beer Event le samedi soir.

De la même manière avec les tags, quand on "ajoute" un tag déjà présent en cliquant sur le marque page, le tag devrait se modifier en petite croix et permettre de supprimer le tag directement.

J'ai cru remarquer qu'il y avait deux modèles d'icones 'marque page' suivant qu'il s'agit d'un tag qu'on a ajouté ou pas, mais parfois c'est une croix qui s'affiche. Je n'en comprends pas bien la logique mais à mon avis ça devrait être uniformisé.