KiwiParty 2015

La Kiwi Party est une Conférence Web gratuite dédiée à la qualité, la performance et l’accessibilité du Web, organisée par l’agence web Alsacienne Alsacreations dans la belle ville de Strasbourg. On y parle design, technique, UX, performance…

Cette année j’ai eu le plaisir de faire partie des chanceux qui ont pu s’inscrire à cet événement. Contrairement à ce qu’on pourrait attendre d’un événement gratuit, le niveau était vraiment haut tant au niveau organisation qu’au niveau des orateurs et de leur présentation. Un vrai régal. Voici un petit résumé de ma journée en mode Kiwi Alsacien.

Toutes les conférences (Enregistrements audio, slides et/ou videos) ainsi que les articles des participants, les tweets, les photos et les sketch-notes sont disponibles sur le site de la KiwiParty : http://kiwiparty.fr

Cet article retrace les propos des orateurs à travers mon regard. Mes commentaires personnels seront notés de cette façon

Sommaire de la journée (et de l’article) :

• Font-icon vs SVG Sprites
• Personas
• Le debug d’application web simplifié (Vorlon.js)
• Le chasseur-cueilleur, Hannibal Lecter et autres considérations ergonomiques
• Le pseudo-élément, c’est bon !
• Le web et ses sales caractères
• Faire passer un mammouth dans un tuyau d’arrosage (aka la performance sur mobile)
• UX Design & hackaton : Un guide de survie
• Le responsive coté serveur
• Et si on parlait productivité ?
• L’UX sans Utilisateur n’est que pornographie

8h – Ouverture des portes de la KiwiParty

Arrivée des participants au compte-goutte. J’ai le plaisir d’apercevoir en chair et en os les organisateurs, membre d’Alsacréations, c’est un plaisir de les apercevoir en vrai !

Un petit soucis organisationnel (d’après des bruits de couloir) nous prive du café de début de journée. Un peu dur mais on survit.

9h – Font-icon vs SVG Sprites

by @iamvdo
slides : http://slides.iamvdo.me/kiwiparty15/#

Les icônes sont partout dans l’informatique depuis très longtemps (dès les premières versions des systèmes d’exploitation). Elles sont parlantes et utiles. Seulement, on se retrouve très vite avec beaucoup d’icônes. Une des premières solutions d’optimisation fut l’utilisation de sprites mais l’arrivée des écrans Retina a vite remis en question cette solution. La duplication des sprites pour chaque résolution est loin d’être une solution viable.
C’est alors que des solutions plus efficaces voient le jour : les images vectorielles (= SVG) ou bien les polices d’icônes (= font-icon).

Chez itk nous utilisons énormément les font-icon et un peu de SVG (essentiellement pour les logos et les graphiques).

Voici un petit comparatif des deux méthodes sous plusieurs aspects.

Thème	Font-icon	SVG
FONCTION	Il s’agit de créer une police d’écriture et de remplacer les caractères par des icones. Concrètement c’est un hack. Ça marche, mais ce n’est pas fait pour.	C’est une Image Vectorielle Redimensionnable (Scalable Vector Graphics). Tout est dans le nom, c’est son rôle.

SVG WIN. KTHXBYE.

Traduction : « SVG a gagné. Ok. Merci. Ciao. » #blague

Allons quand même un peu plus loin dans la comparaison :

