Carnet de notes

Catégorie : Technique

  • Comment renta­bi­li­ser la mauvaise qualité

    Que faire quand le réseau sature et qu’on livre un service de mauvaise qualité ? Les geeks irres­pon­sables diront qu’il faut inves­tir dans l’in­fra­struc­ture réseau. Les commer­ciaux de nos four­nis­seurs d’ac­cès sont bien plus astu­cieux : Il suffit de faire payer un accès prio­ri­taire à quelques heureux élus.

    La solu­tion est mira­cu­leuse : Au lieu de dépen­ser on gagne des sous. Pire, on peut affir­mer à ceux qui subissent la mauvaise qualité, que c’est fina­le­ment de leur faute – ils ne payent pas l’op­tion – et pas celle du four­nis­seur.

    C’est encore Free qui fait parler de lui en imagi­nant faire payer un accès prio­ri­taire au catch-up TV. Pour­tant il est clair que sur ce chapitre seul Free est respon­sable des éven­tuels ralen­tis­se­ments. Ce n’est pas une nouveauté, les diri­geants de Free ont très bien compris la stra­té­gie du pour­ris­se­ment et l’idée qu’une mauvaise qualité c’est une source de revenu. La seule diffé­rence avec l’his­toire de Youtube c’est qu’elle concer­nait l’autre côté du réseau (les four­nis­seurs et non les clients).

    Il serait peut être temps que nos régu­la­teurs mettent leur grain de sel pour défi­nir ce qui est le niveau de qualité attendu (ou au moins impo­ser une mesure de qualité publique pour que chacun fasse son choix en connais­sance de cause).

  • Paliers de respon­sive design

    Et si nous dépas­sions les posi­tions de prin­cipe ?

    Pour faire une mise en page web « respon­sive », des gens biens me décon­seillent de me servir des tailles des diffé­rents appa­reils pour imagi­ner les paliers sur lesquels modi­fier l’agen­ce­ment. L’idée est de travailler sur le contenu et d’ima­gi­ner ce qui est le plus perti­nent pour le contenu, indé­pen­dam­ment des appa­reils sur le marché, qui vont de toutes façons évoluer.

    Oui, ok, en théo­rie. Main­te­nant il est temps de travailler la pratique.

    Je peux faire une opti­mi­sa­tion ou un nouvel agen­ce­ment à chaque fois que l’es­pace dispo­nible me permet d’ap­por­ter un peu de valeur ajou­tée. Je fini­rai avec une multi­tude de paliers diffé­rents. Certains me deman­de­ront du temps, peut être beau­coup, alors qu’ils ne repré­sentent quasi­ment aucun visi­teur. Autant dire que j’au­rai perdu du temps.

    À l’in­verse, je peux prévoir unique­ment quelques paliers prin­ci­paux et lais­ser les marges ou tailles s’adap­ter parce que mon contenu le permet. Ce sera correct et lisible partout mais peut être que tel ou tel type d’ap­pa­reil repré­sente beau­coup de visi­teurs et qu’un palier ou qu’une opti­mi­sa­tion supplé­men­taire aurait apporté un retour sur inves­tis­se­ment signi­fi­ca­tif.

    Au final je vais devoir faire des choix de palier non seule­ment en fonc­tion de mon contenu, de l’er­go­no­mie visée et du temps dispo­nible, mais aussi en fonc­tion des visi­teurs et de leur maté­riel. C’est une clas­sique ques­tion de retour sur inves­tis­se­ment, de ratio entre la valeur ajou­tée et l’in­ves­tis­se­ment néces­saire : Je veux que ce soit correct partout, mais je veux concen­ter mes efforts supplé­men­taires là où c’est le plus utile et visible.

    Même sans toucher au nombre de paliers, l’er­go­no­mie et les conte­nus ne dictent pas toujours un palier très précis. Je peux fina­le­ment viser un peu plus tôt ou un peu plus tard sans que ça ne change grand chose, j’ap­por­te­rai juste une solu­tion légè­re­ment diffé­rente. Tel ou tel appa­reil risque de se retrou­ver proche d’un palier et avoir connais­sance de cette proxi­mité me permet un quick-win au niveau de la valeur ajou­tée qu’il serait dommage de rater.

    Bien évidem­ment c’est une réflexion qui dépend en partie des appa­reils, de la répar­ti­tion des utili­sa­teurs et des prévi­sions tels que nous en dispo­sons aujourd’­hui. Cela peut chan­ger, et cela chan­gera. Si je prends correc­te­ment en compte le design et l’er­go­no­mie alors le rendu restera correct. Peut être pas autant opti­misé qu’au départ, mais pas moins bon que si je ne prends pas du tout en compte les appa­reils et utili­sa­teurs au départ.

  • Quelques outils pour simpli­fier github

    Pour mes propres archives, et pour ceux qui ne connaissent pas encore, github met à dispo­si­tion deux outils pour simpli­fier les inter­ac­tions :

    Le premier c’est github pour mac, une inter­face graphique simpliste mais effi­cace pour gérer les dépôts, commit et branches. Ça ne fait pas le café mais ça fait la base utile pour ceux qui ont une utili­sa­tion naive. Le bonus ce sont les noti­fi­ca­tions d’ac­ti­vité qui passent alors dans le système d’alerte inté­gré d’OS X.

    Le second c’est hub, un rempla­ce­ment de la commande git pour les adeptes de la ligne de commande. On ajoute simple­ment quelques simpli­fi­ca­tions de commandes. Rien d’in­dis­pen­sable, mais de quoi éviter de réflé­chir quand on bosse avec github : utili­ser les couples utili­sa­teur/projet dans la ligne de commande, créer une branche à partir d’une pull request, initier un fork, lancer une pull request, etc.

    Côté alertes pour les diffé­rents commits d’un projet, il y a aussi Commit­ted (pour Mac OS X là aussi)

    Naho­lyr a aussi un petit script pour gérer les pull request, en surcouche à hub.

  • Joyeux effets javas­cript – file upload et Twit­ter boots­trap

    Les gens compé­tents se déchaînent et on voit main­te­nant appa­raitre des choses que nous aurions à peine imaginé du temps où j’étais inté­gra­teur web. Nous étions capable de créer tel ou tel compo­sant, mais en créant tout de zéro ou presque. Désor­mais des biblio­thèques pré-exis­tantes donnent un coup d’ac­cé­lé­ra­teur gigan­tesque.

    Aujourd’­hui je suis retombé sur le télé­char­ge­ment de fichiers, et les exemples du boots­trap proposé sont plus que convain­cants. Le menu à gauche pour gérer le posi­tion­ne­ment dans la page est lui aussi une très bonne idée bien implé­men­tée.

    Je ne peux cepen­dant pas m’em­pê­cher de me poser la ques­tion de la charge en terme de perfor­mance quand on utilise plusieurs compo­sants. Rien que baser tout ça sur jquery risque de faire mal côté mobile.

  • Les rayures de la webperf

    Jeudi confes­sion : Quand je vois un orateur français faire une inter­ven­tion publique au sujet de la perfor­mance web, j’ai encore parfois l’im­pres­sion qu’il usurpe ma place. Oh, je ne le pense pas, mais il y a parfois le petit pince­ment, un peu comme si le sujet était mon bébé.

    Je vous propose un petit jeu : Si vous inter­ve­nez sur un sujet perfor­mances des sites web, mettez un vête­ment à rayures (hori­zon­tales les rayures), publiez une photo dans le groupe flickr dédié et faites un lien dans les commen­taires ci-dessous avec le contexte. Confé­rences, ateliers, forma­tions, même avant-ventes si ça vous amuse : tout le monde peut jouer.

    Si vous croi­sez des inter­ve­nants qui ne jouent pas, tentez de les convaincre. Ceux qui ont d’an­ciennes photo qui corres­pondent peuvent jouer aussi.

  • Ignore the fold

    À contre-courant des habi­tudes des divi­sions de web marke­ting : Ignore the fold.

    Et si au lieu de bour­rer l’in­for­ma­tion de façon à ce que l’uti­li­sa­teur n’ait pas à faire défi­ler la page, il fallait l’aé­rer pour que l’ac­tion désor­mais natu­relle de défi­ler ne soit plus l’obs­tacle à des mises en pages effi­caces ?

    Je suis preneur de plus de ressources à ce sujet si vous en avez. Le lien donné corres­pond assez à mon expé­rience en tant qu’u­ti­li­sa­teur.

  • La fin des carrou­sels

    Oui, ils semblent une superbe idée pour four­nir plus de propo­si­tions à l’in­ter­naute, mais ajou­ter un carrou­sel est géné­ra­le­ment une mauvaise idée. Le carrou­sel tue le taux de conver­sion.

    D’autres ont détaillé la ques­tion bien mieux que moi alors si vous voulez suivre les études, les tests utili­sa­teurs ou les statis­tiques de conver­sion, suivez un des liens en bas du billet. Pour ceux qui veulent un résumé :

    1. Ça ressemble à un élément très graphique, qui bouge, souvent avec des promo­tions ou messages publi­ci­taires, c’est donc traité visuel­le­ment par l’in­ter­naute comme de la publi­cité, et ignoré incons­ciem­ment. Ce que vous mettez dans le carrou­sel est ce qui a le plus de chances de ne *pas* être suivi.
    2. Sans que ça ne soit contra­dic­toire avec le point précé­dent, l’oeil humain fonc­tionne par compa­rai­son. Ce qui bouge attire l’oeil et empêche de se concen­trer ailleurs. Le carrou­sel bouge et en plus de ne pas être effi­cace en lui-même, il empê­chera le reste de la page de l’être.
    3. Trop souvent mal fait il pose de problèmes de perfor­mance sur l’ap­pa­reil client, et des problèmes d’er­go­no­mie si jamais le client souhaite l’uti­li­ser.

    Au final il appa­rait que le carrou­sel est surtout une bonne idée pour l’édi­teur du site, ses équipes commer­ciales et marke­ting, de façon à ne pas choi­sir ce qui doit vrai­ment être mis en avant. Sa seule valeur ajou­tée c’est de conten­ter l’or­ga­ni­sa­tion interne.

    Bien entendu tout ceci est géné­ral, mais parce que c’est le cas géné­ral, il y a peu de chances que votre cas soit diffé­rent, malgré votre volonté d’y croire. Tout ceci n’est pas de l’opi­nion, il y a des vrais tests utili­sa­teurs et des chiffres de conver­sion derrière.

    Si vous souhai­tez tout de même un carrou­sel :

    • C’est pour une infor­ma­tion non secon­daire (une galle­rie d’illus­tra­tions par exemple)
    • Un carrou­sel = un seul type d’in­for­ma­tion
    • Il doit être navi­gable au clavier et en tactile, et les zones de navi­ga­tion clavier doivent être en dehors de la zone du carrou­sel
    • La posi­tion courante doit être expli­cite, et si possible utili­sez des minia­tures pour mieux iden­ti­fier les diffé­rents items du carrou­sel
    • Char­gez le code néces­saire à l’ani­ma­tion et les éléments non visibles en asyn­chrone, ne ralen­tis­sez pas l’ac­cès à la page

    Quelques liens :

  • Les déve­lop­peurs sont des créa­tifs

    À ne pas (faire) oublier : Les déve­lop­peurs sont des créa­tifs, pas des ouvriers.

    C’est vrai pour tous, sans excep­tions, même pour ceux qu’on fait travailler à la chaîne dans les mauvaises socié­tés de service en ingé­nie­rie infor­ma­tique. Même ceux là, s’ils ne sont pas remplaçables par des robots, ce n’est pas en raison de la complexité des choix qu’ils prennent, de la multi­pli­cité des para­mètres pris en comptes, mais bien parce qu’ils inventent les solu­tions.

    Inven­ter c’est le propre du créa­tif. Le déve­lop­peur en fait l’es­sen­tiel de son acti­vité. Il ne s’agit pas que d’une lubie : C’est l’es­sen­tiel du travail du déve­lop­peur qui est couvert par le droit d’au­teur, des spéci­fi­ca­tions au code logi­ciel. Peu de métiers hors des beaux arts peuvent en dire autant, même dans la recherche.

    Bref, n’ou­blions pas que nous avons à faire avec des créa­tifs. Un plan­ning de réali­sa­tion n’a aucun sens, et un plan­ning de créa­tion a un sens tout à fait diffé­rent. L’en­vi­ron­ne­ment, le recru­te­ment, les attentes doivent être adap­tés à la créa­tion.

  • Esti­ma­tion is evil

    Peut être est-ce du à mon inca­pa­cité flagrante à sortir de bonne esti­ma­tions, mais je suis convaincu que l’exer­cice est des plus nocifs. Je conçois le déve­lop­pe­ment comme une acti­vité créa­tive, avec des problèmes qui sont large­ment incon­nus et des besoins qui sont à peine effleu­rés.

    Esti­ma­tion is evil, chez prag­prog.

    Soit on fait semblant, soit on accepte que les esti­ma­tions soient en perma­nence fausses, soit on tient les esti­ma­tions. La dernière option implique forcé­ment une astuce bien connue : c’est la qualité qui trinque. C’est l’op­tion des SSII, mais elle me parait diffi­ci­le­ment tenable en interne à une société.

    Le problème c’est que le busi­ness a besoin d’avoir des dates et de les commu­niquer. Passer du « produire ce qu’on vend » au « vendre ce qu’on produit » est loin d’être simple. L’équi­libre du néces­saire compro­mis est parfois diffi­cile à trou­ver.

  • Soin et alimen­ta­tion des ingé­nieurs infor­ma­tique (ou pourquoi les ingé­nieurs sont grin­cheux)

    Je ne suis pas d’ac­cord avec tout, mais le pourquoi les ingé­nieurs sont grin­cheux est à recom­man­der à tous les mana­gers ou direc­teurs qui ne viennent pas du déve­lop­pe­ment et qui peuvent avoir à faire même indi­rec­te­ment à une équipe tech­nique infor­ma­tique. Ça donne une première mise en contexte de certaines choses. Ensuite il reste à expliquer la culture parti­cu­lière du milieu, et l’at­ta­che­ment d’une partie de la commu­nauté à des valeurs très spéci­fiques (d’ailleurs rien que le fait de parler de commu­nau­té… parle-t-on de commu­nauté pour les comp­tables ?).

    Il faudrait presque écrire un livre. Je me suis rendu compte que servir d’in­ter­prète et de guide dans le monde des déve­lop­peurs était fina­le­ment une partie de mon métier de direc­teur tech­nique. C’est assez diffi­cile, peut être aussi parce que je suis fonciè­re­ment *dans* cette commu­nauté et atta­ché à ses parti­cu­la­ri­tés.