C’est un peu fatigués, après une partie de la nuit en voiture vers Paris et une autre petite partie de nuit dans un hôtel, grâce aux grèves SNCF qui nous ont privées de notre TGV que cette aventure commence…

Il est 6h30, nous sommes le 8 Juin 2018 à Paris, c’est dur de se réveiller, mais il est temps d’aller au Best Of Web 2018 !

C’est donc une petite troupe d’Homo-Intechus (Laurine, Stéphane, Antoine, Cécilia et Clément), un peu dans la brume du réveil qui s’est rendu à pieds à la grande crypte du Best Of Web 2018 !

Après un bon café, et quelques croissants, nous étions tous prêts à assister aux conférences de la journée qui se tenaient dans deux salles différentes. Ne pouvant tout vous présenter en détail, nous avons pris le parti de ne présenter que nos préférées !

“Cut me some Slack”, autrement dit “Laissez moi un peu tranquille” était le nom de la conférence donné par Morgan Kobeissi, qui a inauguré une des deux salles. Nous évoluons dans un domaine qui se réinvente presque quotidiennement. De nouvelles technologies apparaissent, de nouvelles manières de faire, etc. Et dans le même temps, notre expérience grandit au fil des jours. Prenons-nous (et surtout, disposons-nous) cependant d’assez de temps pour à la fois, rester à la page et ensuite, corriger / optimiser ce que nous savons aujourd’hui pertinemment avoir mal fait hier ? En attendant que vous réfléchissiez à cette question, revenons ensemble sur les idées principales de cette conférence.

L’une des pistes qui a été explorée est le “slack”. Il s’agit d’une capacité (de travail) qui va être sacrifiée dans l’intérêt de garantir une bonne santé (de l’équipe, de l’entreprise, etc.) sur le long terme. Autrement dit et dans les grandes lignes, l’idée est de se garder du temps pour faire autre chose que terminer le plus de user stories possible.

Afin de dégager du temps, il est possible de réduire l’engagement que nous prenons à chaque sprint. Ainsi, nous allons non seulement pouvoir stabiliser notre vélocité (puisque nous serons toujours largement capable de couvrir le périmètre sur lequel nous nous sommes engagés), et d’autre part nous aurons du temps “libre” pour faire ce que nous ne prenons que rarement le temps de faire. Le conseil qui a été donné est de prendre 20% de la capacité pour ce “slack time” sur chaque itération. Enfin, l’un des avantages est aussi que ce temps pourra ponctuellement être utilisé en cas d’urgence / de gros problèmes.

Que faire et quand faire pendant ce “slack time” ? Bien évidemment, il n’y pas de réponses figées pour ces deux questions. Concernant le contenu, on peut penser au refactoring (réduction de la dette technique), ou encore à des montées en compétences (via des MOOCS par exemple). Pour ce qui est de “quand”, là encore c’est à chaque équipe de trouver le bon équilibre. Il est recommandé de faire cela en fin de sprint afin qu’il ne puisse pas y avoir de distraction possible (afin d’optimiser au mieux l’utilisation de ce temps).

Caroline et Héloïse sont venues nous expliquer quelles sont les clés pour réussir à avoir une bonne expérience avec les PWA.

En tant que concepteurs et développeurs, nous avons l’habitude depuis des années de développer nos applications sur des ordinateurs. Nos interfaces sont donc adaptées aux écrans d’ordinateurs. Nous utilisons ensuite la technique du responsive pour adapter ces interfaces aux écrans plus petits (tablettes mais surtout mobiles). Cela pour mener à des erreurs de conception et des mauvaises expériences utilisateur.

Or, aujourd’hui la tendance est de faire des PWA (Progressiv Wep Apps), ce qui veut dire des applications s’intégrant parfaitement aux mobiles. Elles doivent offrir la même expérience que les applications natives. C’est pour cela que les règles d’UX entre les applications Web responsives et les PWA ne sont pas les mêmes.