Thème	Font-icon	SVG
UTILISATION	Nombreux sets d’icônes dispo et utilisables gratuitement et rapidement	Ça pêche, c’est moins simple.
CREATION	Complexe, besoin d’outils comme icomoon, fontello etc.. et déjà besoin d’un svg avant !	Le même SVG que pour la font. Un vrai langage à apprendre.
INTEGRATION	@fontface	6 façons différentes (inline, img, svg, background etc)
SUPPORT	IE6+ mais PAS Opera Mini (smart watch)	IE9+ mais Opera mini
FALLBACK	Complexe	simple
LIGATURES	ok. Remplacer une texte « Facebok » par une icône	utiliser foncface DANS le svg… useless
COULEUR	Complexe	Illimités
REUTILISABILITE	null	On peut définir une forme avec < def > puis la réutiliser partout avec < use > Ou < symbol >
POSITIONNEMENT / ALIGNEMENT / TAILLE	Propriété de texte. Personne n’aime modifier le kine-height. Il reste toujours des espaces blancs non maitrisables. TEXTE != FORME	Box model. Et pour la taille tout le svg est utilisé comme un seul bloc.
INTERACTION / ANIMATION	Complexe	Intégré de base. Utilisation du CSS et même de Js inclus dans le SVG.
CSS AVANCE	Nop	Dégradés, masques, filtres, … etc
Js	Nop	inclus dans le SVG. Possibilité de générer du SVG à la volée via Js.
RESPONSIVE	Nop	Changement d’images selon la taille de l’écran (apparition de détails sur grand écran et forme plus simple pour petits écran)

Score Final :
Font-icon 3 – 11 SVG

L’orateur est clairement pour les SVG et ça se sent !

CONCLUSION

Bénéfices du SVG

• (Assez) facile à créer
• Réutilisable
• Multi-effets
• Positionnement simplifié
• Dégradation gracieuse
• Meilleure a11y
• CSS + JS

Inconvénients du SVG

• Encore peu de sets prêts à l’emploi
• Workflow complet pas évident
• Compatibilité navigateur non homogène
• Parait plus complexe

Grosse liste de liens concernant le SVG donné par l’orateur à la fin de la présentation : slide 57

QUESTIONS

Q : Comparaison des performances entre SVG et font-icon ?
R : Pas encore d’article mais selon un autre acteur du milieu (qui doit en faire un), les font-icon semblent plus performantes (il parlait de 5x plus)

BONUS

« Faire du SVG avec Illustrator c’est comme faire du HTML avec DreamWeaver »

9h30 – Personas

by @GwennolaPierre from @Kaliop
slides : https://speakerdeck.com/gwennolapierre/persona-dot-dot-dot-grata-number-kiwiparty?slide=1

Affichage d’une image de deux personnes âgées du type Fotolia qui sent bien le « fake sans âme ». Gwenola fait alors une présentation détaillée de qui ils sont, leurs âges, leurs vies, leurs passés, leurs histoires, leurs liens, leurs familles, leurs envies, leurs besoins… Les personnages prennent peu à peu « vie ».

C’était l’exemple d’un Persona. Pour faire un bon Persona il faut quelque chose de concret, pour bien le comprendre et se mettre dans sa peau : Photo, prénom, vie (age lieu enfants), un objectif (très important), une « base line » qui va décrire une façon de penser, une biographie, culture et habitudes, ses freins…

A quoi ça sert ?

Il s’agit ici de bien identifier sa cible afin de bien la comprendre et de pouvoir proposer une vraie solution adaptée.
Identifier sa cible permet de faire des choix, d’avoir un « référent » commun avec l’équipe (à afficher sur les murs), de concevoir son produit, son interface, d’augmenter le taux de conversion…

Un point très important est développé ici, un amalgame est souvent fait, il ne s’agit pas d’écouter l’utilisateur et de le laisser trouver la solution. Au contraire, il n’a pas la vision suffisante pour le faire. C’est à l’UX de trouver la solution. L’user doit donner son contexte, ses besoins, ses envies, ses freins etc… Généralement, il n’est pas bon de suivre une proposition technique d’un user.

EX : Un calculateur de quantité de peinture en fonction de la surface. Une idée qui a beaucoup plu, qui a été trouvée suite à une analyse des utilisateurs mais qu’un utilisateur n’aurait jamais pu suggérer lui-même.

Une autre présentation reprend ce point important : UX Day – Empathie dans l’UX : L’UX n’est pas le User et inversement !

Un outil : La carte de l’empathie (page 8 des slides). Cette carte a été retravaillée et améliorée par Kaliop.

