Carnet de notes

Catégorie : Développement informatique

  • Prio­ri­sa­tion du back­log

    Ce billet vient d’un désac­cord sur twit­ter sur les éléments qui permettent de prio­ri­ser un back­log dans un déve­lop­pe­ment agile.

    On me propose de trier par valeur fonc­tion­nelle (je vais parler de valeur ajou­tée au produit, pour éviter de mélan­ger avec la complexité fonc­tion­nelle) mais cela ne me convient pas.

    Toutes les histoires n’ont pas le même détail

    Sur mon back­log j’ai de quoi remplir plusieurs sprints. Toutes les histoires n’ont pas le même niveau de détail. Détailler tout c’est passer un temps énorme à faire un travail qui risquera d’être remis en cause et qui délaiera inuti­le­ment le déve­lop­pe­ment. L’objec­tif n’est pas de faire un cahier des charges détaillé sur deux ans. Mon respon­sable produit fera ça au fur et à mesure. Ce qui est prio­ri­taire est détaillé et plus on s’en­fonce dans le back­log plus les histoires utili­sa­teurs sont « macro ».

    Une « macro » histoire sera décou­pée en plusieurs petites. Logique­ment la valeur ajou­tée liée à cette macro histoire sera aussi divi­sée. Si vous suivez, il y a de bonnes chances pour que les macro histoires en milieu de sprint soient celles qui ont une colonne « valeur » avec les plus gros nombres. Les histoires à faire aujourd’­hui et demain seront bien décou­pées, et donc unitai­re­ment avec des petites valeurs ajou­tées.

    Voilà mon premier argu­ment pour ne pas clas­ser que par la valeur ajou­tée : Ça revien­drait à mettre en premier les histoires les moins détaillées, puis les détailler (vu qu’elles sont prio­ri­taires), se rendre compte que du coup d’autres sortent avant, les redé­tailler, et ainsi de suite. En quelques itéra­tions on va finir par détailler trop préci­sé­ment un plan d’ac­tion pour plus d’un an, et faire un travail inutile tout en ayant mal prio­risé entre temps.

    La prio­rité c’est sortir la plus grande valeur à chaque itéra­tion

    Toutes les histoires n’ont pas le même niveau de détail, mais elles ne néces­sitent pas toujours le même effort non plus. Imagi­nons un site d’ac­tua­lité, avec une histoire « permettre de saisir un commen­taire » (c’était impos­sible jusqu’a­lors) et une histoire « affi­cher le titre séparé du corps de l’ar­ticle » (il était collé aupa­ra­vant).

    Ajou­ter des commen­taires apporte bien plus de valeur qu’ajou­ter un espace entre le titre et le corps du texte, disons « 10 » pour le premier et « 2 » pour le second. Mais côté effort de déve­lop­pe­ment c’est la même chose : « 20 »pour le premier, et « 0,5 » pour le second.

    Si je classe simple­ment par la valeur ajou­tée, je vais prio­ri­ser des histoires comme « saisir des commen­taires ». Pour­tant si je calcule j’au­rai eu plus de valeur ajou­tée à mon produit si j’avais prio­risé d’abord plusieurs histoires de type « sépa­rer le titre ».

    Ma prio­rité c’est bien de livrer la plus grande valeur à la sortie de l’ité­ra­tion. La prio­rité est donc, logique­ment, plus dépen­dante du rapport valeur/effort que de la valeur elle-même. J’ai besoin d’avoir estimé mes histoires pour en connaître l’ef­fort et les prio­ri­ser. Un respon­sable produit qui prio­rise sans connaître l’ef­fort asso­cié à chaque histoire ne peut pas maxi­mi­ser la valeur de son produit, et c’est pour­tant tout l’objec­tif de la démarche.

    Encore d’autres facteurs

    Le ratio valeur/effort est pour moi un bon critère de tri pour la prio­ri­sa­tion. On ajoute après des contraintes fonc­tion­nelles comme les dead­line fonc­tion­nelles comme un contrat de parte­na­riat à implé­men­ter dans le mois.

    Mais là aussi la tech­nique a son mot à dire. Nos histoires ont des dépen­dances tech­niques entre elles, et ça joue et doit jouer sur les prio­ri­tés. De même tout déve­lop­peur sait bien que parfois faire deux tâches ensemble permet de gagner un temps certain. Il y a des prio­ri­tés d’op­por­tu­nité à faire : d’un coup je peux faire à moindre coup une fonc­tion­na­lité qui est norma­le­ment plus bas dans le back­log.

    Parfois j’y gagne à court terme (parce que le niveau d’ef­fort dimi­nue telle­ment qu’elle devient bien prio­ri­taire). Parfois j’y perd un peu à court terme mais je gagne bien en valeur à moyen terme puisqu’au final j’ai bien dimi­nué l’ef­fort et donc permis de faire une histoire de plus. Tout est un équi­libre entre le gain en terme d’ef­fort et la valeur de l’his­toire à reprio­ri­ser.

  • Perplexité, complexité, vélo­cité … une autre vue

    J’ai lu « Perplexité, complexité, vélo­cité » sur le blog d’OCTO. L’ar­ticle est bien tourné et on sort complè­te­ment convaincu. Mon problème c’est que quelques heures après j’ai commencé à avoir des doutes et plus les jours avancent plus mes doutes se trans­forment en avis contraire. Je vous encou­rage à lire d’abord le billet d’OCTO, le mien n’aura de sens qu’en réponse.

    À quoi sert la vélo­cité ?

    À quoi sert la vélo­cité ?

    1.     Esti­mer ce qui sera réalisé ou non dans le sprint

    2.     Mesu­rer la produc­ti­vité de l’équipe

    3.     Mesu­rer le réalisé pour le projet, le produit

    Ma diver­gence avec l’ar­ticle source vient d’un constat simple : Nous n’uti­li­sons pas cet indi­ca­teur dans le même objec­tif. Lui l’uti­lise pour mesu­rer la produc­ti­vité, moi pour amélio­rer les esti­ma­tions.

    Amélio­rer les esti­ma­tions

    Amélio­rer les esti­ma­tions c’est faire en sorte de mieux évaluer ce qui sera livré dans chaque sprint et aider à la prio­ri­sa­tion. Bref, gérer le projet.

    Pour amélio­rer nos esti­ma­tions on tente de se baser sur les tâches simi­laires précé­dentes et on en réuti­lise l’es­ti­ma­tion sans tenir compte de la produc­ti­vité de l’équipe. On utilise pour cela une unité virtuelle qui nous détache des jours/hommes : le point. Réali­ser une esti­ma­tion ainsi est de plus en plus simple, rapide et fiable.

    Pour prendre en compte les évolu­tions de produc­ti­vité (équipe plus effi­cace ou dette tech­nique gran­dis­sante) c’est le nombre de points réali­sable dans un sprint qu’on fait varier. Afin de ne pas sortir le dé pour évaluer ce nombre de points, on se base sur ce qui a été réalisé dans les quelques sprints passés et on tente de rester sur une courbe la plus stable possible.

    Nos réfé­rences d’es­ti­ma­tion sont stables, nos esti­ma­tions se fiabi­lisent avec le temps. Le nombre magique de points qu’on peut mettre dans un sprint, c’est pour moi ce qu’est la vélo­cité de l’équipe.

    En prenant en compte la tech­nique

    Si on calcule en points et pas en heures ou en jours, ce n’est pas parce qu’on compte en complexité fonc­tionne, c’est pour s’au­to­ri­ser à faire varier la somme totale plutôt que chaque esti­ma­tion.

    Il ne faut pas perdre de vue que notre objec­tif reste bien d’éva­luer une charge de déve­lop­pe­ment. Il faut donc tenir compte dans nos esti­ma­tions de tout ce qui est néces­saire à évaluer le temps de déve­lop­pe­ment et livrer la fonc­tion­na­lité : Ça va des besoins fonc­tion­nels à la complexité tech­nique en passant par les contraintes orga­ni­sa­tion­nelles spéci­fiques.

    Si je ne prends en compte que la complexité fonc­tion­nelle, l’es­ti­ma­tion n’aura plus aucun lien avec le temps de déve­lop­pe­ment. Pour savoir ce qui tient ou pas dans le sprint, on en vien­dra à faire une esti­ma­tion globale, au jugé, sans réfé­rences simi­laires : tout l’in­verse de l’objec­tif.

    Outil privé versus indi­ca­teur public

    À mon humble avis l’er­reur de l’ar­ticle n’est pas seule­ment de faire de la vélo­cité une mesure de produc­ti­vité, c’est en plus de l’avoir commu­niquée à l’ex­té­rieur de l’équipe.

    Du coup, forcé­ment, la vélo­cité devient un enjeu poli­tique. L’équipe, son mana­ger, son coach commencent à avoir inté­rêt à amélio­rer l’in­di­ca­teur au lieu de se concen­trer sur ce qui devrait être leur seul objec­tif : appor­ter de la valeur au produit.

    Que la vélo­cité augmente, dimi­nue, c’est quelque chose propre à l’équipe. S’il faut un indi­ca­teur de produc­ti­vité et de pertur­ba­tion, il faut publier la seule chose impor­tante : la progres­sion de la valeur du produit (si ça ressemble au para­graphe précé­dent, ce n’est pas une coïn­ci­dence).

    Cette vélo­cité doit être prise pour ce qu’elle est : un outil d’es­ti­ma­tion, de plani­fi­ca­tion et de prio­ri­sa­tion. Comme tous les outils, il a voca­tion à être utilisé en interne, par l’équipe, et nulle part ailleurs.

    Et la complexité fonc­tion­nelle ?

    Mon second problème est là : Selon moi la complexité fonc­tion­nelle n’in­dique rien de valable. Ce n’est pas une mesure de ce que coûte la fonc­tion­na­lité, ce n’est pas une mesure de ce qu’ap­porte la fonc­tion­na­lité, et inci­dem­ment ce n’est pas une mesure de l’im­pli­ca­tion ou de la produc­ti­vité de l’équipe.

    Tout au plus la complexité fonc­tion­nelle permet de faire une première esti­ma­tion des histoires utili­sa­teurs qui ne sont pas prévues pour tout de suite ou dont on ne connaît pas la complexité tech­nique.

  • Réso­lu­tions d’écran – mai 2011

    Petite statis­tiques abso­lu­ment pas repré­sen­ta­tive mais inté­res­sante quand même : les réso­lu­tions d’écran des gens qui sont passés sur ce site du 1 au 12 mai 2011.

    Petite inter­pré­ta­tion perso :

    • J’ai moins de 10% de visites de mobile (réso­lu­tion infé­rieure à 1024px)
    • Je dois avoir envi­ron 3% de netbook et tablettes (réso­lu­tion de 1024px mais pas plus)
    • Les desk­top supportent tous ou presque au moins 1280px (87% de support, mobiles inclus)
    • Les mobiles sont tous diffé­rents et il est diffi­cile d’ac­ter d’une réso­lu­tion mini­male stan­dard sauf à la prendre vrai­ment très petite
    Avec comme consé­quence sur le design, si on doit faire plusieurs versions:
    • Une version mini­male à 240 ou 280px, quitte à ce qu’elle soit très dégra­dée
    • Une version à 800 (android récent en paysage), qui servira aussi pour les iphone avec une meilleure réso­lu­tion, les tablettes et les netbooks
    • Une version desk­top à 1280, qui sera la version « stan­dard »
    • Une à 1400 ou 1600 pour récu­pé­rer les écrans larges
    • Et si je suis bien luné une version à 1900 parce que ça concerne quand même encore un quart des visites
    Atten­tion, ces chiffres ne prétendent pas être repré­sen­ta­tifs de quoi que ce soit, et ne repré­sentent que des réso­lu­tions d’écran, pas des tailles de fenêtre, ce qui est nette­ment diffé­rent.

  • JSON c’est hype

    J’en ai marre de voir du JSON partout. J’ai même vu des gens propo­ser de rempla­cer du XML par du JSON juste parce que c’est plus moderne, plus léger et plus compa­tible. « JSON is the new XML » est un effet de mode, un mauvais effet de mode. On va se retrou­ver comme avant avec des gens qui vont se réveiller dans quelques mois/années avec des formats de données pas du tout adap­tés à leur usage.

    Coupons un peu dans le tas :

    JSON n’est pas vrai­ment plus simple à lire par un humain

    Pour un petit fichier en volume comme en hiérar­chie, le JSON a un léger avan­tage sur le XML mais ce n’est pas fran­che­ment signi­fi­ca­tif.

    Pour un gros fichier ou avec beau­coup de hiérar­chie, le JSON devient complè­te­ment illi­sible à suivre au niveau des imbri­ca­tions.

    JSON n’est pas plus simple à écrire par un humain

    JSON est un peu moins verbeux mais plus propice aux erreurs : facile d’ou­blier une virgule en fin de ligne, ou d’en mettre une par erreur à la dernière ligne. Sur les gros fichiers les niveaux d’im­bri­ca­tion seront eux aussi un écueil à l’écri­ture.

    En compa­rai­son la verbo­sité d’XML rend diffi­cile les erreurs et le dispo­ni­bi­lité de fichiers gram­maire permettent de faire de l’aide à la saisie voire de vali­der en tems réel le contenu.

    La diffé­rence de poids n’est pas signi­fi­ca­tive

    JSON est plus léger que le XML d’en­vi­ron un tiers (pour des fichiers forte­ment struc­tu­rés, beau­coup moins pour les autres). À moins de 1,5 Ko une fois compressé en gzip (donc 6 Ko non compressé) ça tient dans un paquet TCP/IP et 500 octets de moins ne changent stric­te­ment rien. Sur disque on compte de toutes façons au moins par paquets de 4K.

    Pour faire une diffé­rence signi­fi­ca­tive de 10 Ko sur le réseau il faut une donnée de 160 Ko avant compres­sion. Ça concerne d’au­tant moins de monde qu’à ce volume le JSON n’est plus du tout lisible.

    JSON n’est pas plus natif que XML

    XML est natif sur tous les outils, langages et navi­ga­teurs depuis des années là où JSON n’a d’API native que sur les navi­ga­teurs récents, certains langages et quelques outils.

    JSON est en fait natif en javas­cript via eval(), mais ça n’est pas plus perfor­mant. Pour une même donnée, lire du XML via DOM est 30% plus rapide que lire du JSON avec eval(). Pour avoir sécu­rité et fiabi­lité en lecture, ou pour faire de l’écri­ture JSON, il faudra une biblo­thèque pas native du tout sur IE7 ou Safari pour iPhone 3.2. Elle fera au moins 5 Ko et ne sera donc renta­bi­li­sée par rapport au XML natif que si on trans­fert au moins 15 Ko de JSON.

    JSON n’est pas vrai­ment exten­sible ou évolu­tif

    JSON permet souvent d’ajou­ter de nouvelles clefs sans modi­fier casser la compa­ti­bi­lité. Si on souhaite ajou­ter une date de mise à jour à une liste de chaînes de carac­tères, il faudra toute­fois modi­fier le format, mettre à jour tous les outils concer­nés. Si on souhaite mixer des formats diffé­rents là ça devient vite un casse-tête et des solu­tions bidouille.

    En XML on a la possi­bi­lité d’in­sé­rer des méta-données dans des attri­buts, ainsi que de mixer diffé­rents concepts ou formats à l’aide d’es­paces de noms. Ce sont des fonc­tion­na­li­tés qui ont leurs limites, mais qui ont prouvé appor­ter un peu de souplesse et d’évo­lu­ti­vité aux formats créés.

    Compa­tible avec l’exis­tant

    Outre le concept de « natif », beau­coup d’ou­tils, d’ap­pli­ca­tions, de progi­ciels ou de chaînes de trai­te­ment sont adap­tés à l’ex­ploi­ta­tion ou à l’ex­por­ta­tion de données XML. Côté JSON les plus récents savent faire de l’ex­port, tout le reste est à trai­ter en spéci­fique.

    Sur l’exis­tant XML j’ai des concepts de signa­ture, des mapping XML-Objet en Java, des outils qui font du filtre ou du routage, de la vali­da­tion, des compo­si­tions entre données XML.. tout ça n’existe simple­ment pas en JSON. Quand (si) j’en aurai besoin, il faudra réin­ven­ter la roue.

    Hype, mode et trucs de jeunes déve­lop­peurs inno­vants

    JSON était simple au départ parce qu’on utili­sait eval(), que ça renvoyait immé­dia­te­ment sur un objet javas­cript sans deman­der au déve­lop­peur client de faire des mani­pu­la­tions complexes ou de char­ger une biblio­thèque de plus. Ça a permis d’ou­vrir quelques API à des gens qui auraient eu du mal autre­ment. C’est indé­nia­ble­ment posi­tif sur ce point là.

    Ensuite s’est rendu compte que pour la fiabi­lité et la sécu­rité il fallait du code en plus. Faire des petites fonc­tions qui lisent du XML simple pour créer des objets javas­cript natifs aurait été plus simple, plus perfor­mant et moins lourd mais c’était trop tard : c’était « hype ». Du coup on a utilisé des biblio­thèques d’ana­lyse de 10 Ko de pur javas­cript pour lire des JSON de moins de 1 Ko et annon­cer que ces derniers étaient moins lourds que le XML corres­pon­dant. Allez comprendre.

    Depuis on a des fonc­tions natives dans les navi­ga­teurs récents et un peu plus de support dans les outils récents (c’est la mode, il a bien fallu faire avec et suppor­ter le nouvel usage) donc ça a du sens pour quelques usages (échange de petites données struc­tu­rées avec un navi­ga­teur récent) mais la mode prend encore trop le pas sur des grilles de compa­rai­son argu­men­tées et factuelles et même dans les usages les plus adap­tés, le béné­fice sur le XML est rare­ment très signi­fi­ca­tif.

  • Sud Web : La confé­rence des métiers du web dans le sud

    Nous avons monté Paris Web il y a main­te­nant quelques années pour parler du web, de ses métiers, de retours d’ex­pé­riences de profes­sion­nels sur la qualité, l’ac­ces­si­bi­lité et la publi­ca­tion sur le réseau. Depuis lors on nous a demandé « et pour les gens du sud alors ? ».

    Cette année quelques uns ont pris leur courage à deux mains pour créer Sud Web, un événe­ment avec une des meilleurs tagline qu’on puisse imagi­ner : savoir-faire et faire-savoir. Avec le soutien de parte­naires locaux comme la recom­man­da­tion de noms pres­ti­gieux comme le W3C, le programme qui s’an­nonce peut mettre au défi une grande majo­rité des événe­ments web français du domaine.

    Si c’est incon­tour­nable pour les passion­nés et les amou­reux du web, c’est aussi une étape de forma­tion conti­nue et d’ex­plo­ra­tion de l’état de l’art avec un recul que vous ne pour­rez pas compen­ser par quelques lectures en ligne ou par une session de forma­tion entre quatre murs.

    Tout ça c’est à Nîmes, fin mai, le 27 exac­te­ment. Pour ceux qui veulent renta­bi­li­ser leur dépla­ce­ment c’est précédé le 26 par une jour­née centrée autour de l’ex­pé­rience utili­sa­teur : Web UX. Alors ce n’est pas à Paris, mais entre le soleil et l’hé­ber­ge­ment moins coûteux qu’à la capi­tale, on s’y retrouve rapi­de­ment ; et puis ça vaut large­ment le billet de train, tout simple­ment.

    Il reste des places, prenez votre courage à deux mains et jouez des pieds pour bouger votre employeur afin de vous inscrire.

  • Ce qui me fait aban­don­ner vos pages

    Je suis un bouli­mique du web, je ne consomme pas que ça mais j’en consomme énor­mé­ment.  Poli­tique, tech­nique, travail, diver­tis­se­ment : tous les sujets y passent.

    Je me plains régu­liè­re­ment que certains n’ont rien compris au web et me font fuir. Ça reste souvent instan­tané, je m’en vais, je râle, et j’ou­blie. Afin que ça serve, à moi-même ou à d’autres, voilà quelques unes des diffi­cul­tés régu­lières qui font que je fuis immé­dia­te­ment certains sites :

    Contenu vidéo

    Si le contenu est en vidéo ou en audio, sans trans­crip­tion, je suis inca­pable de le scan­ner rapi­de­ment pour savoir s’il m’in­té­resse vrai­ment, et quand bien même il m’in­té­resse il a toute les chances de me deman­der bien plus de temps qu’un contenu texte (et le temps est ma ressource la plus chère). Même quand je suis convaincu d’être inté­ressé au point d’avoir envie d’y passer du temps, je ne suis pas toujours en contexte où je peux lire une vidéo (bande passante dispo­nible en mobile) ou où je peux l’écou­ter (pas de son au boulot). Au final soit je quitte soit je stocke le lien pour plus tard et je n’y reviens fina­le­ment pas.

    Redi­rec­tion vers la page d’ac­cueil du site mobile

    Je pense à LCI mais pas unique­ment à eux. Si je suis un lien d’ar­ticle à partir de mon télé­phone mobile je suis redi­rigé vers la page d’ac­cueil du site mobile. Impos­sible de retrou­ver l’ar­ticle souhaité et de suivre les liens : c’est un départ immé­diat. C’est plus rare mais l’ex­pé­rience inverse est aussi problé­ma­tique. Au final vous avez une chance sur deux de mal tomber et que le lien parte immé­dia­te­ment à la poubelle.

    Un article en plusieurs sous-pages

    Je ne suis pas sur le web pour mimer les contraintes que j’ai sur papier. Je ne suis pas sur le web pour m’amu­ser à tour­ner les pages. C’est agaçant, j’ai réel­le­ment fuit des sites pour ça. Lais­sez-moi utili­ser l’as­cen­seur de mon navi­ga­teur.

    Un site vrai­ment lent

    Ceux qui me connaissent doivent s’y attendre, pour­tant c’est à dessein que je ne le mets pas dans les premiers critères : Si vos pages sont lentes, je risque bel et bien de repar­tir agacé avant même d’avoir eu l’oc­ca­sion de lire quoi que ce soit. Sur télé­phone portable, même dans le métro avec une mauvaise récep­tion, il est hors de ques­tion d’at­tendre plus de 10 secondes. Sur un poste bureau­tique ne me faites pas attendre la moitié de ça.

    La grosse pop-in

    Si votre contenu commence par être masqué par un gros pop-in, je ne passe­rai jamais à la suite, c’est aban­don immé­diat. Je me fiche que ce soit de la publi­cité, un formu­laire de feed­back ou un message de bien­ve­nue. En fait les deux derniers cas sont presque ceux qui m’agacent le plus de part leur imbé­cil­lité. Je ne ferme­rai pas la pop-in, je parti­rai. C’est encore plus vrai sur mobile où réus­sir à fermer le pop-in est souvent mission impos­sible de toutes façons.

    Des lignes trop longues

    Si vos lignes font plus d’une quin­zaine de mots, elles devien­dront rapi­de­ment pénibles à lire pour moi. Pire, j’au­rai beau­coup de mal à scan­ner la page rapi­de­ment en diago­nale.  Si ça semble futile comme critère, je vous assure que c’est un aban­don systé­ma­tique pour tous les sites qui ont des lignes trop longues. Si vous voulez une mesure, comp­tez une longueur maxi­mum de 45 fois la taille de votre police de carac­tères. Sur mobile c’est encore pire, si votre mise en page m’em­pêche de zoomer sur le texte de façon à ce qu’il tienne dans la largeur de mon télé­phone portable quand je double clique dessus, ça sera telle­ment pénible à lire que je n’es­saie­rai même pas.

    Ça bouge partout

    Vous tenez à la publi­cité et je le comprends, mais si ça bouge, si ça flash, si ça clignote, vous me verrez partir immé­dia­te­ment. Je serai simple­ment inca­pable de fixer mes yeux au bon endroit sans que ce ne soit pénible. Mon œil peut se lais­ser atti­rer hors du contenu une fois, mais la seconde fois je ferme la page. Notez que ça vaut aussi si c’est votre propre contenu promo­tion­nel ou carrou­sel qui attire l’œil et non de la publi­cité. Je ne fais pas de diffé­rence à ce stade là.

    On mélange tout

    Vous avez des publi­ci­tés ou des pavés promo­tion­nels au milieu du contenu, je sais, ça encou­rage les clics. Mais je sais aussi que ça me fera fuir immé­dia­te­ment là aussi. C’est encore plus vrai si j’ai un doute sur la sépa­ra­tion entre promo­tion­nel et rédac­tion­nel. Encore une fois, si je ne suis pas capable de filtrer et repé­rer l’in­for­ma­tion utile au premier coup d’œil, je repars immé­dia­te­ment. Même sans publi­cité, le trop plein d’illus­tra­tions hors contexte (même avec des légendes humo­ris­tiques ou sarcas­tiques) donne le même effet.

    Texte rikiki

    Votre graphiste vous l’a montré, la maquette est quand même bien plus jolie quand c’est écrit petit … sauf que c’est illi­sible, et ça aussi c’est un bloqueur pour moi. Non, 10 pixels de hauteur pour une police ce n’est pas suffi­sant pour moi. Notez qu’à l’in­verse je ne me souviens pas avoir jamais aban­donné un site parce que le texte était trop gros.

    Et si je lis ?

    Si vous avez passé le texte jusque là, bravo, il y a des chances que je lise votre contenu. Un autre jour je vous explique­rai ce qui peut faire qu’a­près la première lecture je ne revienne jamais chez vous.

    Allez, pour la forme j’ajoute ce qui d’après la légende est gênant mais qui pour ma part ne m’a jamais freiné (ou en tout cas pas consciem­ment) : les textes trop longs, le manque d’illus­tra­tion, le trop plein de liens, le tutoie­ment ou le vouvoie­ment, la prise d’opi­nion subjec­tive, les propos « indé­cents », ou les sites person­nels sans répu­ta­tion. Rien de tout ça ne me gêne a priori.

  • How media queries slow the mobile web

    You proba­bly have been told to design with the grace­ful degra­da­tion para­digm. If you have very smart friends, they may even use the « progres­sive enhan­ce­ment » in place of grace­ful degra­da­tion. To enable an opti­mi­zed access to mobile on a website, you proba­bly use css media queries:

    header { background-image: url(head-1280px.png) }
