Il était une fois un pauvre petit pixel, incompris, dévalorisé, que tout le monde prétendait connaître sans le cerner vraiment, tout le temps en vue, mais que l’on cherchait à éviter et qui avait subi de plein fouet, par-dessus le marché, la crise de la HD… Pour qu’enfin vous puissiez vous targuer de tout savoir sur lui, voici le conte du petit pixel et quelle est son influence sur les layouts et les interfaces d’aujourd’hui.

 

La définition à retenir lorsque toute tentative de compréhension a échouée.

Le pixel est une unité propre à l’affichage sur écran. L’impression papier dispose de sa propre unité qui est le point (pratiquement, c’est aujourd’hui la même chose,). Globalement, le pixel est la plus petite quantité d’information que l’on peut envoyer sur l’afficheur. Pour être précis, je devrais dire sur la carte graphique, car après elle, le signal peut être converti en format analogique et envoyé par exemple sur un écran cathodique. Celui-ci, même s’il est calibré pour des résolutions données, ne sait pas, à proprement parler, traiter les pixels. L’abréviation du pixel est px.

 

Viva la résolution !

Un pixel peut être carré ou rectangulaire (dans ce cas, souvent orienté verticalement).

Un pixel ne peut être qu’en deux dimensions. C’est toute la magie des images de synthèse qui transforment un monde en 3D en espace 2D. À ce propos, ce n’est pas parce qu’un film est en 3D (relief) que les pixels qui le composent sont en relief. Le pixel est toujours en 2 dimensions et à plat, mais on les traite après le rendu sur l’afficheur pour qu’ils paraissent en relief (lunettes, dalles spécifiques).

Un ensemble de pixels forme une résolution. Si l’on forme un ensemble rectangulaire de 640 pixels de long sur 480 de large (soit déjà un beau paquet de plus de 300 000 pixels), nous avons une résolution normée appelée VGA. D’autres résolutions sont ainsi standardisées, comme le sVGA (800x600 px), le XGA (1024x768 px), le SXGA (1280x1024 px), le UXGA (1600x1200 px soit pas loin de 2 millions de pixels).

Le rapport d’un format VGA (rapport hauteur /largeur) vaut 1, 3333. Si on réduit un peu la fraction (plus petit dénominateur commun), on obtient un rapport de 4/3, qui est également une norme de taille d’écran. Cependant, des rapports différents existent, comme le 16/9 (1600x900 px, 1280x720 px), 16/10 (1920x1200px, 1280x800 px).

Les fabricants de télévisions imposent aussi des formats qui sont, pour le numérique et l’Europe, le 720p (1280x720 px) et le 1080p (1920x1080 px) en attendant le 4K (4096×2160 px, soit quasiment 9 millions de pixels, tout de même). Cependant ces normes prennent aussi en compte le taux de rafraichissement de l’écran (ou la fréquence, le nombre de fois en une seconde ou l’écran peut changer l’ensemble des pixels) et d’autres valeurs plus commerciales.

Bien sûr, si l’on affiche une petite résolution (480x340) sur un grand écran, les pixels deviennent perceptibles et le rendu est mauvais. Par contre, on ne peut pas afficher plus de pixels que la matrice de l’écran n’est capable d’en afficher. Voilà pourquoi on parle de résolution efficace ou optimale lorsque la résolution d’une interface est en accord avec la capacité matérielle.

Autre considération plus matérielle, un pixel est affiché via une matrice physique qui peut contenir plus ou moins de densité, plus ou moins de micro led, mais nous ne rentrerons pas dans ces finesses dans cet article.

 

Dis, combien tu pèses ?

Un pixel, c’est avant tout un point de couleur. Cette couleur est généralement codée selon un modèle multiplicatif (l’impression sur papier est en mode soustractif, pour info) sur trois couleurs primaires : Le rouge, le vert et le bleu. Plus le taux de chaque couleur est élevé dans ces trois canaux, plus la couleur du pixel tend vers le blanc. Chaque canal est codé lui-même sur un ensemble de valeurs qui généralement aujourd’hui va de 0 à 255. Cela équivaut à une palette de plus de 16 millions de tons possibles pour chaque pixel. Bref, suffisamment pour que l’on ne voit pas les transitions entre valeurs lorsque l’on fait des dégradés.