Le premier conseil donné est de concevoir son application web d’abord sur le mobile, et ensuite de l’adapter à l’ordinateur (technique inversée par rapport à l’habitude). Sans cela, nous avons tendance à trop charger les interfaces mobiles.

Elles nous ont également expliqué qu’il fallait faire bien attention aux utilisateurs de nos applications, et qu’un utilisateur de mobile est différent d’un utilisateur sur ordinateur. En effet, sur mobile nous sommes plus facilement distraits, nous avons peu de temps, l’écran est petit, nous avons plus de difficulté à taper du texte et donc souvent nous n’en avons pas envie.

Une première chose à faire est donc de simplifier au maximum les formulaires : plus les étapes sont courtes, et moins l’utilisateur se rend compte qu’il remplit beaucoup d’informations. Il faut également éviter au maximum de faire utiliser le clavier en utilisant plutôt des composants tactiles.

Pour concevoir les interfaces, Heloïse et Caroline nous ont donné une astuce : afin de savoir quoi afficher, nous pouvons nous poser ces questions : pourquoi les utilisateurs viennent ici ? Quelle est la chose la plus importante à montrer ? Pour une page, nous devons avoir une fonctionnalité. En effet, l’utilisateur doit comprendre rapidement ce qu’il doit faire. Si en 3 secondes il n’a pas compris, c’est qu’il y a un problème avec ce que vous affichez (design et/ou graphisme)

