Retour sur la KiwiParty 2015

Par Marie,
dans Inside acti

La Kiwiparty, c'est l'occasion de faire le plein d'énergie pour les futurs projets !

Organisé à Strasbourg par une agence locale, Alsacréations, cet événement gratuit rassemble des professionnels du web pour une journée de conférences sur la conception, la technique et les bonnes pratiques web.

acti-kiwiparty-02

Pour ma deuxième participation consécutive, j'ai pu à nouveau apprécier la variété des sujets proposés, ainsi que la bonne ambiance qui règne tout au long de la journée : une équipe d'organisateurs aux petits soins, des orateurs accessibles, et des participants ouverts aux échanges et discussions.

Focus sur l'intégration : SVG, pseudo-éléments, @font-face

En tant qu'intégratrice, j'ai toujours un faible pour les conférences qui traitent de mon cœur de métier...

Icon-fonts vs SVG sprites

Après la présentation époustouflante du line-height l'année dernière, Victor de Oliveira (@iamvdo) était de retour cette année pour nous parler SVG (images au format vectoriel), et plus spécialement pour décortiquer 2 manières de l'utiliser : les icon-fonts et les sprites.

Méthodes d'inclusion, réutilisabilité, styles, animations, accessibilité... tous les avantages et inconvénients étaient passés en revue afin de pouvoir choisir, selon les besoins du projet, la manière la plus adaptée.

Résultat du match : on peut retenir que l'utilisation de sprites SVG est la méthode qui ouvre le plus de possibilités, notamment en terme de styles et d'animations.
Nous avons déjà commencé à les utiliser en images d'arrière-plan, mais cela donne envie d'aller plus loin sur les prochains projets !

Consulter les slides de "Icon-fonts vs SVG sprites"

Le pseudo-élément, c'est bon !

Pour sa première conférence, Matthieu Bué (@twikito) avait choisi de se concentrer sur les pseudo-éléments ::before et ::after.

Comme leur nom l'indique plus ou moins, il s'agit d'éléments... qui n'existent pas vraiment : ils n'apparaissent pas dans le code HTML, mais sont manipulables comme si c'était de vrais éléments, placés en début ou en fin de leur conteneur. Ils peuvent donc être totalement stylés en CSS et leur usage principal est plutôt réservé à des fins décoratives, tels que l'insertion de pictos.
Nous nous en servons depuis un certain temps maintenant, et il est vrai que cela permet de faire beaucoup de choses qui, auparavant, n'étaient possibles qu'en surchargeant le code HTML de balises vides.

La conférence se concentrait ainsi principalement sur une série d'exemples essayant de pousser l'utilisation le plus loin possible, des effets de survol originaux, en passant par des checkboxs customisées, pour finir en apothéose sur un système d'ouverture de menu avec overlay, géré uniquement en CSS.
Pour le coup, ce dernier exemple était à voir plutôt comme une expérimentation que comme un cas concret, mais il faut avouer que c'était impressionnant !

Consulter les slides de "Le pseudo-élément, c'est bon !"

Le web et ses sales caractères

Depuis un certain temps déjà, la grande majorité des sites utilise la règle @font-face pour charger des polices de caractères spécifiques, qui ne sont pas disponibles par défaut chez l'utilisateur.
Cependant Damien Senger (@iamhiwelo) souhaitait revenir sur plusieurs points de performance dans cette utilisation, et donner quelques bons conseils.

Tout d'abord, gérer la graisse et le style directement dans la déclaration @font-face : cela permet que les différents fichiers de la même famille de caractères soient réunis sous le même font-family, et que le chargement du bon fichier selon la graisse s'effectue "naturellement", c'est-à-dire simplement via le changement de la propriété font-weight, sans devoir à chaque fois changer la propriété font-family.
Ensuite, tirer parti du format de fichier OTF, qui permet, entre autres, de gérer les ligatures (ex : "œ").
Enfin, ne pas oublier la propriété local(), qui évite de charger le fichier de police si l'utilisateur en dispose déjà sur son poste.

Par ailleurs, il donnait quelques astuces pour gagner du poids de chargement : optimiser bien sûr les fichiers de police, mais aussi ne sélectionner que les caractères utilisés, ou encore utiliser du faux gras pour les textes de labeur où la différence visuelle est minime.

Les questions de participants ont également soulevé un point important : la dépendance à Google Fonts, que ce soit en terme de service (ca peut disparaitre ou être inaccessible à n'importe quel moment, sans que l'on ait de contrôle là-dessus) ou en raison du tracking que cela implique.

Consulter les slides de "Le web et ses sales caractères"

Responsive, encore et toujours : debug multi-devices, performance sur mobile, responsive côté serveur

Sketch-note de la conférence "Le debug d’applications web simplifié" par Margot Peyen

Le responsive est maintenant bien ancré dans les usages, mais nous ne sommes pas au bout de nos efforts : il est important de creuser les différents aspects et implications pour une bonne expérience, quels que soient les conditions et le matériel de consultation.

Le debug d’applications web simplifié

C'était la conférence sponsorisée "bonne surprise" de la journée !
David Rousset (@davrous) et Étienne Margraff (@meulta) nous présentaient Vorlon.js, un outil développé par Microsoft pour faciliter la vie des développeurs : peu importe le device et le navigateur final utilisé, pouvoir débugger et inspecter le DOM d'un site via un ordinateur desktop.
En effet, jusqu'à présent les solutions de ce type étaient liées à la plateforme utilisée, ce qui oblige à jongler entre de multiples outils et supports.

