Mon site professionnel [h2o.be] : ouvert aux critiques

(reprise du message précédent)

Le fond de l'incompréhension me semble être ceci : les clients mobiles sont des "clients pauvres", et les navigateurs mobiles n'ont pas les mêmes capacités de traitement ni de mémoire que les navigateurs desktop : processeurs lents (pour être moins consommateurs d'énergie), pas de disque dur, etc. D'autre part, la bande passante est souvent plus réduite, et toujours plus coûteuse.

Pour prendre un cas extrême, le navigateur mobile le plus léger actuellement... est une appliquette Java de 55Ko. Moins extrême, le développement actuel de Minimo est très révélateur de ce problème majeur : le test décisif de chaque nouvelle bêta est celui des plantages pour cause d'exigences mémoire trop importantes pour les machines.

Un "système simple" de redimensionnement est donc techniquement très difficile à mettre en oeuvre. Et ne résoud pas le problème de bande passante. L'optimisation du contenu Web HTML passe inévitablement par un tri, lorsque l'adaptation n'est pas possible ou se révèle trop lourde...

Enfin, la problématique du Web mobile actuellement n'est pas de bénéficier d'un contenu spécifique (avec des attributs permettant de lui adresser des images réduites), mais de traiter le HTML existant (l'échec du WAP a été suffisamment manifeste pour que cette leçon soit comprise). C'est pourquoi il est nécessaire de se servir au mieux du HTML existant pour faciliter ce traitement.

Sans compter que la diversité des clients mobiles (du plus pauvre au PDA) est suffisante pour qu'il soit illusoire d'adresser utilement un format d'image unique. C'est d'ailleurs l'un des enjeux des nouvelles techniques élaborées au sein du W3C : les Composite Capability/Preference Profiles (CC/PP) permettront de recourir à une véritable négociation de contenu selon les capacités précises du client, que celui-ci pourra exprimer via HTTP.

On pourra alors, sans doute, oublier ces attributs d'images. Mais pas avant
Modifié par Laurent Denis (18 Aug 2005 - 20:13)

a écrit :
Le fond de l'incompréhension (...)

Les concepts de mémoire, d'encodage et compagnie, ce sont choses acquises; la question que je me posais c'était explicitement : "sur quels critères du média image lui même, un navigateur PDA se base t'il pour l'afficher ?"

Sa taille et son poids, deux critères qui semblent évidents (mais comme vous avez l'air de vous intéresser de près à ces navigateurs, peut être que certains supportent tel ou tel format et pas d'autres, et c'est cela qui m'intéresse d'apprendre, si vous le savez.)

Autres questions, je vous cite :

a écrit :
certaines images (ou autres objets multimédias) ne seront pas téléchargés par le mobile

Comment diable le PDA sait il que l'image contenu dans le HTML va être téléchargée ou non ? En effectuant une requête supplémentaire pour aller vérifier son entête, ou pour effectuer un calcul du secteur de départ et d'arrivé, qui va emcombrer cette "bande passante" déjà fragile ? Utilisez vous, vous même un PDA ? Si oui, pouvez vous me donner l'URL d'une image qu'il accepte et qu'il n'accepte pas d'afficher ? Je vous remercie d'avance.

En ce qui concerne l'appareil, et ce n'est pas le but de ma question, "sa mémoire", je m'en doutais ... Il est évident qu'un PDA ne peut pas mémoriser autant de données qu'un PC. L'OS d'un PDA occupe une centaine de Mo d'espace (Windows Media Mobile par exemple), je vous laisse en déduire la prise en charge des appareils /logiciels tiers.

Il n'a donc également de part ce fait aucunement besoin d'un processeur 2 Ghz. Un "simple" 300 Mhz sera amplement suffisant, 128 Mo de mémoire vive, une restitution de 16 bits de données graphiques et un modem 56kbps sont largement aptes à afficher des images.

Quand aux CODEC de celles ci, ils sont identiques; les formats GIF, PNG ou JPEG téléchargés d'un PC sont exploités par un PDA. Cela dit, cet appareil lit ou télécharge des médias vidéos et musicaux au formats divers a des bitrate élevés; alors question processeur, je ne pense pas que cela soit génant pour lui d'afficher une image !

a écrit :
est une appliquette Java de 55Ko

Il est possible, avec ce seul volume, d'afficher plus de 15 captures d'écran optimisées (ce ne sont pas des paroles en l'air; sur simple demande, je vous en fait la démonstration) Il est encore une fois certain que si une page contient des images JPEG pour des captures d'écran, on ira pas loin.

J'en reviens à mon problème initial (pour lequel je "milite"), toutes les images que j'ai pu analyser sur le web sont loin d'être optimisées, deux à "x" fois trop lourdes, et le potentiel de leur format méconnu, et souvent employé à tort. C'est comme si tous les sites web étaient en HTML 4.01 et qu'il existe XHTML 1.0 Strict, vous voyez ce que je veux dire ?

L'accessibilité que vous défendez avec tant de volonté à travers OpenWeb ou Alsacréations (tout à votre honneur) ne dépend donc pas seulement de la qualité du média HTML, mais également de celui de tous les médias du web, format image inclu. Les standards permettent, par la même occasion, de réduire considérablement la taille des médias, et donc le travail des serveurs, et c'est particulièrement vrai avec PNG qui se démarque largement à ce niveau. Si de plus le média image peut être exploité sur d'autre plate-formes (PDA) selon leur résolution et leur poids, l'optimisation des images est un thème difficile à négliger... pour un site tel OpenWeb, qui prône les standards du web (facile à dire ). ... bon le sujet original c'était quoi déjà ?

original.defeat a écrit :
"sur quels critères du média image lui même, un navigateur PDA se base t'il pour l'afficher ?"

Prenons le cas d'Opera et des modes Small Rendering (qui concernent donc les mobiles et non les PDA. Pour ceux-ci, les modes Medium screen rendering n'intervienent sur les images que pour les redimensionner). Quelques exemples rapides :

En mode CSSR ( écrans de largeur entre environ 200px et 320px):
- les très petits images de moins d'une dizaine de pixel ne sont pas téléchargées si le navigateur connaît leur dimensions, et ne sont en aucun cas affichées.
- les autres images sont redimensionnées si nécessaires

En mode MSSR (écrans de largeur inférieure à 200px environ) :
- la barre de refus des petits images s'élève : une image inférieure à 36x36px ne sera pas téléchargée si ses dimensions sont connues, et ne sera en aucun cas affichée.
- les images de grande dimensions seront également supprimées de la même manière. Le rapport hauteur/largeur intervenant de façon plus importante. Par exemple, un 800x600 sera éventuellement redimensionné, mais un 800x800 sera supprimé.
- les autres images sont redimensionées.

La suppression des images de petite taille est évidemment liée à leur rôle fréquent (pour ne pas dire quasi-systématique) comme élément de présentation. Celle des éléments de grande taille est liée à l'impossibilité éventuelle, selon leurs proportions, d'obtenir un rendu acceptable compte-tenu de la taille et des proportions de l'écran.

a écrit :
Comment diable le PDA sait il que l'image contenu dans le HTML va être téléchargée ou non ?

Si les attributs de hauteur et de largeur de l'image sont présents, le navigateur décide sans avoir de requête à adresser. Ce qui est justement le but du jeu...

a écrit :

Il n'a donc également de part ce fait aucunement besoin d'un processeur 2 Ghz. Un "simple" 300 Mhz sera amplement suffisant, 128 Mo de mémoire vive, une restitution de 16 bits de données graphiques et un modem 56kbps sont largement aptes à afficher des images.

Oui. Mais il s'agit là de PDA : on est très au dessus des chiffres correspondants pour la majorité des mobiles.

a écrit :
Il est encore une fois certain que si une page contient des images JPEG pour des captures d'écran, on ira pas loin.

Bien-sûr : l'utilisation judicieuse des formats favorise également l'accès au Web sur le media mobile.
Modifié par Laurent Denis (18 Aug 2005 - 23:19)

@ Bob (MC Melun) :

a écrit :
Euh, pas le droit d'installer des trucs sur le poste du bureau

C'est un simple fichier exe, ça ne s'installe pas. Oui, téléchargez le. Il ouvre une fenêtre dans laquelle vous pouvez faire des glissés-déposés. Dès lors, il génére un équivalent PNG de l'image (ou des images) que vous avez mis dans la fenêtre. Par contre sous Paint, plus de JPEG. Sélectionnez BMP 24bits (ou mieux 256 couleurs, mais les couleurs risquent d'être un peu fantaisies selon la capture !) et donnez ce fichier BMP à PNGOptimizer.

L'URL que j'ai donné montre clairement son fonctionnement : on sélectionne depuis l'explorateur, glissé déposé dans la fenêtre du logiciel.

- - - - - - -

@Laurent Denis :

Ces appareils se basent donc uniquement sur ces attributs, et c'est une grave erreur. Je reprends l'exemple (l'erreur) que h2o a commis sur sa page, et qui est fréquente : celle de redimensionner dans le HTML avec les fameux attributs; mais son poids lui, n'a pas changé. Admettons qu'elle est été dimensionnée à une résolution acceptable pour un mobile, avec 255 Ko de poids toujours bien réel ... j'aurais aimé voir ce qui ce serait passé.

Je pense qu'il soit peut être difficile de normaliser tout ceci, car cela dépend de la résolution de l'appareil lui même apparemment (avoir des quota de résolution strict par exemple).

Quand bien même, vous avez raison, mais je n'utiliserai toujours pas ces attributs, pour les raisons citées précédemment. J'en ajoute une autre : le fait de dimensionner une image haute résolution en "petite" résolution la rend complètement illisible.

Une solution serait peut être d'effectivement créer des miniatures d'images qui feraient un lien hypertexte vers une page qui contiendrait l'image en taille réelle disons. Du travail en plus qui a ses avantages... et ses inconvénients. Ca fait penser à l'époque où on créait un site pour NestScape et un pour IE...

Enfin, la navigation par mobile n'est pas une "fatalité", c'est un choix; tout le monde est bien conscient que l'affichage ne sera pas identique que sur l'écran d'un PC, cela c'est impossible... de part ce fait, je ne vois aucune raison de remettre tous les attributs de centaines de captures si c'est pour les supprimer demain.

Sur ce, ce n'est qu'un avis personnel. qui est contraire aux normes ! (... sont pas optimisées vos "emoticônes" ... )