Pour faire simple, chaque valeur pour un canal est codée sur 8 bits (valeur de 0 à 255). Comme nous avons 3 canaux pour chaque couleur, cela nous fait donc 24 bits pour chaque pixel. Si l’on prend une résolution nominale de 1366x768 px (soit celle de la tablette Microsoft Surface RT), nous avons donc un « poids » d’un peu moins de 3 MB. Si l’image est rafraîchie 60 fois par seconde, pour que la fluidité soit parfaite, le total de mémoire nécessaire par seconde d’image vaut 180 MB !

Et pour éviter un éventuel bouchage de la mémoire, on peut compresser le signal, notamment en ne recodant que les pixels qui sont significativement différents d’une image sur l’autre (compression sans perte), ou en diminuant le nombre de couleurs affichables (compression avec dégradation).

Tout ceci serait assez simple si d’autres méthodes de codage ne venaient compliquer un peu la donne. Par exemple, le noir ou le blanc peuvent être codés sur 1 bit. Les pixels en niveau de gris (les valeurs entre le blanc et le noir) peuvent aisément tenir sur 8 bits. Enfin, on peut aussi vouloir jouer avec des pixels transparents. La transparence peut être codée sur 1 bit si l’on se contente de valeurs franches, ou sur 8 bits si l’on veut obtenir des transparences pondérées. Ces valeurs, nous les ajoutons donc à nos informations de couleurs et nous obtenons le format RGBA (red/green/Blue/Alpha) qui sera codé sur 32 bits.

En rendu 3D, pour les puristes qui utilisent DirectX, un pixel à l’écran est le résultat d’un nombre de passes de calculs complexes qui prends en compte un nombre variable de paramètres (diffus, ambiant, réflexion, ombrage, …). Tout ceci étant bien entendu fortement accéléré par des techniques de calculs performantes (pixels shaders), par des APIs intégrées (DirectX) et par du matériel sans cesse plus puissant (carte graphique, notamment).

Voilà en grande partie pourquoi les graphistes disposent d’une multitude de formats qui couvrent l’ensemble de leurs besoins créatifs, tout en permettant, via la compression, d’occuper moins d’espace.

 

Mais alors bon, c’est quoi le vectoriel ?

Bref, nous venons de voir que disposer des pixels en troupeaux peut vite devenir assez consommateur en place. Sans compter que l’avènement de l’image numérique, notamment dans le domaine du « print », ne date pas d’aujourd’hui, mais d’une période où les disques durs étaient beaucoup plus restreints. Et pour ne rien arranger, la taille des livrables pour l’impression est beaucoup –BEAUCOUP- plus important, notamment pour des raisons de densité. Allez, me direz-vous, qu’elle est encore ce nouveau bazar ? Pour bien comprendre la densité, nous allons reparler un peu de résolutions. Prenez une résolution de 640x480 px et affichez-là sur un écran de 10’ (Pythagore me signale à l’oreillette que cela fait une surface de 7 x 7 pouces, soit 49 pouces carrés ou 324 cm carrés). Vous obtenez alors un rapport du nombre de pixel par cm2. Projetez maintenant la même résolution sur un écran 30’ et vous aurez alors une densité bien moins importante. La densité est donc directement dépendante de la taille de l’afficheur et de sa résolution. On parle de plus en plus de très haute densité, puisque certains devices sont capable d’afficher 2048x1536 px sur seulement des écrans de 10’.

Mais on parlait du Print, là, alors quel rapport, Hector ? La densité est un facteur crucial en impression, puisque en fonction des supports à imprimer, il faudra travailler avec plus ou moins de pixels. Par exemple, lorsque l’on travaille sur une carte de visite, on utilise une densité importante pour que le rendu papier soit parfait (du 300 dpi ou dot per inch, points par pouce), Sur ce document, cela nous fait donc une résolution de 900 px par 500. Imaginez maintenant que je travaille pour une affiche de 4mx3m, à la même densité ! Cela va nous faire un gros pavé de 62000x35000 px… ! Mais en général, on utilise pour les affiches une densité moindre (de l’ordre de 150 dpi).

C’est dans ce cadre qu’a été créé le vectoriel. Ici, plus de notion de pixels. On ne parle plus qu’en courbes mathématiques. Et comme une courbe mathématique est une fonction, on peut assez facilement interpoler un grand nombre de pixel via une fonction qui prend beaucoup moins de place en mémoire que des pixels unitaires. Reste que le résultat est meilleur et plus compressé si le nombre de couleurs est limité, ou que l’image vectorielle dispose de peu de courbes différentes.

