KiwiParty 2015 : bilan d’une longue journée

Merci à Alsacréations et à tous les sponsors pour avoir, cette année encore, pu proposer des conférences de qualité, dans une salle encore plus grande que l’année dernière mais avec des muffins toujours aussi bons. Voici le résumé de mes notes avec les slides des orateurs de la journée. Cette année, le programme était commun à tout le monde. Il n’y avait pas 2 salles avec des conférences en parallèle. Vous avez donc tout ci-dessous, comme si vous y avez assisté. Bonne lecture.

Icon-fonts vs SCG sprites de Vincent De Oliveira


Avec l’apparition des écrans rétina, nous avons du développer des techniques pour que les icônes ne soient pas pixélisées. La meilleure solution est d’utiliser des icônes vectoriels.

Il y a soit les icon-font :

  • police de caractères
  • rendu possible grâce à @font-face

Considéré plus comme un ‘hack’.

Il y a soit le SVG (Scalable Vector Graphics) :

  • format d’image vectoriel
  • c’est du XML

Dédié à la vectorisation.

L’utilisation de base diffère. Pour les icon-font, elles sont prêtes à l’emploi avec qu’il y a un peu plus de travail pour utiliser les SVG.

Concernant la création, les icon-fonts sont plus complexes à faire que les SVG.

Niveau intégration, il n’y a qu’une façon d’intégrer une police dans une page alors qu’il y en a 6 pour les SVG.

L’icon-font est supportée à partir de IE6 (pas Opéra mini) alors que les SVG n’est compatible que depuis IE9 (et Opéra mini).

Il est également plus simple de mettre en place un fallback pour les SVG. Les ligatures étant possible tant pour les icon-font que les SVG.

Niveau JavaScript, il est inclut dans le SVG, il permet l’accès au SVG DOM alors qu’il n’y en a pas avec les icon-fonts.

Pour ce qui est du responsive, les icon-fonts ne le sont pas alors que le SVG peut embarquer les différentes versions responsive de l’iage.

Avantages du SVG :

  • facile a créer
  • réutilisable
  • multi-effets
  • positionnement siplifié
  • drégradation gracieuse
  • meilleure ally
  • CSS + JS

Inconvénients :

  • encore peu de sets prêts à l’emploi
  • workflow complet pas évident
  • compatibilité navigateur non homogène
  • parait plus complexe

Les personas : comment les concevoir et les utiliser, de Gwennola Pierre

Le debug d’applications web simplifié, par Etienne Margraff et David Rousset

Vorlon.js, basé sur Node, Express et Socket.io, est un outil de debug web pour mobile. L’architecture est basée sur des plugins :

  • Console
  • modernizr
  • DOM Explorer
  • Object Explorer
  • XHR Panel
  • ngInspector

Pour l’utiliser, il faut installer le serveur (npm install -g vorlon) ou faire un clone / fork de vorlonjs. EN 2e étape, il faut modifier le site à débuger et mettre en place un fichier JS sur le front de votre site web.

Considérations ergonomiques avec Antonio Capobianco

La cognition spatiale est une capacité qui permet d’optimiser un espace de rangement. Cette cognition spatiale a plusieurs caractéristiques dont la mémoire spatiale. Lorsqu’on navigue sur un site internet, nous allons également faire une carte graphique de l’espace et des contenus qui permet de nous orienter dans l’information.

Cette mémoire spaciale a des propriétés :

  • elle conserve les caractéristiques spatiales. De ce point de vue, un site one page n’est qu’une liste à puce, soit un empilement de documents. Il est moins facile de mémoriser une information spatiale.
  • elle repose sur un référentiel
  • c’est un où et un quoi. Chaque élément doit avoir une sémantique claire et efficace. Chaque partie doit être clairement délimitée.
  • elle doit exploiter les référentiels. Il vaut mieux favoriser une navigation par écran pour mieux mémoriser l’information.
  • elle est automatique mais pas immédiate. Il faut offrir un comportement spatialement stable.

Les animations influencent la mémorisation. Elles doivent renforcer la cohérence spatiale du contenu.

Le pseudo-élément, c’est bon ! par Matthieu Bué

Quelques une de ses démos sur Codepen.

Le web et ses sales caractères par Damien Senger