Pour récolter tout ça, il faut « aller à la pêche » :

• Statistiques (même internes, des fois les ressources internes sont très riches)
• Études / infographies
• Ateliers internes (les gens du terrain ont énormément de savoir, comme des retours utilisateurs, sans forcément s’en rendre compte)
• Entretiens avec les utilisateurs (quand c’est possible)
• Sondages (online ou IRL)
• Réseaux Sociaux (analyse des profils abonnés à une page FB par ex)

CONCLUSION

Ne pas multiplier les personas (3-4) et les prioriser. Il faut un Persona principal + 2 ou 3 secondaire. Le persona principal aura le dernier mot, c’est pour lui qu’on design en priorité. C’est la cible la plus importante. Il doit être accepté par toute l’équipe. Cela impliquera également un renforcement de la cohésion de l’équipe.

Il faut mettre à jour ses personas régulièrement

Chaque projet a ses propres personas

P – Primaire : il faut un persona principal qui prenne le pas sur les autres
E – Empathie : UX n’est pas User et inversement !
R – Réaliste : il faut un cas concret qui soit plausible
S – Singulier : Tous doivent être différents. Si deux personas se ressemblent alors il faut en supprimer un.
O – Objectif : Ils doivent avoir un but, un objectif
N – Nombre : Idéalement il faut 3-4 personas
A – Applicable : un cas qui soit concret et applicable sur un projet

QUESTIONS

Q : Comment ne pas tomber dans les clichés ?
R : Il faut beaucoup travailler avec l’équipe et en interne avec le client aussi pour bien connaitre sa cible et ne pas « imaginer ».

Q : A force de faire des « types » de personnes, n’efface-t-on pas les individualités ?
R : Un persona va associer, absorber, les caractéristiques de plusieurs utilisateurs, il ne va pas être un utilisateur en particulier. C’est un peu un « monsieur tout le monde » représentatif de la cible. Un persona doit aider à répondre à la majorité de sa cible et non à la majorité des utilisateurs.

10h – Le debug d’application web simplifié (Vorlon.js)

by @meulta && @davrous
site de l’application : http://vorlonjs.com
video : http://www.dailymotion.com/video/x2x7wg0_le-debug-d-applications-web-simplifie-avec-vorlon-kiwiparty-2015_tech#from=embediframe

Le web permet une utilisation multiplateforme simple et ça c’est cool.
Le débug client se fait essentiellement grâce aux inspecteurs de code (F12 et autres FireBug). C’est cool aussi.
Mais quand il s’agit de débuguer le client sur mobile… aïe. En développement web, le débug mobile est une chose assez relou. C’est pourquoi nous avons fait http://Vorlon.js !

Vorlon.js a été fait à base de Node.js, Express.js et socket.io. Il est libre et sur github. Il permet un débug client en remote. Il est certes un peu moins performant que les inspecteurs de code classique mais c’est mieux que rien. Il possède 6 plugins par défaut (dont 1 pour AngularJs) et il n’attend que vous pour en avoir plus.

Il s’installe très facilement (en un « npm-install », cf la présentation sur le site officiel) et s’intègre au page simplement grâce a un appel de script Js.

Il permet également un débug d’applications natives si on utilise un système du genre Cordova pour les générer à partir d’une appli web.

Pour le moment l’application ne permet de voir que les devices connectés sur le moment. Pouvoir garder un historique des connections et ainsi pouvoir en faire des statistique est bien sur prévu mais n’était pas dans les priorités du MVP pour son lancement.

J’ai gagné un T-Shirt pour avoir posé cette question sur l’historique ! \o/

L’application pourra également ouvrir pleins de portes comme par exemple le débug et le support à distance.

Bonus

Article de présentation de Vorlon.js sur Alsacreation.com : http://www.alsacreations.com/outils/lire/1684-vorlonjs.html

11h – Le chasseur-cueilleur, Hannibal Lecter et autres considérations ergonomiques

