Blog Arolla

Automne et Paris Web 2014

Retour à l'accueil - Paris Web, webdesign, accessibilité, qualité

Automne 2014. C’est la saison, direction Paris Web.

Pour cette nouvelle édition, Paris Web s’est déplacé au beffroi de Montrouge, un beau bâtiment, agréablement situé sur une jolie place agrémentée d’un café, et juste en face de la nouvelle station de métro de la ligne 4.
Et comme l’année précédente, Paris Web ne néglige pas votre santé en vous faisant monter et descendre de multiples escaliers entre chaque changement de salle. (; D’ailleurs il fait bien éliminer quelques calories accumulées lors de la dégustation des multiples mets, amuse-bouches, mini-sandwiches et cookies (et quels cookies !!) lors des pauses.

En tous cas, voici quelques retours sur les conférences qui m’ont le plus parlé. (:

Interactions : Animations et interfaces

par Olivia Lor

Lien Paris Web

En partant des grands principes de l’animation décrits par les animateurs de Walt Disney Ollie Johnston et Frank Thomas, Olivia Lor nous explique ce qui rend une animation crédible à la vue d’un œil humain.

Depuis la grande époque des gifs animés dans les années 90, il y a eu une impressionnante évolution de la qualité des interfaces, autant au niveau des devices mobiles que des interfaces purement web. Grâce à cela, il est maintenant possible (et relativement aisé) d’ajouter des animations de qualité sur nos sites web afin de toujours améliorer l’expérience utilisateur.
Bien que l’ajout d’animation soit toujours tentante, il faut se demander si celle-ci est bien pertinente, quel est son but ? Où doit se trouver l’attention de l’utilisateur ? Quels doivent être la fréquence et la mécanique de l’animation?

Cette conférence abordait un sujet très intéressant, mais elle manquait cruellement d’exemples techniques concrets… En effet, si je veux rendre mon animation plus crédible, je vais devoir par exemple ajouter des effets d’étirements et/ou de rebonds en CSS. Mais est-ce si simple de combiner tous ces effets en CSS ? Devrais-je utiliser un GIF animé ?

Présentation des outils de tests Cross Browser

par Cyril Balit

Lien Paris Web

Une petite conférence dans la ligne directe de celle de 2013 sur l’intérêt des tests unitaires en javascript. Simple et efficace. Au vu du nombre croissant de devices (et donc de navigateurs), il devient de plus en plus compliqué et coûteux de faire des tests multi-navigateurs. Bien qu’une recette manuelle doive toujours être faite sur un parc de devices, Cyril Balit nous a présenté ici des infos utiles ainsi qu’une liste d’outils pour nous permettre d’automatiser une partie de ces tests.
Dommage que les tests d’intégration avec Sélénium ne soient pas un peu plus développés, mais ce n’était pas forcément le but de cette conférence. (:

Code de qualité : ce qu’il faut savoir

par Julien Wajsberg et Anthony Ricaud

Lien Paris Web

Pourquoi doit-on produire un code de qualité ? Eh bien, pour la qualité en elle-même, mais aussi la maintenabilité et la réutilisation du code.
Pour en arriver là, Julien Wajsberg et Anthony Ricaud nous exposent différentes bonnes pratiques qui permettent d’arriver à un code de qualité : le versionning, un gestionnaire de tickets, la revue de code, les vérificateurs de code, les tests unitaires et fonctionnels, l’intégration continue, les générateurs de guide de styles et de documentation, et aussi comment avoir une bonne gestion de la dette technique, qui comme l’entropie, a toujours une variation positive, quoique nous fassions.

Le seul point sur lequel je suis mitigée est la revue de code ; je préfère de loin le binômage. La revue de code consiste à faire relire son code par un autre développeur, afin de s’assurer de sa lisibilité et sa simplicité. Comme le binômage, cela permet un partage de connaissance et de limiter le “bus factor”*.

Avec la revue de code, une fois la fonctionnalité développée, un second développeur va lire le code, ce qui implique que deux développeurs vont intervenir sur la même fonctionnalité de manière séquentielle ; à l’inverse du binômage où l’intervention se fait en parallèle. De plus, la revue de code fait du reviewer le responsable du commit… c’est surtout avec ce dernier aspect que j’ai le plus de mal, car cela m’apparaît comme une déresponsabilisation du développer au profit du reviewer. A mon sens, chaque développeur doit être responsable de son code et sa fonctionnalité de bout en bout, afin d’avoir une meilleure implication dans le projet et d’améliorer la pluridisciplinarité. Mais c’est juste une histoire de préférences. (;

* “bus factor” : nombre de personnes pouvant mourir écrasées par un bus avant que l’entreprise ne mette la clé sous la porte.

Dark patterns, la contre-attaque du pire

par Clément Hardoüin

Lien Paris Web

Clément Hardoüin nous présente différents types de dark patterns, exemples à l’appui.
Un dark pattern est un procédé visant à tromper l’utilisateur ou le client, afin d’augmenter son profit. Il semble trouver son origine dans un dévoiement du marketing et d’une dictature de la mesure. Puis il a su profiter de flous juridiques et d’un ineffable problème de régulation à l’échelle internationale, tout en adhérant à la politique du “pas vu, pas pris”.
Un collègue m’a déclaré que cette conférence ne servait à rien, car aucune solution n’existe contre les dark patterns. Que si votre client vous demande d’ajouter cette option floue et pré-cochée vous l’ajouterez (car vous tenez un peu à votre travail).
A mon avis, ce n’est pas parce que les dark patterns sont des pratiques répandues que cela les justifie. Il faut bien commencer quelque part, et informer les gens.

Voici un article qui regroupent quelques exemples : http://www.24joursdeweb.fr/2013/dark-patterns-design-interface/

Comment optimiser le checkout sur mobile ?

par Nicolas El Azzi

Lien Paris Web

Lors de cette petite conférence, Nicolas El Azzi part de la version mobile d’un site de vente en ligne existant, et nous explique, pas à pas, quelles pourraient être les modifications possibles, afin d’améliorer de manière significative le checkout par l’utilisateur.
Par exemple en limitant les scrolls et le nombre des actions, en mettant les infos importantes tout de suite en haut de la page, en affichant le niveau de progression de l’utilisateur au travers du checkout, ou encore en limitant le nombre de champs de saisies à ceux qui sont réellement indispensables. Et évidemment, toujours rendre une version mobile la plus légère possible (mais ça, on ne devrait avoir à la signaler ;)).
Bref, pleins de petites choses à connaître.

Et les web components ?

A mon grand regret je n’ai pas assisté la conférence informelle sur les web components. D’autant plus qu’il ne s’agissait “que” d’une informelle, et que par conséquent elle n’a pas été enregistrée.

Les “web components”. Le terme est revenu plusieurs fois lors de conférences. Ce standard, en cours de validation par le W3C, est déjà compatible avec la version 36 de Chrome. Google (entre autres) a également sorti la bibliothèque Polymer pour la création de ses propres web components.
Finalement qu’est-ce qu’un web component ? Dans les grandes lignes, les web components sont des composants créés à partir de d’éléments HTML custom, ce qui permet d’avoir un composant, encapsulé, indépendant et réutilisable à volonté.

Affaire à suivre. En attendant, voici quelques liens utiles :

* http://css-tricks.com/modular-future-web-components/
* http://component.kitchen/components
* http://webcomponents.org/

Laisser un commentaire

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