Et, en tout état de cause, ce que l’on gagne en mémoire, on ne le perd que marginalement avec Windows 8, puisque le rendu SVG est accéléré par IE 10 et le xaml supporte nativement l’accélération matérielle.

 

Alors, oui, mais on ne fait pas du print, nous !

Oui, c’est exact, les graphistes venant du monde du print et ceux issus du pur numérique ont toujours eu des visions très différentes du métier de création, même s’ils utilisent les mêmes outils. Nous avons déjà parlé de la différence colorimétrique (additives en RVB ou soustractives en CMJN), mais aussi de la densité. Mais le designer d’interfaces pourra légitimement se poser la question de l’utilité de concepts tels que la densité dans son travail de tous les jours, parce qu’au final, pour son affichage, un pixel reste un pixel et qu’il travaille toujours en résolution donnée… Oui, c’est exact, sauf dans les cas où vous devez faire appel à de la rasterisation d’objets vectoriels. Allons bon, Simenon, voilà autre chose ! Car une interface est un mélange d’objets pixélisés et d’objets vectoriels, notamment les polices. Ces dernières sont souvent envoyées á l’affichage sous forme de vecteurs et pixellisées (rastérisées) à la volée. Voilà qui explique en grande partie les subtiles différences d’affichage qui peuvent exister entre une planche Photoshop et un layout Visual Studio : Une composition faite sous le logiciel d’Adobe est paramétrée par défaut en 72 pixels par pouce, alors qu’un layout sous Blend utilise une densité nominale de 96 pixels par pouce. Du coup, les polices Sous Photoshop devront être légèrement agrandies pour respecter la densité d’un projet Visual Studio, ou sinon, on devra porter attention à la densité nominale du projet Photoshop de manière à rasteriser correctement les polices de caractères.

Autre point d’importance aujourd’hui, c’est que l’on travaille de plus en plus en vectoriel, notamment en WPF. Le Xaml fait en effet la part belle aux tracés qui proposent l’avantage d’être redimensionnables et peu sensibles à la résolution. Si vous utilisez la techno alternative, équivalente sous Windows 8, à savoir le HTML, vous pourrez savourer la gestion du SVG (Scalable Vector Graphics) qui permet l’utilisation d’objets vectos dans votre layout. Toutefois, des contraintes sont à prévoir, tant en terme de performances (un trop grand nombre de tracés entraine un temps de calcul certains, même si le process est accéléré) qu’en terme d’interprétation (les contours spéciaux, notamment en xaml sont assez mal interprétés).

Petit nota en ce qui concerne les polices : celles-ci sont lissées de manière spécifique, par l’utilisation d’un algorithme de rendu sous-pixel nommé Clear Type, sous Windows. Cette technique implique un compromis de la chrominance sur la luminance d’une police.

 

Bien bien bien. Et mon layout dans tout ceci ?

Le layout peut, en un sens, constituer un exemple d’anti-pixel, puisque c’est le plus haut niveau d’affichage sous Windows 8. Notamment parce que les applications ModernUI sont plein écran.

Le layout est donc l’ensemble des pixels qui compose l’écran. Quel que soit son format ou sa résolution, d’ailleurs. Et c’est là où les choses se complique drastiquement, puisque dans le monde PC, nous avons à notre disposition une panoplie complète d’écrans qu’il faut tous adresser, depuis le 1024x768 jusqu’à la dalle de grande taille (ou de forte densité, vous avez compris…) de 2560x1440.

Je ne reviendrai pas ici sur les moyens inhérents à chaque solution logicielle pour obtenir une interface fluide, mais plutôt sur la manière et sur la philosophie pour bien y parvenir. À haut niveau, on considère que la philosophie d’affichage des layouts est orientée « blocs », quelle que soit la technologie utilisée. En HTML, on viendra par exemple poser des « div » dans lesquelles on viendra disposer notre contenu. D’ailleurs, ces div peuvent aisément être renommés pour être contextualisé (header, etc…). Même chose en XAML, ou la notion de contrôles est basé sur la logique de blocs (grid, Stackpannels, …). Dès lors, il suffit de bien définir les blocs fixes des blocs mobiles (ou adaptatifs) de notre layout pour obtenir assez rapidement un écran fluide.

Pour autant, au niveau du designer, il convient de créer les maquettes et les wireframes des applications dans 3 résolutions significatives minimum et de toujours prévoir deux form factors (paysage et portrait).