by @LamiTransalpin
slides : https://speakerdeck.com/tonicapo/le-chasseur-cueilleur-hannibal-lecter-et-autres-considerations-ergonomiques

Cette prez n’est pas vraiment un REX mais plutôt une analyse et des recommandations plus ou moins théoriques des différents design web que l’on peut croiser (Design fluide, one page, double scroll, parallaxe…)

La cognition spatiale nous est d’une grande aide à chaque moment, sans même que l’on s’en rende compte. Elle nous aide à nous déplacer dans une ville inconnue, à jouer au tétris ou à faire sa valise.
La mémoire spatiale nous permet par exemple de savoir avec précision où chaque objet se trouve sur un bureau en bordel. Si on remonte un peu plus loin, dès l’époque des chasseurs-cueilleurs, cette mémoire nous permettait d’aller chercher de la nourriture assez loin et de revenir chez nous avec. Dans une époque plus actuelle c’est cette même mémoire qui va nous aider à retrouver directement l’icône d’un programme parmi toutes nos icônes sur le « Bureau » de notre ordinateur. Les interfaces graphiques reposent sur une métaphore spatiale.
La recherche spatiale est plus efficace que la recherche visuelle pour un nombre d’élément pas extravagant. La mémoire spatiale est à la base des comportements experts.

Notre axiome ici est que, lorsqu’on on navigue sur un site, on utilise une carte mentale (navigation, contenu, …).
L’utilisateur fait un « reverse engineering » par rapport au travail du designer.

1 – La mémoire spatiale conserve les caractéristiques spatiales.

Il vaut mieux donc privilégier les structures de contenu larges mais peu profondes pour solliciter la mémoire spatiale. De par ce fait, un site « one-page » est assez mauvais pour la mémorisation.

2 – Une information spatiale repose sur un référentiel

Il faut exploiter les repères existants et aider les utilisateurs à construire leurs propres repères.

3 – Une information spatiale c’est OU et QUOI

Chaque élément doit avoir une sémantique claire et efficace. Les sites one-page sont plus dur à analyser. Chaque partie doit être clairement délimitée.

4 – La mémorisation de l’information spatiale est automatique mais pas immédiate

Il faut offrir un comportement spatial stable donc attention aux design fluides (EX : le « search » qui passe du header au footer)

5 – Les animations influencent la mémorisation

Les animations doivent renforcer la cohérence spatiale du contenu (EX : Le déplacement animé de blocs qui changent de position). Les effets de parallaxe complexes deviennent gênants au delà de l’aspect esthétique.

Conclusion

Certaines tendances du web vont à l’encontre de principes ergonomiques. Ces designs sont bien pour une belle expérience virtuelle mais au delà, il ne faut pas s’attendre à ce que l’utilisateur retienne de l’information. Tout est question de priorité.

11h30 – Le pseudo-élément, c’est bon !

by @Twikito
slides : https://speakerdeck.com/twikito/les-pseudo-elements-cest-bon

Les pseudo-éléments CSS sont très puissants. Il en existe une looooongue liste :
::first-line, ::first-letter, ::before, ::after, ::selection pour les plus connus. Mais d’autres, moins connus pour le moment, sont en cours de route comme ::spelling-error, ::grammar-error, ::marker, ::placeholder.

Concentrons nous sur ::before et ::after. Ils doivent TOUJOURS contenir la propriété « content ». Dans ce « content » on peut y mettre :

• none ou normal – useless
• « du texte » – usage le plus courant mais attention à l’accessibilité
• une image
• open-quote / close-quote – mieux que content:' »‘; pour l’accessibilité
• counter(var) – compteur CSS
• attr(var) – pour récupérer un attribut de l’élément html

Beaucoup d’exemples sont assez connus et ne donnent que des « challenges » pas vraiment utilisables / utiles dans le contexte d’applications métier.

Quelques bonnes idées à retenir

Signaler automatiquement le type de fichier pointé par un lien

