Evaluating Technology — Jeremy Keith

Case Study, ioLCE 2017

Introduction

Jeremy Keith

En ce début d’année, nous nous réunissons dans le cadre du workshop IoLCE (input/output, lire et communiquer sur écran). Cet atelier a pour but de nous apprendre à utiliser une méthode de travail centré sur le contenu. Lors du premier jour, nous avons constitué des groupes de quatre personnes et les professeurs nous ont attribué une conférence. Notre groupe (15) analysera la conférence Evaluating Technology de Jeremy Keith.

La finalité de ce travail est de comprendre et de partager le contenu de cette conférence à travers une page web, un abstract et un case study. Nous allons ici vous présenter le case study de l’atelier, qui retrace toutes les étapes de notre travail.

Renseignement, prise de notes et mise en commun

Définitions des termes importants

Première étape : nous regardons la conférence et prenons des notes individuellement. Nous avons fait le choix de traduire toute la conférence pour comprendre tous les détails mentionnés. Nous avons rencontré notre premier obstacle : même si nous nous sommes partagé le travail, la traduction complète a été très longue.

Néanmoins, cela nous a permis de comprendre toute la conférence.

Nous nous donnons ensuite rendez-vous pour mettre en commun les informations et les différentes parties de la traduction. En ce qui concerne les termes liés au webdesign et personnes citées par Keith, nous avons décidé de nous partager le travail de recherche, pour ensuite les regrouper dans un lexique.

La compréhension des termes utilisées, nous a permis de mieux saisir l’essence du discours pour en faire un résumé cohérent et pertinent.

Résumés

Plan de la conférence

Vient alors le moment de rédiger le résumé, qui permettra de construire le plan de notre analyse. Pour ce faire, nous avons procédé ainsi :

  • Nous avons regroupé les idées principales et les avons résumé en deux phrases;
  • Nous avons tenté de trouver des titres pertinents en fonction de ces phrases résumées;
  • Les titres, une fois regroupé, ont permis la création d’un plan.

Avant d’utiliser ce plan pour rédiger notre analyse complète, nous avons créé un premier résumé destiné à être traduit en Anglais pour l’abstract.

Nous avions des contraintes de contenu pour la rédaction de cet abstract. En effet, il ne fallait pas dépasser 1500 caractères. L’abstract est comme la quatrième de couverture d’un livre: c’est un résumé ayant pour but de donner envie de lire l’article complet.

Abstract rédigé

Après rédaction de l’abstract, nous pouvons nous concentrer sur l’analyse complète et l’ébauche de notre article.

Rédaction du contenu de l’article et corrections

Nous nous partageons le plan en deux parties, Eléonore et Thibaut pour la première partie, Julien et Margaux pour la deuxième. M. Thronte est notre professeur référent et peut donc nous aider dans la rédaction et répondre aux différentes questions que nous nous posons. Nous lui présentons une première ébauche pour avoir son avis. Bien que nous ayons compris la conférence, le contenu doit par endroit être modifié. Certains des points traités doivent être développés et certains termes sont maladroits. Malgré les corrections, il reste quelques petits soucis à résoudre. Avec les commentaires du professeur, nous apportons des précisions supplémentaires aux points demandés.

Commentaires de notre professeur

Après corrections, nous reproposons notre article, qui est alors validé par M. Thronte. Nous pouvons maintenant nous concentrer sur la planification de notre case study et commencer à essayer la mise en page et les choix de typographies.

Planification et rédaction de l’article Case Study

Plan du Case Study

Nous planifions alors la manière dont nous allons construire ce case study, qui s’oriente naturellement autour de nos journées de workshop. En gardant une trace du travail effectué, il nous suffit de suivre ces étapes pour ensuite les retranscrire.

Mise en page, fonts et univers graphiques

Pour cette nouvelle étape, il nous est demandé tout d’abord de commencer par la création de paragraphes cohérents. Pour ce faire, nous analysons les couleurs de paragraphes sur google fonts afin de décider quelles typographies seront à tester plus tard. Une fois cela effectué, il nous faut comparer les typographies similaires grâce aux lettres x, o et m. Nous réduisons l’opacité d’une des deux lettres, la changeons de couleur, ce qui permet de voir si elles se superposent correctement ou non.

Superposition des lettres

Il nous faut terminer par le choix de l’interlignage (suivant les rapports de proportions) et les tailles de paragraphes (plus ou moins de caractères par lignes) pour déterminer la disposition des blocs.

Notre choix de typographie est ainsi terminé.

Notre principal souci a été que, après avoir effectué tous ces essais, nous nous sommes rendus compte qu’il nous était impossible d’avoir les graisses italic et bold si nous souhaitions respecter la demande d’avoir un temps de chargement rapide des fonts. Nous effectuons de nouveaux tests pour palier à ce problème mais rien à faire : nous nous résignons à ne prendre qu’une graisse par police utilisée.

A présent, nous devons réfléchir à un univers graphique. Cette partie (comme la précédente), est individuelle et dépend des choix de chacun. Nous créons un wireframe pour nous y aider, réfléchissant à la disposition des blocs par rapport aux éléments graphiques. Il nous faut ensuite procéder au layout pour déterminer si nos idées (un peu brouillonnes encore dans le wireframe) s’additionnent correctement pour créer un ensemble harmonieux.

Exemple de recherches de layout

Une fois ceci fait et validé, il ne nous reste plus qu’une chose à faire : créer le véritable site web.

Finalisation des différents visuels

Plan de travail : layout et résultat HTML/CSS.

La création du site web est totalement individuelle. Avec la base commune de notre texte rédigé, nous passons à l’élaboration des pages HTML et de leur CSS. Bien vite, nous rencontrons chacun différents obstacles.

Obstacles :

Premièrement, nous venons d’apprendre à coder (malgré quelques bases en première année), ce qui a rendu difficile la compréhension et l’utilisation de certaines balises.

Autre souci : le visuel. En effet, en essayant de suivre le layout Photoshop à la lettre, il est extrêmement compliqué (à moins de faire du pixel perfect) d’avoir le même résultat sur la page web. Qui plus est, en ne possédant pas la même résolution sur l’ordinateur où a été fait le layout et sur celui où est réalisé le code, les typographies semblent ne pas correspondre parfaitement. Il nous faut mettre une résolution en 1440 de largeur pour obtenir un résultat similaire.

D’ailleurs, certains éléments introduits dans le layout Photoshop sont difficiles (avec nos connaissances actuelles) à reproduire en HTML/CSS. Il faut donc s’adapter en changeant certains détails.

Ensuite, la colorimétrie des écrans a elle aussi perturbé les recherches du visuel final. Pendant la phase de recherches graphiques, nous n’avions pas pris en compte les couleurs de liens, qu’ils soient visités ou non ou en hover. De fait, il a été difficile de trouver des couleurs qui s’accordent sur des écrans aux colorimétries différentes pour donner un visuel harmonieux. La luminosité des écrans a aussi joué.

Enfin, ça n’a pas été aussi évident que l’on a pu le croire d’accorder la page de la conférence et la page de l’abstract. Des changements de design ont dû être opérés puisque la quantité de texte était bien moindre.

Opportunités :

Le fait de rencontrer ces différents obstacles nous a permis de découvrir beaucoup de choses et de nous adapter à différentes situations. Nous avons alors surmonté ces difficultés.

Ce projet a été à la fois un travail collectif et également individuel, nous forçant à faire preuve d’autonomie et de réflexion personnelle.

Nous avons beaucoup appris de l’expérience ioLCE et avons mis un pied dans le monde du web design. Nous avons hâte de continuer et d’apprendre de nouvelles choses.

Article écrit par Julien Debrauwer, Margaux Membré, Eleonore Monnom et Thibaut Vermeulen.