Pour mes propres archives : Quand on veut indexer un paquet d’e-mail, Notmuch semble plus qu’efficace pour les recherches. À retenir un jour où je souhaite sortir de Gmail.
Catégorie : Technique
-
Comment rentabiliser la mauvaise qualité
Que faire quand le réseau sature et qu’on livre un service de mauvaise qualité ? Les geeks irresponsables diront qu’il faut investir dans l’infrastructure réseau. Les commerciaux de nos fournisseurs d’accès sont bien plus astucieux : Il suffit de faire payer un accès prioritaire à quelques heureux élus.
La solution est miraculeuse : Au lieu de dépenser on gagne des sous. Pire, on peut affirmer à ceux qui subissent la mauvaise qualité, que c’est finalement de leur faute – ils ne payent pas l’option – et pas celle du fournisseur.
C’est encore Free qui fait parler de lui en imaginant faire payer un accès prioritaire au catch-up TV. Pourtant il est clair que sur ce chapitre seul Free est responsable des éventuels ralentissements. Ce n’est pas une nouveauté, les dirigeants de Free ont très bien compris la stratégie du pourrissement et l’idée qu’une mauvaise qualité c’est une source de revenu. La seule différence avec l’histoire de Youtube c’est qu’elle concernait l’autre côté du réseau (les fournisseurs et non les clients).
Il serait peut être temps que nos régulateurs mettent leur grain de sel pour définir ce qui est le niveau de qualité attendu (ou au moins imposer une mesure de qualité publique pour que chacun fasse son choix en connaissance de cause).
-
Paliers de responsive design
Et si nous dépassions les positions de principe ?
Pour faire une mise en page web « responsive », des gens biens me déconseillent de me servir des tailles des différents appareils pour imaginer les paliers sur lesquels modifier l’agencement. L’idée est de travailler sur le contenu et d’imaginer ce qui est le plus pertinent pour le contenu, indépendamment des appareils sur le marché, qui vont de toutes façons évoluer.
Oui, ok, en théorie. Maintenant il est temps de travailler la pratique.
Je peux faire une optimisation ou un nouvel agencement à chaque fois que l’espace disponible me permet d’apporter un peu de valeur ajoutée. Je finirai avec une multitude de paliers différents. Certains me demanderont du temps, peut être beaucoup, alors qu’ils ne représentent quasiment aucun visiteur. Autant dire que j’aurai perdu du temps.
À l’inverse, je peux prévoir uniquement quelques paliers principaux et laisser les marges ou tailles s’adapter parce que mon contenu le permet. Ce sera correct et lisible partout mais peut être que tel ou tel type d’appareil représente beaucoup de visiteurs et qu’un palier ou qu’une optimisation supplémentaire aurait apporté un retour sur investissement significatif.
Au final je vais devoir faire des choix de palier non seulement en fonction de mon contenu, de l’ergonomie visée et du temps disponible, mais aussi en fonction des visiteurs et de leur matériel. C’est une classique question de retour sur investissement, de ratio entre la valeur ajoutée et l’investissement nécessaire : Je veux que ce soit correct partout, mais je veux concenter mes efforts supplémentaires là où c’est le plus utile et visible.
Même sans toucher au nombre de paliers, l’ergonomie et les contenus ne dictent pas toujours un palier très précis. Je peux finalement viser un peu plus tôt ou un peu plus tard sans que ça ne change grand chose, j’apporterai juste une solution légèrement différente. Tel ou tel appareil risque de se retrouver proche d’un palier et avoir connaissance de cette proximité me permet un quick-win au niveau de la valeur ajoutée qu’il serait dommage de rater.
Bien évidemment c’est une réflexion qui dépend en partie des appareils, de la répartition des utilisateurs et des prévisions tels que nous en disposons aujourd’hui. Cela peut changer, et cela changera. Si je prends correctement en compte le design et l’ergonomie alors le rendu restera correct. Peut être pas autant optimisé qu’au départ, mais pas moins bon que si je ne prends pas du tout en compte les appareils et utilisateurs au départ.
-
Quelques outils pour simplifier github
Pour mes propres archives, et pour ceux qui ne connaissent pas encore, github met à disposition deux outils pour simplifier les interactions :
Le premier c’est github pour mac, une interface graphique simpliste mais efficace 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 utilisation naive. Le bonus ce sont les notifications d’activité qui passent alors dans le système d’alerte intégré d’OS X.
Le second c’est hub, un remplacement de la commande git pour les adeptes de la ligne de commande. On ajoute simplement quelques simplifications de commandes. Rien d’indispensable, mais de quoi éviter de réfléchir quand on bosse avec github : utiliser les couples utilisateur/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 Committed (pour Mac OS X là aussi)
Naholyr a aussi un petit script pour gérer les pull request, en surcouche à hub.
-
Joyeux effets javascript – file upload et Twitter bootstrap
Les gens compétents se déchaînent et on voit maintenant apparaitre des choses que nous aurions à peine imaginé du temps où j’étais intégrateur web. Nous étions capable de créer tel ou tel composant, mais en créant tout de zéro ou presque. Désormais des bibliothèques pré-existantes donnent un coup d’accélérateur gigantesque.
Aujourd’hui je suis retombé sur le téléchargement de fichiers, et les exemples du bootstrap proposé sont plus que convaincants. Le menu à gauche pour gérer le positionnement dans la page est lui aussi une très bonne idée bien implémentée.
Je ne peux cependant pas m’empêcher de me poser la question de la charge en terme de performance quand on utilise plusieurs composants. Rien que baser tout ça sur jquery risque de faire mal côté mobile.
-
Les rayures de la webperf
Jeudi confession : Quand je vois un orateur français faire une intervention publique au sujet de la performance web, j’ai encore parfois l’impression qu’il usurpe ma place. Oh, je ne le pense pas, mais il y a parfois le petit pincement, un peu comme si le sujet était mon bébé.
Je vous propose un petit jeu : Si vous intervenez sur un sujet performances des sites web, mettez un vêtement à rayures (horizontales les rayures), publiez une photo dans le groupe flickr dédié et faites un lien dans les commentaires ci-dessous avec le contexte. Conférences, ateliers, formations, même avant-ventes si ça vous amuse : tout le monde peut jouer.
Si vous croisez des intervenants qui ne jouent pas, tentez de les convaincre. Ceux qui ont d’anciennes photo qui correspondent peuvent jouer aussi.
-
Ignore the fold
À contre-courant des habitudes des divisions de web marketing : Ignore the fold.
Et si au lieu de bourrer l’information de façon à ce que l’utilisateur n’ait pas à faire défiler la page, il fallait l’aérer pour que l’action désormais naturelle de défiler ne soit plus l’obstacle à des mises en pages efficaces ?
Je suis preneur de plus de ressources à ce sujet si vous en avez. Le lien donné correspond assez à mon expérience en tant qu’utilisateur.
-
La fin des carrousels
Oui, ils semblent une superbe idée pour fournir plus de propositions à l’internaute, mais ajouter un carrousel est généralement une mauvaise idée. Le carrousel tue le taux de conversion.
D’autres ont détaillé la question bien mieux que moi alors si vous voulez suivre les études, les tests utilisateurs ou les statistiques de conversion, suivez un des liens en bas du billet. Pour ceux qui veulent un résumé :
- Ça ressemble à un élément très graphique, qui bouge, souvent avec des promotions ou messages publicitaires, c’est donc traité visuellement par l’internaute comme de la publicité, et ignoré inconsciemment. Ce que vous mettez dans le carrousel est ce qui a le plus de chances de ne *pas* être suivi.
- Sans que ça ne soit contradictoire avec le point précédent, l’oeil humain fonctionne par comparaison. Ce qui bouge attire l’oeil et empêche de se concentrer ailleurs. Le carrousel bouge et en plus de ne pas être efficace en lui-même, il empêchera le reste de la page de l’être.
- Trop souvent mal fait il pose de problèmes de performance sur l’appareil client, et des problèmes d’ergonomie si jamais le client souhaite l’utiliser.
Au final il apparait que le carrousel est surtout une bonne idée pour l’éditeur du site, ses équipes commerciales et marketing, de façon à ne pas choisir ce qui doit vraiment être mis en avant. Sa seule valeur ajoutée c’est de contenter l’organisation 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’opinion, il y a des vrais tests utilisateurs et des chiffres de conversion derrière.
Si vous souhaitez tout de même un carrousel :
- C’est pour une information non secondaire (une gallerie d’illustrations par exemple)
- Un carrousel = un seul type d’information
- Il doit être navigable au clavier et en tactile, et les zones de navigation clavier doivent être en dehors de la zone du carrousel
- La position courante doit être explicite, et si possible utilisez des miniatures pour mieux identifier les différents items du carrousel
- Chargez le code nécessaire à l’animation et les éléments non visibles en asynchrone, ne ralentissez pas l’accès à la page
Quelques liens :
-
Les développeurs sont des créatifs
À ne pas (faire) oublier : Les développeurs sont des créatifs, pas des ouvriers.
C’est vrai pour tous, sans exceptions, même pour ceux qu’on fait travailler à la chaîne dans les mauvaises sociétés de service en ingénierie informatique. 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 multiplicité des paramètres pris en comptes, mais bien parce qu’ils inventent les solutions.
Inventer c’est le propre du créatif. Le développeur en fait l’essentiel de son activité. Il ne s’agit pas que d’une lubie : C’est l’essentiel du travail du développeur qui est couvert par le droit d’auteur, des spécifications au code logiciel. Peu de métiers hors des beaux arts peuvent en dire autant, même dans la recherche.
Bref, n’oublions pas que nous avons à faire avec des créatifs. Un planning de réalisation n’a aucun sens, et un planning de création a un sens tout à fait différent. L’environnement, le recrutement, les attentes doivent être adaptés à la création.
-
Estimation is evil
Peut être est-ce du à mon incapacité flagrante à sortir de bonne estimations, mais je suis convaincu que l’exercice est des plus nocifs. Je conçois le développement comme une activité créative, avec des problèmes qui sont largement inconnus et des besoins qui sont à peine effleurés.
Estimation is evil, chez pragprog.
Soit on fait semblant, soit on accepte que les estimations soient en permanence fausses, soit on tient les estimations. La dernière option implique forcément une astuce bien connue : c’est la qualité qui trinque. C’est l’option des SSII, mais elle me parait difficilement tenable en interne à une société.
Le problème c’est que le business a besoin d’avoir des dates et de les communiquer. Passer du « produire ce qu’on vend » au « vendre ce qu’on produit » est loin d’être simple. L’équilibre du nécessaire compromis est parfois difficile à trouver.