La démonstration donnait envie : l'installation et la prise en main semblent simple et rapide, incluant un test avec plusieurs dizaines de smartphones de participants accessibles au debug.

Avantage non négligeable : étant open-source, Vorlon se prête à la création de plugins personnalisés, pour étendre les fonctionnalités de debug. Le but avoué est ainsi de se baser sur la communauté pour faire progresser l'outil.

Voir la démo de Vorlon.js

Faire passer un mammouth dans un tuyau d'arrosage (aka la performance sur mobile)

Après sa conférence à toute allure sur la performance de l'année dernière, Jean-Pierre Vincent (@theystolemynick) revenait pour parler plus spécifiquement de performance sur mobile.

Il mettait ainsi en avant des bonnes pratiques performance, côté technique mais aussi en conception : penser mobile et sans JS d'abord, éviter les animations JS et privilégier le switch de classes CSS avec des transitions en transform (translate), lazy-loader les contenus non-visibles en premier lieu ou non-critiques (particulièrement les images)...
Plus précisément, il s'agit de cadrer la démarche de performance, et pour cela il faut savoir d'où l'on part et où l'on veut aller, avec des objectifs chiffrés : premier rendu en moins de 2 secondes, fonctionnalité principale en moins de 5, quels contenus critiques à prioriser pour l'affichage, quels modèles visés, etc.

Enfin, il prenait en exemple une comparaison entre les pages d'accueil du Guardian et du Figaro : 2 sites médias plutôt chargés en contenu. Le Guardian remportait la mise car, créé en mobile-first, il permet un accès et une interaction avec le contenu beaucoup plus rapides, malgré son poids total de chargement plus élevé.
Ce fut l'occasion ensuite de prolonger la discussion, car une des personnes travaillant sur le site du Figaro était présente et a pu expliquer le travail mis en œuvre et les améliorations envisagées.

Le responsive côté serveur (RESS)

Rémi Grumeau (@remi_grumeau) nous présentait différentes techniques pour éviter de tout déléguer côté client (front) quant à la gestion responsive.
En effet, actuellement c'est surtout le JS et le CSS (media-queries) qui gèrent les adaptations selon la taille de l'écran ou les technologies supportées. Cela résulte en un poids chargé plus important que nécessaire, puisque c'est le code dans son ensemble (gérant tous les cas) qui est envoyé au navigateur, peu importe quelles parties sont réellement utilisées.

La proposition du REsponsive Server Side (RESS) est donc de prendre en charge une partie côté serveur, c'est-à-dire modifier le code avant qu'il soit envoyé au navigateur.
Cela a été fait sous différentes formes depuis un certain temps : les sites dédiés mobile notamment, par user-agent-sniffing.
Ici, l'idée est bien de toujours se baser sur le user-agent, mais de façon plus modulaire, en se basant sur les tailles d'écrans et les technologies supportées par chaque combo navigateur/device. Bien entendu, pour fonctionner comme ça, il faut avoir des infos très précises liées au user-agent : des bases de données continuellement mises à jour, afin de gérer les nouveaux modèles qui sortent régulièrement.
Au final cela permet par exemple d'envoyer tout de suite les images adaptées à la taille et à la résolution de l'écran, ou alors de modifier complètement la structure HTML selon qu'on soit sur mobile ou desktop, sans devoir avoir recours à du lourd JS : générer le DOM le plus petit et le plus adapté possible.

Je crois que je n'étais pas la seule dans le public à accueillir cette présentation avec des sentiments mélangés... L'intérêt de la chose est-il suffisant, en comparaison de tous les écueils qu'il faudra éviter (gestion du cache, des changements d'orientation sur les devices portables, finesse dans la détection par le user-agent...) ?
Je n'arrive pas encore à être convaincue totalement, mais ça a au moins le mérite de poser d'intéressantes questions sur "comment faire du responsive autrement".

Consulter les slides de "Le responsive côté serveur (RESS)"

Et tout le reste...

acti-kiwiparty-01

Les conférences ne se limitaient pas à l'aspect technique, et j'ai trouvé que beaucoup plaçaient l'utilisateur au centre :

Et tout le reste... (bis)

Il y eut aussi le fameux quiz de fin de journée, QCM aux questions plus ou moins sérieuses, mais l'amphi qui nous accueillait n'était pas pour rien dans l'atmosphère d'examen qui régnait à ce moment-là...

Question du quiz KiwiParty : Quelle technologie n'est plus supportée par le navigateur Microsoft Edge ?

Enfin, pour prolonger cette bonne journée, l'::after tint ses promesses de tremplin aux discussions entre participants, orateurs et organisateurs, d'autant que, comme l'année dernière, un questionnaire par équipes était organisé.

J'insiste là-dessus, mais l'ambiance qui règne lors de cet événement lui donne autant de valeur que son contenu, donc merci à l'équipe qui œuvre pour rendre tout cela possible, et à l'année prochaine !

Quelques bonus :
Le compte-rendu de cette journée par Nicolas Hoffmann
Le chouette sketchnoting des conférences par Margot Peyen
Vous pouvez aussi aller lire le compte-rendu de la KiwiParty 2014 !

Marie Hanotte
par Marie

Laisser un commentaire

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

Rechercher