Les Single Page Applications sont omniprésentes de nos jours. Cependant, elles demandent un travail plus grand au navigateur et cela a donc un impact sur la perception de l’utilisateur des performances. Pour palier à cela, le concept de server-side rendering a été créé. L’idée est simple : créer l’état de la page finalisée comportant les composants et les données côté serveur et rendre directement cette page à l’utilisateur sans qu’il ait besoin d’attendre que l’application s’initialise côté client. L’application se comporte ensuite comme une SPA classique. Ce type d’application est parfois référée comme “universelle” (exemple: Angular Universal https://universal.angular.io/) . Sébastien Chopin a eu l’idée de créer la même technologie pour le framework JavaScript Vue.js . Le but est de créer rapidement et simplement une application Vue en server-side rendering avec des configurations Webpack intégrées afin de pouvoir se concentrer sur la création de fonctionnalités. De base, 2 configurations Webpack sont présentes dans un projet Nuxt : une pour le serveur (dans le cas du premier appel qui renverra la page créée côté serveur) et l’autre pour le client (la page étant déjà chargée, toutes les autres interactions utilisateurs entraîneront des manipulations côté navigateur uniquement).

L’avantage de l’utilisation de Nuxt est qu’il suffit d’écrire un seul code pour les 2 comportements client et serveur. Nuxt apporte donc une couche d’abstraction qui permet d’écrire une seule fois la gestion du store. Cependant, puisque le contexte de serveur est présent, il faut être prudent avec la manipulation du store. Mal implémentée, elle peut entraîner des situations de données partagées entre plusieurs utilisateurs différents.

Nuxt.js est pour le moment peu utilisé mais commence à se faire une réputation car il a été mis en place par des instances connues comme La Maison du Monde et Rolland Garros.

La réalité virtuelle est un sujet qui brûle les lèvres de tous les aficionados de science fiction. Avec l’arrivée des nombreux casques de réalité virtuelle comme, entre autres, l’Occulus Rift, le HTC Vive, le Samsung Gear VR et le Sony PlayStation VR, les opportunités se sont multipliées afin de présenter l’information sous un nouveau jour : celui de la VR.

Victor Viale et son ami Pierre Charles encore étudiants à l’IMAC (école d’ingénieur) en 2016 ont eu l’idée de créer une timeline 3D en temps réel des tweets sur n’importe quel sujet en saisissant des mots clés. Le rendu visuel est étonnant : des tweets en 3D géant venant à nous comme si l’information était à la portée de nos mains. Démo ici : https://pierrechls.github.io/tweetscape

Pour parvenir à créer une telle interface, ils ont utilisé les frameworks et API suivants :

• la Twitter API pour obtenir les tweets en temps réel sur un sujet
• A-Frame, un framework pour créer des scènes 3D pour la réalité virtuelle
• Vue.js pour instancier les éléments de la scène et afficher les données
• Vuex pour gérer le state de l’application

A-Frame est soutenu par Mozilla et a pour but de supporter les différents casques VR existants afin d’apporter l’expérience VR à un maximum d’utilisateurs. Une grande communauté se trouve derrière ce framework ce qui permet d’avoir des composants ayant des objectifs multiples : texturisation, gestion de multi-joueurs, ombres, point de vue caméra, etc.

De nombreux projets voient le jour et permettent d’avancer dans l’amélioration de l’expérience VR au sein des navigateurs Web. De plus, avec l’arrivée de WebAssembly, la possibilité d’avoir des performances quasi natives est à portée.

npm est très utilisé parmi la communauté des développeurs JS. Mais côté sécurité, il y a encore des progrès à faire. Thomas est venu nous expliquer comment il a testé tout ça et découvert quelques failles.

La première chose à savoir avec npm, c’est qu’il est capable d’exécuter automatiquement des scripts durant son cycle de vie. Les différents scripts automatiques peuvent être exécutés avant ou après l’installation d’un package, ou encore avant ou après la publication, entre autres. Et ce qui est important avec l’exécution de ces scripts, c’est qu’elle est automatique par défaut. Donc lorsque vous installez une dépendance, un script peut donc être automatiquement exécuté, et ce ne sont pas toujours des gentils scripts…

Avec npm, il est également possible de définir des alias pour des scripts à exécuter. En effet, par exemple nous pouvons définir un alias qui s’appellera “toto” et qui exécutera le script “echo “Hello you””. Cela peut également être dangereux, car npm ne restreint absolument aucun nom d’alias. Tout peut être utilisé. Une personne malicieuse pourra alors définir un alias s’appelant “curl” et exécuter un script qui fera ce qu’il veut avec. Notre bon vieux curl sera alors surchargé et détourné. Et le plus étonnant, c’est que même l’alias “npm” est autorisé ! Imaginez donc ce que l’on peut faire avec…

Un autre de ses exemples était de montrer qu’à partir du script automatique post-install d’un package, il est possible d’exécuter un script ouvrant un client socket vers un serveur que le hacker contrôle. Il sera alors possible d’envoyer à notre insu des informations vers ce serveur ou encore de faire exécuter des commandes aux client et d’en récupérer les résultats.

Il a tout de même mis un bémol sur cette faille. Depuis npm 5, un fichier package-lock.json est ajouté aux projets et permet de figer les versions des dépendances installées. Par précaution, il conseille donc de désactiver l’exécution automatique des scripts. Mais malheureusement, cela peut casser l’installation de certains packages qui utilisent ces scripts pour s’installer.

Il recommande également fortement de ne faire aucune installation npm en root, car les scripts installés ont les mêmes droits que l’utilisateur qui les installe. Imaginez un script “rm -rf /” avec des droits Root…

Après tout ça, nous sommes donc rentrés dans notre contrée transfrontalière en Lorraine, à Thionville plus précisément. L’ambiance était bien plus calme dans la voiture… Cette journée, bien que très enrichissante, en a fatigué plus d’un dans le groupe.

Merci aux organisateurs pour ce très bel événement (un lien vers le site officiel ici : lien ), avec de bonnes conférences, une bonne ambiance, et toujours des super goodies; et aussi à InTech qui nous a permis d’assister à cet événement tous les 5.

Enfin, si vous voulez en savoir plus, toutes les vidéos des conférences sont disponibles ici.