Contraintes du Web et conseils

Lorsque le maquetiste graphique travaille seul et sans contraintes, il peut être amené à imposer implictement des stratégies de réalisation très coûteuses, en temps ou en performances.

En théorie, l'extrême d'une maquette graphique serait une réalisation en image "pleine page" de la maquette, un peu comme pour les production CDRom interactifs. Evidemment, c'est un cas extrême pour le Web étant donné les poids d'images que chaque page représenterait pour l'utilisateur. De plus, ceci limiterait l'usage du Web à une simple projection graphique d'objets "marketing", ce qui ne représente en fait qu'une part très minoritaire de son usage. Le maquetiste qui travaille pour préparer un visuel d'un site classique ne fait que produire un prototype figé, une photographie d'une application mobile et dynamique. Même s'il est souvent souhaitable de maquetter toutes les diverses représentations d'écrans, dans tous les cas de figure (ne serait-ce que pour faciliter la prise de décision par le maître d'oeuvre), cet exercice est extrêmement coûteux en temsp et donc en budget.

On demande donc plus souvent au maquettiste de fournir les grands scénarios d'affichage du site qui est en projet, puis une charte de style précise et applicable dans la majoroité des situations. Lorsqu'un cas sort de l'ensemble de décidabilité "artistique", le maquettiste est sollicité à nouveau pour compléter les choix graphiques. Voici, en tout cas comment un partage des rôles devrait être établi dans une équipe professionnelle.

Contraintes sur les dimensions de l'espace d'affichage

Si l'infographiste papier peut dans une certaine mesure proposer son format d'affichage (un projet peut justifier par exemple, d'utiliser un format non standard), le designer Web est lié aux disponibilités et aux habitudes locales des utilisateurs.

Les premiers Webmasters ont eu à lutter pour conserver un affichage cohérent entre des écrans 640x480 (CGA) pixels et 800x600 pixels (EGA). Ceux d'aujourd'hui sont tout aussi préoccupés par les perturbations du passage du 800x600 (EGA) au 1024x768 (VGA).

Quid du XVGA ?

Le XVGA (1280x1024) est un format spécifiquement développé pour des applications à haute définition graphique sur des 21". L'utilisation de telles résolutions sur des 15" ou 17", actuellement le plus répandus (même pour les écrans plats) fait plutôt mal aux yeux dans les utilisations courantes.

Peut-on compter sur d'autres évolutions dans le futur ?

Vraisemblablement pas immédiatement dans le domaine du grand public. L'accroissement de la résolution a été beaucoup plus motivé par l'accroissement des surfaces graphiques utilisées par l'informatique, que par une nécessité d'augmenter la finesse de l'image. On peut imaginer évidemment des écrans de 24" puis 30", mais leur utilisation n'est pas du domaine grand public. Donc, sauf pour des technologies très spécifiques de "murs d'image", il n'y a pas nécessité absolue de penser à une augmentation des résolutions.

Ouverture à débat :

Discussion : [Ouvrir]	Messages :		Indice d'opinion
J'ouvre ici ce débat sur ce point.
[Nouveau postage]	[Ouvrir tout]	[Trier par opinion]	[Que les pour]

Cela peut paraître trivial, mais le designer préférera toujours un découpage en zones de l'écran entrant dans une grille carrée de lignes et de colonnes. En effet le développeur de pages va répondre à deux exigences :

• Maitriser le glissement de la structure de page en fonction des redimensionnement de la fenêtre du navigateur.
• Minimiser la charge graphique de la page pour diminuer son délai de présentation au public.

A ces deux contraintes s'ajoutent celle de la gestion d'espace sur des portails très dense en information. Dans de telles situation, le développeur de page va demander au réalisateur le plus d'espace possible pour le contenu informationnel. Certains choix graphiques d'habillage induisent des pertes d'espace par les gouttières larges qu'elles imposent.

Ces deux exigences appuient la préférence d'une grille nette. Voici trois exemples opposés qui illustrent ces contraintes :

Une telle maquette pose évidemment un problème de structure de tables HTML car elle demande une construction complexe de recouvrement de cellules. La maîtrise du redismensionnement risuqe également d'être difficile. Du moins, cette technique par table ne pourra être utilisée avantageusement, sauf au prix d'un découpage en grille de toute l'implantation graphique. Pour un "cover" de site, on pourra admettre cette difficulté. De telles organisations s'avèrent très difficile à produire lorsqu'elles forment le contenu intérieur du volume documentaire.

Dans cet exemple, on peut noter un choix graphique d'un marquage de zone arrondi qui imposera très probablement des marges inutilisables (indiquées en rouge) si l'on souhaite que l'encodage de structure reste simple.