[href$=".pdf"]::after { content: "(pdf)"; }
[href$=".zip"]::after { content: "(zip)"; }

Afficher l’url d’un lien en version print

@media print {
	[href]::after{
		content : "(" attr(href) ")";
	}
}

Des infos-bulles plus accessibles grâce à l’attribut title de l’élément HTML

Une liste numérotée (sur plusieurs niveaux) ou bien un compteur de nombre de cases cochées par exemple grâce au counter CSS

12h – Le web et ses sales caractères

by @iamhiwelo
slides : https://speakerdeck.com/hiwelo/le-web-et-ses-sales-caracteres-kiwiparty

On utilise la typo tous les jours sur le web. Il y a à peu près 700 fonts différentes sur GoogleFont.

@font-face

On l’utilise pour ajouter une font ou une font-icon nos projets. On utilise souvent une déclaration « bullet proof » (multi navigateur) qui marche très bien, mais elle date un peu. Le problème notamment est de devoir faire une déclaration pour chaque graisse de la police (regular, bold, black, italic..), donc potentiellement un nom de font par graisse de police. Ici le problème est au niveau de la maintenabilité. Donner un font-weight ou font-style dans la déclaration de la font permet de donner le même nom à la font et à toutes ses variantes.

.otf

On peut également penser à rajouter la font en OpenType (.otf) car il est mieux supporté de nos jours et permet plus de choses (comme de vrais small caps, les ligatures etc). Attention toutefois car l’otf peut être très (très très) lourd.

local()

Concernant le poids des fichiers, une astuce malheureusement sous-utilisée dans font-face, et pourtant très utile, est local(). Il faut penser à déclarer local() avant de déclarer les url. Pour les petites font pas connues ce n’est pas trop gênant mais pour un Roboto ou Georgia par exemple : la font est dans Android donc pourquoi forcer le téléchargement ? Si on utilise pas local() le css ne va pas chercher et va télécharger la font même si elle est disponible en local.
Tinytype propose un tableau qui répertorie les fonts présentes sur les principaux OS Mobiles. On peut voir que Roboto n’est disponible que sur Android (mais c’est déjà ça). On voit également que Georgia est disponible sur IOS7, WP8 et BlackBerry ce qui peut constituer un gros gain de performance sur ces plateformes.
local() n’était pas beaucoup utilisé notamment à cause de la compatibilité mobile, mais ce n’est plus d’actualité.

@font-face {
    font-family: 'Georgia';
    src: local('Georgia'),
    	local('Georgia-Regular'), // toujours essayer avec la graisse "au cas où.."
    	url('georgia-regular.eot?#iefix') format('embedded-opentype'),
        url('georgia-regular.woff') format('woff'),
        url('georgia-regular.ttf') format('truetype'),
        url('georgia-regular.svg#georgia-regular') format('svg');
    font-weight: normal;
    font-style: normal;
}

Les deux premiers points étaient connus et déjà appliqués chez itk mais pour local() nous ne l’utilisons pas dans nos projet. A rajouter donc car très intéressant.

Faux gras

Une variante de graisse c’est bien, plusieurs c’est lourd. On peut donc également réfléchir à l’utilisation d’un « faux gras ». C’est le gras généré par le navigateur (font-weight:bold;) et non une variante de la font chargée en font-face. Cela implique un gain de temps (pas de téléchargement de font supplémentaire) mais le rendu ne sera peut être pas au rendez-vous.

font-icon accessible

Pour cela il faut arrêter d’utiliser les espaces privés d’unicode (UTF-8) et privilégier un code qui, en fallback, donnera un « émoji » (du système) plutôt qu’un carré moche. Certes, sur certaines plateformes le style de ces émojis ne sera pas raccord avec le design mais cela vaudra toujours mieux qu’un carré sans aucune signification. En plus, ces émojis sont compris par les lecteurs d’écrans car ils font partie des caractères unicode (à la lecture ils rajoutent « émoji » après pour dire que c’était une icône).

