KiwiParty 2015

Par

Baptiste

19/06/2015

(5,00/5 - 2 vote(s))

Date et heure
19/06/2015
08:00 - 18:00

Localisation
L’Escarpe
4 Rue Pierre Montet
67000 Strasbourg
France

C’est parti pour une sixième édition de la désormais plus que célèbre KiwiParty organisée par une agence web chère à tous les alsaciens : Alsacréations. L’objectif de cette journée est échangé, à savoir parler de qualité, de performance et d’accessibilité web.

A noter un changement pour cette KiwiParty 2015 puisque le dual-track a été abandonné pour ne proposer qu’une seule conférence à la fois. Terminé donc les interventions concurrentes pour lesquelles il fallait faire un choix à défaut de pouvoir suivre les deux.

Après une présentation, vraisemblablement de Raphaël Goetter ou Rodolphe Rimelé, se tiendront pas moins de 11 conférences dont WebLife ne manquera de vous communiquer les informations essentielles au travers de cet article qui sera édité en live lors de la journée.

Icon-fonts vs SVG sprites

Par Vincent de Oliveira

Sprites d’icônes mis à mal par les écrans haute définition type Rétina => Création d’images adaptées, mais pas viable. La solution est d’utiliser des icônes vectorielles : icon-fonts & SVG.

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

Slide de présentation

Les personas : comment les concevoir et les utiliser

Par Gwennola Pierre

Les personas sont des personnes fictives utilisées dans le développement de logiciels informatiques. Il s’agit d’archétypes d’utilisateurs possibles de l’application développée auxquels les concepteurs pourront se référer lors de la conception de l’interface. Wikipedia

Intérêt du persona :

Identifier sa cible : ses enjeux, ses centres d’intérêt, ses besoins, ses motivations d’achat et ses freins
Faire des choix
Avoir un référent commun
Concevoir son produit, son interface : Ajout/Suppression de fonctionnalités, contenus, etc.
Augmenter le % de conversion

Il ne faut pas hésiter d’aller chercher les informations pour établir les personas : statistiques, études/infographies, ateliers internes, entretiens utilisateurs, sondages ou encore sur les réseaux sociaux.

Attention, il ne faut pas multiplier les personas (3-4, c’est bien) et identifier un persona principal (persona primaire) qui sera prioritaire dans le cas où le besoin de trancher se fait sentir.

Slide de présentation

Le debug d’applications web simplifié

Par Etienne Margraff et David Rousset

Framework open-source Vorlon.js : Outi de debug web remote cross browser et cross platform.

Sont inclus : Console, Modernizr, DOM Explorer, Object Explorer, XHR Panel et nginspector.

Possibilité de faire du debug d’application web, mais également sur des applications mobiles natives réalisées à partir de Cordova et outils similaires. Debug en JS pour le moment non disponible.

Nous les devs on aime bien les samples, même si sample on peut pas creuser. Etienne

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

Par Antonio Capobianco

Les interfaces graphiques reposent sur une métaphore spatiale. Cette dernière est à la base des comportements experts.

Quand on navigue sur un site internet, on construit une carte mentale des contenus de ce site.

Le problème des sites one-page est qu’ils sont souvent basés sur du contenu sans titre : ils ont un coût cognitif. Chaque partie doit être clairement identifié.

Attention également aux sites à design fluide : problème de stabilité spatiale. Les éléments se repositionnent en effet sans que l’internaute ne soit prévenu.

Il faut exploiter les référentiels en favorisant un mode de navigation par écran. Certaines animations renforcent la mémorisation spatiale. Il est bon de les utiliser, à l’exception des effets de parallaxe abusifs.

Slide de présentation

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

Par Matthieu Bué

Avec les pseudo-éléments, on peut garder un code propre, performant et en se passant de JavaScript.

Démonstration d’exemple : http://codepen.io/Twikito/pen/zGdqVO

Slide de présentation

Le web et ses sales caractères

Par Damien Senger

698 polices de caractères sur Google Fonts. Rien que ça. Un grand choix, mais donc un grand nombre de responsabilités.

@font-face : problème au niveau de la déclaration bulletproof => pour chaque graisse un nouveau nom de typo. Penser à font-style, font-weight et src:local(). Eventuellement faire appel à un « faux gras » : texte de labeur, typographie linéale. Pas adapté à toute les utilisations cependant, notamment au titrage cependant.

icon-font : Problématique d’accessibilité. Penser à un fallback typographique avec les emojis quand l’icon-font n’est pas chargée. Les émoticônes, étant de l’unicode, est compréhensible par les lecteurs d’écran.

Slide de présentation

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

Par Jean-Pierre Vincent

L’outil WebPageTest permet de mesurer les métriques de performances, la vraie expérience des internautes.

