• Journée de code sur Flip-Zone. J’ai passé les plus gros scripts de traitement d’image, qui tournaient avec les fonctions intégrées à #SPIP, en ligne de commande dans #ImageMagick.

    Sur ce site, j’ai depuis belle lurette des scripts qui fabriquent automatiquement des « couvertures » façon magazine, avec le logo du site qui passe derrière la tête du mannequin. Et j’en fait une série de variantes. Par exemple sur cette page :
    http://www.flip-zone.net/fashion/ready-to-wear/fashion-houses-42/maison-martin-margiela-5210
    j’ai la première page du portfolio, avec une grande image (944x600) et le logo « Flip-Zone », couleur violet-éteint, et en dessous des vignettes verticales (pour les autres collections de la même maison), et en fin de page, des vignettes horizontales pour les collections de la même saison.

    L’automatisme de la Une, c’est :
    – prendre l’image de fond,
    – lui appliquer des dégradés à gauche et à droite vers la couleur de fond, ce qui donne l’impression d’un grand bandeau horizontal, avec la pub à droite,
    – coloriser le logo dans la couleur qui va bien, le mettre à la bonne taille, et l’appliquer centré en haut d’image,
    – coller par dessus l’image du mannequin détouré, qui est un fichier PNG (donc avec couche alpha).

    Jusque là, tout était réalisé en fonctions de traitement d’image de SPIP, c’est souple et très lisible à maintenir. Sauf que j’arrive un peu aux limites :
    – ça fabrique tout de même pas mal de fichiers intermédiaires,
    – je commence à saturer le disque dur du serveur (600 Go),
    – au premier calcul, ça bouffe des ressources folles – quand j’efface local/cache-gd, le site met au moins 24 heures avant de commencer à re-fonctionner à peu près et à servir des pages, tellement il est pris par les calculs,
    – et comme je veux que ces images puissent maintenant être aussi en haute définition, j’allais accentuer ces problèmes.

    Bref, j’ai décidé aujourd’hui de court-circuiter GD et de directement tenter de coder ça en ligne de commande d’ImageMagick. La commande elle-même se construit en PHP dans SPIP, ce qui me permet d’avoir des variables tirées de SPIP (telles que les couleurs, converties en RGBA avec |couleur_rgba, les dimensions de l’image…

    Et au final, toute la procédure se fait en une unique ligne de convert, plus aucune image intermédiaire fabriquée (ni stockée), et c’est invraisemblablement rapide.

    Bon, ça pique un peu les yeux, mais voici ce que ça donne :

    convert IMG/arton4091.jpg \( -size 1047x824 gradient:'rgba(171,218,226,1)'-'rgba(171,218,226,0)' -rotate 90 \) \
        -gravity East -composite \
        \( -size 1047x330 gradient:'rgba(171,218,226,1)'-'rgba(171,218,226,0)' -rotate -90 \) \
        -gravity West -composite \
        \( squelettes/imgs/flip-zone-big.png +level-colors 'rgba(54,168,200,1)' -resize 1483 \) \
        -gravity North -geometry +0+70 -composite \ IMG/artoff4091.png -composite local/cache-sommaire/b/b0f831ae954ee943f5eac89fab0d9bfc.jpg
    • Pour info : j’ai finalement totalement effacé le cache d’images (effacé /local) pour voir ce que ça donne, et le site est redevenu totalement fonctionnel en moins d’une heure. (Auparavant, ça prenait au moins 24 heures avant de pouvoir réafficher la moindre page, et 48 heures pour cesser d’avoir des ralentissements.)

  • Avec un peu de retard, j’ai finalement installé mes photos du backstage du défilé Yulia Yanina.
    http://www.flip-zone.net/fashion/backstage/backstage-people/yulia-yanina-4843

    Les photos d’origine sont beaucoup plus sombres, j’ai décidé de les traiter à la limite du high-key.

    Il y a deux photos que j’aime particulièrement :
    https://www.flickr.com/photos/parisbeyrouth/14755805682

    Flickr

    https://www.flickr.com/photos/parisbeyrouth/14569437020
    Flickr

  • Quelques nouveautés pour mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Que l’on utilise par exemple ainsi :

    [(#LOGO_ARTICLE_NORMAL|image_responsive{160})]

    ou :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{160,0})]

    ou :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{0,0})]

    Comme il fonctionne bien, je l’ai désormais systématisé sur Flip-Zone :
    http://www.flip-zone.net
    Si l’on affiche le site avec plusieurs tailles d’écran, on pourra voir que les images qui sont chargées sont de tailles différentes.

    Les deux nouveautés :

    – la première variable désigne la taille de l’image par défaut ; a priori, on choisit la taille minimale d’affichage (sur mobile) ; on peut désormais fixer cette valeur à 0, et dans ce cas l’image par défaut sera « rien.gif » ; au chargement de la page, donc, rien ne se déclenche, on ne charge les images que via javascript. C’est pratique si, comme sur Flip-Zone, on peut avoir des dizaines d’images sur la page ; dans ce cas, limiter le nombre de hits est sensible.

    – la seconde variable est optionnelle, et la seule option est de la mettre à zéro. Si on la fixe a zéro, cela signifie qu’on ne chargera pas les images en haute définition (écran Retina…). En effet, l’intérêt des images responsive est double : (a) charger l’image en fonction de la maquette dans laquelle elle s’affiche à l’écran (selon la taille de l’écran, une image s’affichera par exemple sur 70 pixels de large, 160 ou 524 pixels…) ; (b) charger une image de double définition si on détecte qu’on est sur un écran haute définition (dans ce cas, on a une maquette qui affiche l’image sur « 70 » pixels, mais on affiche une image de 140 pixels puisqu’il y a deux fois plus de points affichés).

    Les deux objectifs sont parfois contradictoires :
    – le point (a) permet de limiter la taille des images chargées sur petit écran,
    – le point (b) force à charger une image deux fois plus larges, donc avec 4 fois plus de pixels, sur affichage à haute définition (souvent des smartphone…).

    Du coup, on peut décider que certaines images se chargent à leur taille d’affichage, mais sans prendre en compte le fait qu’on est sur écran haute définition. Le but du plugin dans ce cas est, essentiellement, d’accélérer l’affichage sur le site.

    Sur Flip-Zone, toutes les vignettes de navigation, qui sont des images, restent en définition normale ; certes ça se voit, mais comme ce sont des photos, je pense que c’est très acceptable vu le poids gagné sur smartphone (la situation de connexion la pire). En revanche, le logo du site, lui, se charge en haute définition sur écran haute déf… parce que c’est une image qui n’est pas très lourde, et parce que c’est un lettrage, dont l’affichage est très sensible à la haute définition.

  • Nouveau constat étonnant des stats de http://www.lebanese-fashion.com, qui est essentiellement visité dans les pays du Golfe :
    – 34% sur ordinateur de bureau
    – 21% sur tablette
    – 45% sur téléphone

    Par ailleurs, la durée des visites est quasiment identique sur ordinateur et sur tablette, mais deux fois plus courte sur téléphone. Ça peut être lié au site, mais aussi au mode de consultation sur téléphone.

    La prépondérance des téléphones est vraiment très étonnante. Du coup, j’avais surtout bossé l’aspect responsive à destination des tablettes, mais il va vraiment falloir que j’en mette une nouvelle couche pour améliorer la consultation sur téléphone.

    Pour que tu voies la différence, le même site en anglais, http://www.flip-zone.net, a une répartition très différente :
    – 65% sur ordinateur de bureau
    – 20% sur téléphone
    – 15% sur tablette.

    • Pour la pub de chez Google, au clic en tout cas, c’est très très nettement ordinateur. Tous sites confondus, répartition du revenu :
      – 68% ordinateur
      – 25% tablette
      – 7% smartphones.

      La plus grosse différence, c’est le taux de clic :
      – 0,83% du ordinateur,
      – 2,33% sur tablette (c’est assez invraisemblable)
      – 0,58% sur smartphone.

      Mais je n’ai pas les chiffres spécifiquement pour les pays du Golfe, alors je ne peux pas directement tirer de conclusions sur l’Arabie séoudite en particulier (là où j’ai une invraisemblable proportion de consultations sur téléphone).

      Après, pourquoi il y a un taux de clic aussi élevé sur tablette, et aussi faible sur smartphone, je ne peux pas savoir si c’est lié au profil et la situation des usagers, donc plus ou moins intrisèque au support, ou si c’est surtout lié à l’interface du site selon les écrans, donc plus lié au site lui-même.

  • Un nouveau #plugin pour #SPIP, destiné à gérer des images en #responsive : Image Responsive
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Le plugin est actuellement installé sur Orient XXI :
    http://orientxxi.info

    Pour se faire une idée des problématiques :
    http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution

    Aucune des solutions évoquées ne me plaît, et je me suis dit qu’on a déjà dans SPIP ce qu’il faut pour s’en sortir, du coup voici une solution qui me semble intéressante.

    Notez que je suis particulièrement intéressé, ici, par des retours et des commentaires. C’est une solution très expérimentale (je l’ai codée aujourd’hui), et comme elle est du coup directement intégrée à SPIP, je pense que c’est une piste très intéressante à développer.

    Le problème à résoudre :
    – en responsive, selon la taille de l’écran, une image va s’afficher en différentes tailles ; sur la page d’accueil d’Orient XXI, c’est même très important (une même image s’affiche sur 160 pixels de large ou 460 pixels de large selon l’écran) ;
    – de plus, sur un écran haute définition, il faudrait afficher des images encore deux fois plus grandes.

    Du coup, dès qu’on commence à faire du design responsive, on a tendance à charger des images plus lourdes que ce qu’on va réellement afficher. Et ça commence à peser sur une connexion mobile pourrie.

    Noter que c’est un aspect désormais lourdement pénalisé par le calcul du PageSpeed.

    Ma solution avec ce plugin :
    – on fait passer une image (ou, si je ne me suis pas raté, un texte complet contenant plusieurs images) par le filtre |image_responsive{120}
    – cela va modifier le tag <img> :
    + le src va appeler une version réduite de l’image (ici, à 120 pixels de large),
    + l’image d’origine (celle qui est donc dans la version initiale du src) est stockée dans un data-src
    + j’ajoute une classe « image_responsive » à l’image.

    Initialement, quand on charge la page, on va charger une version déjà réduite de l’image et, idéalement, on indiquera la taille d’affichage pour smartphone.

    Une feuille de style est associée au plugin, qui force l’affichage de toutes les images de classe .image_responsive à 100% de la largeur. Attention, c’est le point vraiment important et un peu contraignant : c’est le conteneur de l’image (par exemple un <span class="logo"><img></span>) qui va déterminer la largeur d’affichage de l’image, parce que de toute façon l’image sera affichée sur 100% de cet espace. (La feuille de style va donc styler .logo éventuellement de manière responsive…)

    Une fois la page chargée, un javascript va scanner chaque .images_responsive, récupérer la largeur à laquelle elle est affichée, éventuellement multiplier par la densité de l’écran (2 pour un écran retina), et remplacer l’image par la version de cette nouvelle largeur.

    On charge donc une vignette, puis on remplace par une version de l’image à la taille exacte d’affichage.

    L’idée c’est de faire du responsive, pas du fluide. Si votre image peut s’afficher en 1000 largeurs différentes, ce plugin va finir par fabriquer 1000 fichiers graphiques différents, ce qui n’est pas forcément génial…

    – Assez simplement, là où mettait un [(#LOGO_ARTICLE_NORMAL|image_reduire{320})]
    on met maintenant un :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{120})]
    (en considérant, par exemple, que 120 est la taille d’affichage usuelle de cette vignette sur un smartphone).
    Le reste des automatismes du système se charge automatiquement via le #INSERT_HEAD, donc il n’y a rien à faire, si ce n’est vérifier que les CSS sont adaptées pour forcer le dimensionnement du conteneur de l’image plutôt que l’image elle-même.

    – Important : si votre site repose sur le .htaccess (URL sans query string), il faut absolument y insérer une ligne supplémentaire. Cela permet de traiter les images derrière des URL de fichiers JPG, ce qui devrait faciliter les mises en cache.

    Avec ça, le score PageSpeed de la page d’accueil d’Orient XXI est passée de 76/100 à 94/100. Et l’impression de vitesse sur smartphone est très très nettement améliorée.

  • Je viens d’installer sur #spip-zone un #plugin #SPIP que j’utilise systématiquement pour mes sites en #HTML5 et #responsive : HTML5 responsive
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/html5_responsive

    Il s’agit d’une petite trousse à outil des choses dont j’ai systématiquement besoin lors du démarrage de squelettes HTML5 et responsive. (Si on ne veut pas faire de responsive, ce n’est pas une bonne idée d’installer ce plugin.)

    Une fois activé, le plugin ajoute directement ce qu’il faut dans #INSERT_HEAD, il n’y a rien à faire de spécifique dans les squelettes.

    – D’abord, intégration de html5shiv (pour activer la prise en compte des balises HTML5 par internet explorer), et de css3-mediaqueries (pour la prise en compte des #mediaqueries par internet explorer).

    – Insertion des meta-tags habituels pour un site responsive :
    + définition du viewport (attention : j’ai l’habitude d’interdire le zoom sur mes sites responsive, parce que souvent j’ai besoin de pouvoir utiliser les gestures pour autre chose dans le site – bon, si on a besoin, c’est facile à désactiver) ;
    + refuser la détection des numéros de téléphone, ça m’a toujours posé plus de soucis qu’autre chose ;
    + activer la possibilité de transformer le site Web en webapp.

    – Pour l’aspect Webapp, intégration d’un petit script perso qui transforme tous les liens internes du site en action javascript, ce qui fait qu’on peut naviguer entre les pages du site sans cliquer la Webapp (sans cela, dès qu’on suit un lien du site, ça lancerait Safari).

    – Comme c’est chiant à faire à chaque fois, j’intègre le meta du charset systématiquement à cet endroit.

    – Et quelques lignes de CSS…
    + désactiver la « correction » de la taille des caractères ; c’est logique sur un site qui n’est pas optimisé, mais en responsive c’est pénible ;
    + tiens, désactiver le zoom sous Internet Explorer ;
    + forcer le lissage des images réduites sous IE7, parce qu’en responsive on le fait souvent.
    + et puis mes minimums : pas de marge pour le body, et pas de cadre autour des images. C’est pas directement lié au responsive, mais ce sont les seuls choses du genre « reset » que j’utilise systématiquement (je n’utilise jamais de reset.css).

    Je sais qu’il y a déjà des choses dans la Zone, mais c’est un vieux truc à moi que j’utilise absolument tout le temps, et qui est bien pratique. Alors autant le partager.

  • Sarah’s Bag - When Fashion is socially responsible
    http://www.flip-zone.net/b/en/sarah-s-bag-4149

    Sarah Beydoun is a Lebanese social entrepreneur. She is the Founder and Creative Director of “Sarah’s Bag”, a worldwide reknown brand of handmade bags and accessories. Fashionistas of all ages crave for her designs.

    Perhaps the reasons for this success involve the following:

    First, the fact that each bag design is unique, telling a story inspired by Sarah’s Lebanese and Arab culture like poetry, food, architectural elements, etc. Pop culture like Arab pop stars, divas as well as cinema (...)