@media screen and (max-device-width: 480px) {
  header { background-image: url(head-480px.png) }
}

    If you’re really smart and don’t care about IE, you may design first for narrow mobiles and then opti­mize all other use cases:

    header { background-image: url(head-320px.png) }
@media screen and (min-device-width: 321px) {
  header { background-image: url(head-480px.png) }
}
@media screen and (min-device-width: 481px) {
  header { background-image: url(head-855px.png) }
}
@media screen and (min-device-width: 856px) {
  header { background-image: url(head-1280px.png) }
}

    Sorry, what you has been told is bull­shit. You are not opti­mi­zing anything. Worse, you are degra­ding all android user expe­rience (and proba­bly some ipho­ne’s ones).

    It’s not your fault, webkit has an horrible bug. It down­loads all appli­cable images, not just the final one. This basi­cally means that down­loa­ding only the big 1280px image may even be chea­per than these alter­na­tives with media queries.

    Yes, it’s sad, but so is the life. The former is true at least up to Android 2.3.2 so the problem won’t disap­pear this year.

    If you ask me, it’s even worse: Brow­sers based on 2010’s webkit and lower (inclu­ding mobile ones) don’t need any media query to be slowed down. You just need the follo­wing to down­load two images instead of one.

    p { background-image: url(useless.png); }
p { background-image: url(usefull.png); }

    There are only three solu­tions

    1. Push the fix on Android (still not there in 2.3.2) and upgrade to the latest firm­ware (not only on your own mobile, but on everyo­ne’s)
    2. Use the same images for all devices and screen widths AND don’t use the cascade to over­ride previous back­ground-image rules in your style­sheets
    3. Wrap every back­ground-image rule in a media query and define min and max constraints for each media query so that a device never read more than one block (this mean you will never support IE without CSS hacks) AND don’t use the cascade to over­ride previous back­ground-image rules in your style­sheets