Cela permet notamment de se faire une idée précise de la taille relative des polices, qui disposent souvent d’une taille fixe dans des layout adaptatifs, et de la pertinence des éléments à l’écran. Quelle que soit votre méthode ou votre technologie, ce qu’il faut retenir, c’est qu’il vaut toujours mieux ajouter du contenu, à mesure que la résolution (et donc la place disponible) augmente, plutôt que d’agrandir les éléments, bien que ceci reste dépendant du contexte d’utilisation. Dans cette optique, le layout fluide orienté contrôle prend tout son sens puisqu’il permet de redéfinir l’emplacement des éléments en fonction de la place disponible pour les afficher : Ainsi, le menu Démarrer de Windows 8 propose 3 lignes de vignettes en 1366x768, et 5 en 1920x1080. Ajouter du contenu permet aussi de réduire drastiquement le scroll, ce qui n’est pas à négliger.

 

J’ai un faux-contact.

Le tactile est génial pour l’utilisateur. C’est un fait. Mais il se révèle être le compagnon capricieux des créateurs de pixels. Peu de feedbacks nativement, beaucoup de contraintes et une zone interactive très importante. Oui, la pulpe d’un doigt entraîne une surface interactive 10 fois plus importante que celle d’un pointeur conventionnel. Et la main de l’utilisateur est généralement devant le contenu, bloquant l’affichage de celui-ci et réduisant encore le feedback. Et comme si cela ne suffisait pas, les layouts touch doivent parfois contenir des contrôles du système pouvant phagocyter 50 % de l’écran (clavier virtuel). Un cauchemar qu’il faudra bien intégrer et prévoir pour proposer une interface cohérente.

Le meilleur exemple reste le bouton tactile. Celui-ci devra faire au moins 7x7px et au mieux 10x10 px. Mais nos doigts ne sont pas en pixels, eux. Surtout que comme nous l’avons vu précédemment, la résolution, bref le nombre de pixels, est une donnée floue, puisqu’elle est étroitement liée à la notion de densité et de taille d’écran… Du coup, il conviendrait ici de parler de taille en changeant d’unité et en parlant de millimètres, plutôt que de pixels, unité malheureusement incompatible avec la notion de densité.

Donc, lorsque l’on fait du tactile, on utilise souvent une règle de base pour parer aux situations limites et on joue sur des marges moyennes entre les éléments pour convenir d’un pattern utilisable dans le maximum de configurations possibles. On estime ainsi que 5 px valent en moyenne 4,5 mm. Deux boutons ne doivent pas être disposés à moins de 5 pixels l’un de l’autre. On préconise même de prévoir une zone sensible de 10 px pour le bouton et une marge au moins équivalente afin d’éviter les « faux contacts ».

Pour info, un bouton Modern UI Windows 8 fait 40px de large tandis qu’un bouton Windows Phone 8 fait 84x84px (grosse densité). Bien loin des recommandations minimales, donc, mais c’est en grande partie à cause des fortes densités des écrans d’aujourd’hui.

Et encore, on parle ici de zone de contact physique avec un device. Avec Kinect, donc sans contact physique, la zone de « hit » devra être encore agrandie et temporisée pour offrir tous le feedback nécessaire au le confort de l’utilisateur.

 

Conclusion

Nous l’avons bien vu, le pixel est un ami incomparable pour bien comprendre comment un layout est organisé. Il est l’élément de base d’un système qui ne se comprend qu’au niveau le plus haut. Le designer et le graphiste sont donc confronté tous les jours à une expérience quasi-quantique, certains éléments étant immuables, tandis que d’autres ne peuvent être définis que par l’effet perçu sur l’ensemble. Pour être pertinents dans un contexte pareil, il faudra souvent en passer par une phase qualitative (recherche graphique et maquettes de validation de concept), puis de tester ces rendus dans vos résolutions cibles, et enfin de prévoir vos layouts dans un maximum de résolutions possibles, en faisant des tests (ou des tirages imprimés de validation) pour vous assurer que la densité ne viennent pas ruiner vos efforts. En effet, une taille de police prévue pour du 1366x768, restera agréable sur un écran full HD (1920x1080) de plus de 80 cm, y compris à 5 mètres, mais sera très inconfortable sur un écran 12 pouces. Pensez toujours usage, et dans tous les cas, essayer de prendre en compte les déficients visuels.