Il est important de mettre en place une amélioration progressive, à savoir partir du HTML/CSS et ajouter des fonctionnalités par dessus. Il faut penser aux appareils mobiles avant tout. L’objectif est de sauver l’expérience utilisateur.

Il y a différents éléments sur lesquels jouer, mais globalement faire appel à de l’asynchrone et à du fallback : chargement synchrone de fonts, easy loading des images, prioriser le chargement des contenus.

UX design & hackathon : un guide de survie

Par Laurence Vagner

Prévoir :

Faire des points pour échanger avec les participants
Choisir les outils et les technologies ensemble
Optimiser les exports pour ne pas faire perdre de temps aux développeurs
Gestion de version et collaborer
Clé USB de secours pour partager les fichiers en cas de connectivité limitée

Brainstorming :

Mini workshop : écouter toutes les idées
Au moins 1 persona
Lister la limites des fonctionnalités
Définir les priorités
Lister les usecases
Temps limitée, less is more

Maquettage :

Rapide sur papier ou tableau blanc au départ
Dégrossir le projet (grooming session avec les devs)
Usecases + maquettage papier = prêt à développer
Outils UX : Sketch / Balsamiq / Photoshop + MarvelApp

Tests :

Autour de vous : participants, organisateurs
Inviter des testeurs
Guerilla testing depuis le maquettage avec 1 ou 2 participants (hors équipe), définissez un objectif et observez-les

UI design :

99% de chance qu’il n’y ait pas d’autre designer dans l’équipe
Définissez une identité : guide de style pour les devs
Réutilisez : lib, icônes et fonfs
Agile, simple et efficace

Documentation : Ne pas la sous-estimer !

Pitch/présentation :

Définir dès le début qui va présenter
Préparer un pitch de 5 à 10 minutes
Soyez clairs et concis
Parlez de l’équipe du concept, des problématiques et des solutions
A vous de préparer le support : délivrez un message clairement et simplement

Bonnes pratiques :

Less is more : limitez les fonctionnalités
Formez votre équipe à l’avance
Choisissez ensemble les outils et technologies
Dormez, mangez sainement, limitez l’alcool
Débrief une semaine plus tard (suite, idées, doc, etc.)

Les pours :

Créer un projet en un temps limité et avec des ressources limitées
Super terrain de jeu : équipe motivée, temps dédié à la création, des utilisateurs pour faire des tests
80% du projet en 48h / 20% le reste de l’année
Améliorer sa créativité, sortir de sa zone de confrort
Résoudre les problèmes funs, échanger et découvrir de nouveaux outils

Les contres :

Travail gratuit : choisissez bien
Fatigue : prenez congé le jour suivant
Déséquilibre alimentaire : vous aimez les pizzas
Addiction : malgré la fatigue, vous allez recommancer
Adaptation : lors du prochaine projet en rush, vous saurez vous adapter et mieux gérer le stress.

Slide de présentation

Le responsive côté serveur

Par Rémi Grumeau

Au départ, on créait des sous-domaines multiples pour gérer les périphériques mobiles. Actuellement, le responsive revient à tout demander au navigateur (écran tactile, taille de l’écran, etc.), ce qui a un coût en terme de performances.

L’idée est de faire du responsive web design en adaptant en fonction des données du user-agent recueillies : RESS (Responsive Design + Server Side Components). Il faut penser gabarit. L’objectif étant d’avoir le plus petit DOM possible et le plus adapté au device qui charge la page.

Et si on parlait productivité ?

Par Nicolas Birckel

Timeboxer ses interactions pour ne pas perdre de temps et rester focus sur ces projets.

Le multitasking est le mal car il faut se réadapter à chaque interruption.

Côté réunion, limiter les longues réunions et préférer des mini-réunions courtes avec un nombre limité de personnes.

Stress, il y a le bon et le mauvais. Le mauvais entraine l’anxiété, qui entraine fatigue et éventuellement un burn-out. Ne pas hésiter à établir des done-list pour être conscient du travail abattu et de l’avancée des projets.

Slide de présentation

L’UX sans Utilisateur n’est que pornographie

Par Raphaël Yharrassarry

Il est primordial de bien connaître ses utilisateurs en posant les bonnes questions. C’est la clé pour comprendre les problématiques d’un projet et atteindre les objectifs.

Contexte d’une méthode non pas à Gilles (Agile), mais à Robert.

Et comme d’habitude, la KiwiParty se terminera par un Quïz avant de proposer à tout le monde – organisateurs, intervenants et passionnés/professionnels du web s’étant déplacés – de décompresser lors de l’::after après une journée riche en enseignements.

Intéressés étant parvenus à obtenir leurs tickets d’entrée lors des courtes vagues d’inscription, rendez-vous à l’Escarpe à Strasbourg.