14h30 – Faire passer un mammouth dans un tuyau d’arrosage (aka la performance sur mobile)

by @theystolemynick
video : https://vimeo.com/133654572

Perf Perf Perf

Ce qui n’a pas changé ces dernières années :

• L’humain : « need for speed »
• La transmission radio : mobile = latence = sites lents
• Google : la perf n’est pas un bonus c’est une fonctionnalité à part entière (et un critère de référencement)

Par contre ça ne sert à rien de s’y coller tout seul comme ça dans son coin. Pour convaincre il faut mesurer et montrer.
« Montrer c’est faire douter. »

On peut utiliser des sites comme http://www.webpagetest.org/ ou même son Google Analytics (que l’on peut enrichir avec un peu de Js).

Amélioration progressive

Il faut avoir de vrais objectifs (ex : pour 80% des utilisateurs avoir un premier rendu en moins de 2 secondes, fonctionnalité principale en moins de 5 secondes etc).
C’est un peu comme un escalator : s’il ne marche pas, tu peux toujours monter à l’étage. Ça va dans la même direction que le mobile first, l’accessibilité etc.

Il faut donc prioriser ce que l’on veut afficher.

Une première étape est de penser par exemple au chargement asynchrone des fonts et à un fallback. Le site affichera alors une font non stylée mais l’utilisateur pourra commencer à lire en attendant plutôt que d’attendre devant une page vide. Il faut donc discuter avec l’équipe (ergonome, graphiste, dev) afin de repérer ces points bloquants et les éliminer (les faire charger en asynchrone).

Garder un site lisible sans JS, Avoir quand même les href même si à terme le Js viens intercepter les clics pour afficher de belles choses…

Pour résumer la stratégie globale il faut d’abord penser au mobile (l’UX est d’abord mobile aujourd’hui), utiliser des techniques d’amélioration progressive (lien simple), et discuter en interne avec tout le monde pour bien comprendre l’intérêt du contenu de chaque page.

Et si on fait ça bien, le site site mobile (+expendables) va finir par remplacer le site desktop (ex : Guardians, SNCF,…).

Tips Techniques

• Il faut faire attention aux animations une fois la page chargée : à la fluidité des animations d’un slider par exemple. C’est le piège de JQuery : lourd + lent = saccade sur les slides. Utilisez CSS3 à la place ! Le Js ne gère alors que l’état du slider et les noms de classe. Le traitement est plus rapide et le résultat plus fluide.
• Les images adaptatives : servir les images les plus adaptées en fonction du device, de la bande passante… Il faut donc se rapprocher le plus possible du SVG et du CSS3. Pour les images de contenu il faut faire du lazy loading (afficher les images uniquement lorsqu’on arrive dessus) cela permet de libérer de la bande passante pour charger des images de meilleure qualité tout en étant plus rapide par ex. Et s’il y a des images critiques comme le logo, des icônes ou autres, on peut toujours les encoder en base64 directement dans le html comme ça elles s’affichent tout de suite.

Conclusion

Concrètement si votre boite n’a pas de site qui marche (et vite) sur mobile, votre boite va crever lentement.

Le retour de l’amélioration progressive annonce aussi le retour des perfs, de l’accessibilité, la compatibilité, donc ça veut dire conquérir de nouveaux marchés / devices.

La perf c’est une culture d’entreprise, il faut embarquer tout le monde avec vous (chef produit, marketing, ergonome etc…)

QUESTIONS

Q : Est-ce qu’il y a une grosse diff de perf entre les transformations CSS 2D et 3D (scale etc) ?
R : Non, mais ça va essentiellement dépendre du device. Chrome par ex va gérer les transformations 2D comme les 3D (avec le GPU). Il faut tester sur les devices mais généralement la translation 2D suffit largement.

Q : Les images en lazyLoad entrainent un reflow, c’est pas gênant ?
R : Normalement tu devrais prévoir des espaces de la taille de la future image pour éviter ca. Mais c’est beaucoup plus compliqué pour les images dont on ne connait pas les ratios…