Il y a pratiquement 700 typo sur Google Fonts. Il y a un grand choix mais aussi de grandes responsabilités. Un fichier de font est relativement lourd.

La déclaration bullet-proof de Font Spring de l’époque n’est plus d’actualité. Le problème de leur syntaxe est de déclarer pour chaque graisse un nouveau nom de typo (la normale, la bold, l’italique, etc).

Une des premières modifications que vous pouvez y apporter est la graisse des caractères directement en css, via font-weight:400 (regular, 700 : bold); au sein d’un @font-face. et via le font-style pour l’italique.

Pensez aussi à intégrer l’opentype systématiquement lors de vos déclaration.

Avec local(), vous pouvez vous passer de changer une typo quand elle est déjà disponible sur le device. C’est un gain certain de performance. Rendez-vous sur le tableau de diffusion des polices sur les OS mobile pour avoir plus de détails : http://jordanm.co.uk/tinytype/

Faire passer un mammouth dans un tuyau d’arrosage par Jean-Pierre Vincent

Ce qui n’a pas changé :

  • on a besoin d’aller vite
  • mobile = latente = sites lents
  • pour Google, la vitesse de chargement a de l’importance

Mesurer : Webpage Test

Montrer : Google Analytics, à enrichir avec des mesures liées au métier

Objectif, pour 80% des utilisateurs :

  • premier rendu en moins de 2 secondes
  • fonctionnalité principale en moins de 5 secondes
  • fluide à partir de tel modèle (modèle de device mobile)
  • UX riche

Solution : asynchrone et fallback. Pensez d’abord pour les mobiles, utilisez des techniques d’amélioration progressive, dialoguez en interne de l’importance de chaque contenu pour chaque page et remplacez le site desktop responsive par le site mobile le plus tôt possible.

Les techniques :

  • éviter les effets de saccade sur les sliders : la propriété left de jQuery donc une fonction animate coûte très cher en ressource. C’est elle qui fait saccader. Il faut donc la remplacer. Au lieu de jQuery, utilisez le CSS avec la proriété transform et translateX(-600px); suivi d’un transition-timing-function: cubic-bezier.
  • utiliser les images adaptives. Privilégiez les SVG et appliquer leur des ombres (si nécessaire) en CSS. Vous pouvez aussi utiliser des images encodées en inline ou du lazy-loading

UX Design & hackaton : un guide de survie par Laurence Vagner

Un hackaton / game jam : 48h pour développer un site, une application, un jeu vidéo, etc. Pourquoi y participer ? Pour avoir un gros challenge, sortir de sa zone de confort et tester de nouvelles choses.

Guide de survie

  • oublier tout ou presque de votre vite habituelle
  • faire des points régulièrement
  • choisir les outils et technologies ensemble
  • optimiser les exports
  • gestion de version + collaboration : GitHub
  • clé USB de secours
  • mini workshop : écouter toutes les idées
  • créer au moins 1 persona
  • lister et limiter les fonctionnalités
  • définir les priorités
  • lister les usecases
  • dégrossir le projet (grooming session avec les devs)
  • définir les écrans et leur fonctionnalités
  • usecases + maquettage papier => prêt à développer
  • outils UX : Sketch / balsamiq / marvelapp
  • définir une identité : guide de style pour les devs
  • réutiliser : librairies open-source, icônes, fonts

Bonnes pratiques

  • Less is more : limitez les fonctionnalités
  • formez votre équipe à l’avance
  • choissiez ensemble les outils et technologies
  • dormez, mangez sainement, limitez l’alcool
  • débrief une semaine plus tard (suite, idées, doc)

Et si on parlait productivité par Nicolas Birckel

Mythe 1 : faire de grosses journées, c’est être productif.

Mythe 2 : il faut être disponible, tout le temps, pour tout le monde.

Mythe 3 : le multitasking permet d’être plus productif

Mythe 4 : faire souvent des réunions (ordre du jour trop chargé, personnes non directement concernées)

Mythe 5 : on travaille mieux sous pression (avoir une deadline est un bon stress mais il y en a surtout du mauvais)

L’UX sans utilisateur, par Raphaël Y.

Retrouvez le bilan de cette Kiwiparty par Weblife ici.

Créer une vidéo responsive pour Youtube, Vimeo, etc.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *