Enguerran Weiss's List: Mémoire RWD

p. 2 : web = support flexible par définition (diff. print)

p.3 : importance du support de conception : "le choix du support est un acte créatif puissantavant le premier coup de pinceau ou de burin, le support donne une dimension , une forme, une hauteur et une largeur, établissant les limites de l'oeuvre naissante" = pb entre le canvas de Photoshop et le support final (navigateur).

Importance des contraintes du print, qui se sont transmise dans le passage au web : cadre fixe, dimensions absolues, etc...

p. 5 : cit. John Allsopp "A Dao of web design": Nous devrions accepter le fait que le Web n'impose pas les même contraintes et concevoir en fonction de cette flexibilité. Mais nous devons accepter l'impermanence des choses.

p. 7 : def + responsive architecture : une architecture qui s'adapte aux humains qui se présente à l'interieur : ex mur qui se déforme selon la personne qui passe devant. RWD : site réactif, qui profite de la flexibilité du web, plutôt que d'essayer de la contrer / contourner.

p. 15 - : présentation de la grille fluide, la composition flexible. Techs CSS, et adaptation de PSD fixe vers mise en page fluide. CIBLE / CONTEXTE = x em. Par exemple, un titre qui est en 24px sur PS, la taille de police par défaut sur les navigateur (après reset) étant 16px: 24/16 = 1,5em.

Ne pas arrondir les valeurs obtenues.

p. 30 : pour les dimensions des blocs > bloc principal : définir la largeur en %, à l'oeil. Par exemple, pour du 960px > 90%. Ensuite, on prend le contexte de 960px pour calculer proportionnellement les éléments interieurs. Ex : bloc de contenu principal qui fait 900px. 900/960 = 0,9375.

On multiplie par 100, le bloc fait 93,75% de large.

p.48 : pour les images / objects / etc... propriété max-width / pour IE6, width : 100%; pour le rendu des images redimensionnés, sous Windows, rendu dégueu, il faut utiliser AlphaImageLoader.

p. 54 : technique de la mosaïque d'arrière plan flexible (pour créer des colonnes en bg) : ds Photoshop, on calcule proportionnellement la largeur de chaque elément (en l'occurence 2 colonnes), on crée une grande image d'arrière et on recrée les 2 colonnes à partir des valeurs proportionnelles relevées.

p. 60 : négocier le contenu : les images ne peuvent pas seulement devenir plus petites dans certaines situation, il faut les cropper (overflow: hidden).

p.67 : la grille fluide ne suffit pas, des problèmes de hierarchisation du contenu, longueur de lignes, etc... Il faut donc prévoir des points de rupture.

p.76 : zone d'affichage (width et height) et zone de rendu (max-width et max-height).

p.80 : viewport = zone affichée par le navigateur avant son redimensionnement pour les dimensions de l'appareil. Pour rétablir le viewport, on le fixe aux dimensions de l'appareil (device-witdh) et idem pour son échelle (initial-scale=1). Ca permet d'avoir un rendu identique pour tous les appareils.

p. 84 : adaptation = changement de taille de polices, de famille de police (selon la lisibilité)

p. 101 : Pourquoi les media queries ? Elles permettent d'attribuer des propriétés, conditionnellement selon l'appareil qui visionne la page. Media Queries ne veut pas dire Responsive : il faut une grille fluide en plus. Pourquoi ? permet un support des appareils qui ne supporte ni JS, ni les media Queries et propose une solution de secours acceptable. Par ailleurs, il est plus simple de mettre en place des règles pour quelques appareils à partir d'une grille fluide, que de tout devoir redefinir pour chaque taille d'appareil. = moins de développement et moins d'incompatibilités.

p. 102 : Fluide mais on peut appliquer des contraintes si on juge que certains appareils ne sont pas adaptés à notre public. On peut fixer la largeur max du conteneur principal si la lecture sur grand ecran n'est pas adapté à notre cible.

p. 107 : contre-arguments : qui dit accès mobile dit besoin différent de l'utilisateur. Pour Marcotte = extrapolation. On ne peut pas deviner le contexte de visionnage d'une page web. Dans l'absolu, le RWD n'est pas là pour remplacer un site mobile, c'est une solution de design et de stratégie de développemnt qui convient à certains projets. C'est en étudiant ses utilisateurs et ses objectifs que l'on peut le savoir. S'il faut un contenu identique pour tous types d'appareil, le RWD doit se réveler une technique à considérer sérieusement.

Pour Marcotte on ne peut pas non plus utiliser les display: none; pour cacher les contenu que l'on ne juge pas utile aux utilisateurs de mobile, cela pénalise tous les utilisateurs, car il charge du contenu qui ne les concerne pas.

p.111 : mobile first = philosophie de design et technique de stratégie de contenu et de design par amélioration progressive. En partant d'un design mobile, on se concentre sur les objectifs principaux d'un site et le contenu nécessaire à ces objectifs. Ensuite on peut proposer des amliorations : plus de renseignements ? plus d'éléments de décors ? pour servir ces objectifs.

p113 : identifier les points de ruptures. Pour Marcotte = première phase du dev. A partir des données sur nos utilisateurs, il faut identifier les points critiques. Le reste se fera grâce à la grille fluide.

p. 115 : Conception / création : on ne peut pas prévoir chaque vue pour chaque appareil dans Photoshop : pb de temps, de rentabilité. Pour Marcotte, il faut une phase de conception / développement hybride. EN partant d'une maquette au format bureau, toute l'équipe (créa et dev) discute de la façon la plus appropriée pour casser la page selon les points de rupture identifiés. C'est un brainstorming dans lequel un max de problème dus aux changements d'interfaces doivent être identifiés (comportements de l'interface, interactions, mise en page, compatibilité).

Si la maquette est validé par l'équipe, on crée un prototype. Puis phase de tests. Dans cette phase, toute l'équipe devient designers en suggérant des améliorations, validées ou non.

p. 118 : Dernière phase : test de l'interactions sur les différents appareils, lors d'une réunion pendant laquelle tous les membres tests toutes les fonctionnalités et s'assure de son accessibilité.

p. 121 : au final, l'idée est de casser les cycles de prod traditionnel pour avoir une équipe dev et design qui travaille plus étroitement.

Reste du livre : pb de compatibilité si pas de JS, et avantage de l'approche mobile first dans ce cas.

bonne et courte définition

témoignages de pro