Q : Ton discours va-t-il changer avec l’arrivée de HHTP2 ?
R : Non. Ça va permettre d’éviter certains trucs mais ça ne change pas tant que ça. Tu pourras charger plusieurs ressources en même temps mais la taille du tuyau reste la même. La priorisation de contenu et l’affichage de la première image resteront d’actualités.

15h – UX Design & hackaton : Un guide de survie

by @hellgy
slides : http://fr.slideshare.net/hellgy/uxdesign-hackathon

CF le CR de l’UX Day 2015 à venir

15h30 – Le responsive coté serveur

by @remi_grumeau
slides : https://vimeo.com/133654573

Comme son nom l’indique il s’agit de gérer le « web mobile » coté serveur.

La gestion du responsive coté serveur a mauvaise réputation… pour de bonnes raisons ! A l’époque cela avait été mal fait : on a géré le web mobile avec un sous domaine « iphone » quand il est sorti, puis un autre « mobile » puis encore un pour l’ipad etc… Le contenu était dupliqué et le partage transmédia complètement foireux… D’où l’élan massif pour gérer ça coté client avec HTML5, CSS3, JS (+ modernizr, yepnope.js etc..)

Cependant, on demande tout au navigateur alors qu’on a déjà 90% des réponses. Et on lui demande à chaque fois toutes ces questions pour chaque page sans retenir les réponses : c’est de l’amnésie coté client.

Donc baisse en Perf, en UX, en réseau, en reflow, en dépendances, en maintenance etc… Ça complique énormément le code. Sans compter que le front est peut être l’endroit le plus foireux pour faire des choses (compatibilités. Même modernizr se plante !). On télécharge et on exécute plus de fichiers qu’avant..

Retournons un peu vers le serveur

RESS : Responsive Server-Side components

Gestion côté serveur 2 : Le retour.

On oublie les sous-domaines et les redirections, les détections de plateformes, l’amalgame iPhone == Safari, etc.

On oublie aussi la segmentation Desktop/Tablette/Smartphone/Mobile mais on va aller vers une segmentation par taille de résolution (> 1024, 1024-600, 600-320, < 320). On va tenter de faire du user-agent snifing mais pas n’importe comment. On se fout un peu du nom du périphérique mais grâce à lui on va pouvoir connaitre la résolution de ce périphérique (-> taille de viewport). Même comportement qu’au niveau front avec les media-queries.

Le plus dur c’est de récupérer les infos. Pour ça il existe des services qui les répertorient et les mettent à disposition via API ou BDD téléchargeable (DeviceAtlas, 51Degrees, Wurfl). Il faut quand même faire attention à la mise à jour de ces bases et aux mobiles de la liste.

Et si on ne sait pas, on garde le site mobile first et ON LOG LES RÉSULTATS DE MODERNIZR pour actualisation de notre base.

De cette façon on peut gérer le contenu (et les technos) de sa page dynamiquement en fonction de la taille (et ça marche également pour le référencement en servant des images plus légères à GoogleBot-Mobile et des images de bonne qualité à GoogleBot). On peut par exemple faire changer la position d’un élément dans le DOM (ou carrément ne pas l’afficher) plutôt que de le faire changer visuellement avec un CSS douteux.

L’idée est de générer le plus petit DOM possible et le DOM le plus adapté au périphérique.

On peut aussi faire ça avec le CSS (pour ne pas se trimbaler un CSS trop long sur mobile) et les images (tailles, def rétina etc).

Par contre il ne faut pas TROP en faire côté serveur. Il faut juste tester ce qui ne « change pas » : tactile, taille d’écran, PPI, viewport…
Et laisser au client le soin de vérifier le reste : géoloc, online/offline…

QUESTIONS

Q : Des solutions pour éviter d’avoir un cache trop important ?
R : Faut faire attention à ne pas trop découper côté serveur et ne pas vouloir trop en faire donc en se limitant au viewport plutôt qu’au périphérique on doit normalement ne pas avoir un cache trop important.

Q : Pour la gestion des images côté front on peut utiliser les srcset etc, viable ou pas ?
R : Oui pour les nouvelles technos (on oublie les vieilles versions de navigateurs par contre) mais on se retrouve rapidement avec un DOM assez conséquent et pas forcément pratique…

Q : Ne risque-t-on pas de pénalité Google pour envoi de contenus complètement différents selon les devices ?
R : Non, du moins pas eu de retour négatif pour le moment.

Q : Comment gérer le changement d’orientation du périphérique ?
R : On gère ca coté CSS comme actuellement dans les gabarits qui sont chargés. Il faut juste faire attention à ses breakpoints afin que le gabarit chargé soit le même quelque soit l’orientation.

16h – Goutaÿ

On mange, on boit (des jus et du café) et on se repose le cerveau avant la derniere ligne droite

17h – Et si on parlait productivité ?

by @nbirckel
slides : https://speakerdeck.com/nbirckel/et-si-on-parlait-productivite

Les 5 mythes de la productivité

Grosse Journée = Productivité

Quand on fait du 9h – 20h on a eu une grosse journée mais on a eu qu’environ 4h de production effective.
Semaine de 40h != d’un résultat de 40h

Il faut etre dispo tout le temps pour tout le monde

Les interactions polluent votre productivité.
Il y a un moment ou on atteint le « flow ». C’est la concentration maximale, là où on est bien dedans et on ne voit pas le temps passer. Skype, FB, twitter, mails… tout ça coupe le flow et/ou nous empêche de se concentrer assez pour l’atteindre.

Il faut arriver à time-boxer ses interactions

Multitasking = Productivité

Selon la loi de Little qui calcule le temps de traitement d’une file d’attente :

LT = WIP/T

LT : Lead Time, le temps de traitement de la file
WIP : le nombre de projets en cours
T : le temps pour finaliser un projet exprimé en projet / temps

Prenons pour exemple 8 dossiers. En file on obtients 8/(1/10H) = 8*10 = 80H. Mais quand on prend les dossiers en parallèle on ajoute un temps de mise dans le contexte non négligeable…et 8*(10+d)

Nous sommes mono-tâches.Il faut prendre les projets les uns apres les autres pour être plus efficace.

Réunions = Productivité

Ordre du jour trop chargé, personnes non concernées, échanges trop longs etc.. la liste des erreurs est longues. Les réunions sont rarement productives (mais ça peut arriver).

Quelques outils :

• Reu courte et debout (20-30 min max)
• ODJ concis
• Qu’avec les personnes impliquées
• Avoir des actions concrètes en sortie de réunion

On travaille mieux sous pression

Il y a du bon stress mais surtout du mauvais. Le stress engendre de l’anxiété, puis de la fatigue qui génère encore plus de stress. C’est un cercle vicieux qui mène au Burn-Out.

On peut utiliser des outils pour visualiser l’avancement du projet (et faire une « done list » en fin de journée par ex)

Outil proposé de gestion de tâche : https://pomotodo.com/

Si on est trop charette, il faut savoir prendre du recul et dire « non » (surtout aux réunions).

17h30 – L’UX sans Utilisateur n’est que pornographie

by @iergo

L’UX est à la mode mais on a trop tendance à oublier le U de User.

Ici Raphaël nous a compté quelques unes des mauvaises expériences qu’il a vécu au cours de sa carrière pro.

Attention aux client-users qui font un outil pour eux…

Conclusion Perso sur la KiwiParty 2015

C’était top choucroute ! Des conférenciers au top qui ont donné des conférences pointues sur des sujets variés.

Une première participation pour moi et j’ai été convaincu. L’année prochaine j’y retourne ! Enfin… si je suis assez rapide..!!

Photo de couverture par Jennifer Noesser (bruit_silencieux) : https://www.flickr.com/photos/bruitsilencieux/sets/72157654549069978