Tester son site sur appareil portatif

Bonjour

Pas possible de déterminer de résolution particulière dans la mesure où les PDA ont de plus grands écrans qu'un téléphone. Pour eux, on s'oriente depuis l'an dernier vers une apparente standardisation du 240x320.

Aujourd'hui il est difficile de répertorier modèle par modèle la réaction aux affichages d'images plus grandes que ces 240px de large. En pratique les téléphones déterminent une taille (poids) d'image qui leur est propre : en dessous elles sont affichées réduites, au dessus elles sont ignorées. Mais il y a tant de modèles nouveaux qui sortent sur le marché que les tester un par un est aussi fastidieux qu'inutile. Avant d'arriver à des "bonnes pratiques" il faudrait définir quelques protocoles de tests de réactivité à telle ou telle limite, que ce soit pour les langages ou pour les objets embarqués. On en est encore très loin

Nolem a écrit :
Salut Hermann,
Je trouve que ton lien est pas mal. À propos de la mise en page d'un site pour un mobile. Sais-tu qu'elle est la résolution maximale ?
++

Je cite:

a écrit :
Most screens of mobile devices are less than 200 pixels wide

ce qui correspond a peu prés à ce qu'explique Arsene.
Si tu cliques sur chaque point de contrôle invalide, des conseils sont donnés et le lien "help me to fix it" est fort appréciable.
En fouillant un peu on tombe par exemple sur ce tableau comparatif entre les XHTML élémentaire (basic) et XHTML MP (Mobile profile).
La problème est que si un site optimisé pour les appareils portatifs implique
de créer deux documents (XHTML+XHTML basic 1.1 ou MP 1.2), on est alors confronté à une charge de travail supplémentaire importante, ou alors j'ai pas bien compris comment gérer ça.

Arsene a écrit :
Aujourd'hui il est difficile de répertorier modèle par modèle la réaction aux affichages d'images plus grandes que ces 240px de large. En pratique les téléphones déterminent une taille (poids) d'image qui leur est propre : en dessous elles sont affichées réduites, au dessus elles sont ignorées. Mais il y a tant de modèles nouveaux qui sortent sur le marché que les tester un par un est aussi fastidieux qu'inutile. Avant d'arriver à des "bonnes pratiques" il faudrait définir quelques protocoles de tests de réactivité à telle ou telle limite, que ce soit pour les langages ou pour les objets embarqués. On en est encore très loin

Oui tout à fait, d'ailleurs va savoir ceux qui peuvent gérer le média handheld? Appart Opera SSR et un navigateur Opera pour portable je crois, je n'en connais pas d'autres.
La plupart se basent encore sur la CSS screen.
Modifié par Hermann (17 Jul 2007 - 11:47)

Salut,

Suite à un autre sujet je poste ici l'adresse d'un article de pompage : Design de poche : Porter votre site web au petit écran. Et les recommandations pour l'iPhone.
Modifié par Patidou (17 Jul 2007 - 13:11)

Sinon je me demande si minimo supporte le media handheld.

Patidou a écrit :
Salut,

Suite à un autre sujet je poste ici l'adresse d'un article de pompage : Design de poche : Porter votre site web au petit écran. Et les recommandations pour l'iPhone.

Oui je l'ai déjà lu, il y a quelques bonne pratiques à employer et des point intéressants mais comme l'explique Laurent Denis sur son blog,

a écrit :
L'accès aux contenus Web sur les mobiles, par exemple, tient moins à leur présentation (contraste des couleurs, taille des caractères, multi-colonnage, etc) qu'à la nature du contenu lui-même (compacité du code économisant la bande passante, dimensions et poids réels des images, non support des frames, difficultés rencontrées avec Flash et autres objets faisant appels aux plugins, difficultés rencontrées avec le javascript et les pages dynamiques, etc). On se reportera ave profit aux normes de structuration propres à ce media : XHTML basic et sa variante XHTML Mobile Profile ;

Merci pour le lien I-phone, ça peut servir.

Pour le support du média handheld, cet article pourrait t'interessser même si il date un peu.
Modifié par Hermann (17 Jul 2007 - 14:58)

Hello,

Hermann a écrit :
La problème est que si un site optimisé pour les appareils portatifs implique
de créer deux documents (XHTML+XHTML basic 1.1 ou MP 1.2), on est alors confronté à une charge de travail supplémentaire importante, ou alors j'ai pas bien compris comment gérer ça.

Via XML / XSLT.

Lorsque le site doit être portable sur différents supports, XML est le format idéal. Toute la "mise en forme" est gérée via XSLT (on produit le XHTML+XHTML basic 1.1 ou MP 1.2 à partir de là mais la description des données originale est unique -> à peu près le même principe que d'avoir une feuille CSS par media ; on n'a qu'un seul code XHTML qui sert de base).

Merci pour les liens...

À l'heure actuelle, est-il vraiment nécessaire d'utiliser ces versions spéciales d'xhtml puisque de toutes façons les navigateurs actuels sur mobile gèrent parfaitement les versions «normales»? Évidemment, comme dit Laurent, il ne faut pas commencer à utiliser des frames...

Et pour ce qui est des images, les images devant s'afficher sur Opera Mini sont d'abord moulinée par un serveur avant d'être envoyées pour réduire leurs poids. Je parle ici des images normales (photos, etc), les images associées aux CSS, ça c'est normalement le designer qui doit gérer ça même si le serveur d'Opera en est capable aussi.
Modifié par Patidou (17 Jul 2007 - 15:28)

Hermann a écrit :
Oui tout à fait, d'ailleurs va savoir ceux qui peuvent gérer le média handheld? Appart Opera SSR et un navigateur Opera pour portable je crois, je n'en connais pas d'autres.
La plupart se basent encore sur la CSS screen.

J'utilise depuis plus d'un an un Sony-Ericsson w900i (évidemment déjà largement dépassé...) qui implémente Xhtml, Css et JS... Il tient compte des feuilles Handheld sans problème, que ce soit par l'outil de navigation natif ou via Opera Mini.
En revanche il se passe des choses curieuses au niveau de la gestion des tailles de polices : apparemment il "limite" la taille des <h> ce qui fait que l'"architecture sémantique" a tendance à disparaître, puisque souvent <h1>, <h2> et <h3> ont strictement la même taille. D'où par exemple l'intérêt de les gérer en chromie dans handheld...

Je crois que les doublages de versions (2 fichiers Xhtml distincts) sont une aberration temporaire, le temps que tous les fabricants se calent sur des normes communes. Il est de loin préférable de ne produire qu'un seul contenu et d'attendre sagement que tout ce petit monde le restitue correctement, peut-être l'affaire d'un an ou deux ??? ...même i-phone s'y mettra je suppose.

En revanche la vraie question à se poser est celle du volume de contenu distribué et son organisation. Vu ma (toute) petite expérience dans le domaine je suis actuellement plutôt fan de regrouper tous les menus en haut de page, avec des items de liste renvoyant à d'autres listes du genre :

<h1>Outils de navigation</h1>

<ul id="menu1">
<li><a href="#menu2">menu général du site</a></li>
<li><a href="#menu3">menu de cette rubrique</a></li>
<li><a href="#contenu">contenu de la page</a></li>
</ul>

<ul id="menu2">
<li><a href="#">rubrique infos</a></li>
<li><a href="#">rubrique documents</a></li>
<li><a href="#">rubrique ...</a></li>
</ul>

<ul id="menu3">
<li><a href="jour.php">infos du jour</a></li>
<li><a href="semaine.php">infos de la semaine</a></li>
<li><a href="mois.php">infos du mois</a></li>
</ul>

<h1>Titre contenu</h1>

<div id="contenu">La page en cours</div>

<ul id="menu4">
<li><a href="#menu1">remonter haut de page</a></li>
<li><a href="#menu2">rubriques du site</a></li>
<li><a href="#menu3">rubrique infos</a></li>
</ul>

Suite à quoi via CSS pour la feuille screen on s'arrange pour regrouper "optiquement" tout le début en un seul menu si on veut, en "masquant" les liens servant à passer de liste en liste...
C'est assez pénible de devoir défiler d'interminables listes (+ de 10 items par exemple) sur un portable et je trouve que scinder tout ça accroît de façon significative l'usabilité du site. Comme en plus ça regroupe bien les menus en "unités cohérentes" c'est toujours ça de pris.

Comme toujours il s'agit de compromis et il se trouvera toujours un usage particulier où cette structuration pourra générer des soucis mais si on se place dans une optique d'interopérabilité entre UA ça me semble à l'heure actuelle une solution acceptable -- en attendant mieux, n'ayant ni souris (possibilité de choisir son focus) ni possibilité d'appréhender le contenu global d'un seul coup.

Enfin d'un point de vue technologique il est évidemment préférable d'éviter les menus déroulants, pop-ups*, frames et autres artifices dédiés aux écrans d'ordi... en revanche il va de soi des include PHP ne posent strictement aucun problème, la page étant générée en amont.

*ça c'est pour F.

@Koala Merci pour ces infos! Mais pour cela il faut passer par XML que je ne maîtrise pas encore vraiment.

Arsene a écrit :

J'utilise depuis plus d'un an un Sony-Ericsson w900i (évidemment déjà largement dépassé...) qui implémente Xhtml, Css et JS... Il tient compte des feuilles Handheld sans problème, que ce soit par l'outil de navigation natif ou via Opera Mini.
En revanche il se passe des choses curieuses au niveau de la gestion des tailles de polices : apparemment il "limite" la taille des <h> ce qui fait que l'"architecture sémantique" a tendance à disparaître, puisque souvent <h1>, <h2> et <h3> ont strictement la même taille. D'où par exemple l'intérêt de les gérer en chromie dans handheld...

Ok. J'ai remarqué aussi que le mode SSR d'Opera affichait les textes plus petit qu'en utilisant le même mode via la web developer bar mais d'aprés ce que j'ai lu, cette dernière n'est pas (encore) très fiable pour ce genre de taches.

Arsene a écrit :

En revanche la vraie question à se poser est celle du volume de contenu distribué et son organisation. Vu ma (toute) petite expérience dans le domaine je suis actuellement plutôt fan de regrouper tous les menus en haut de page, avec des items de liste renvoyant à d'autres listes.

C'est une astuce intéressante mais trop contraigante à mon goût
On peut aussi se demander quel type de site est utile sur un appareil portatif. Le côté pratique est évident mais est ce qu'on peut lire de long textes sur de petits écrans sans fatigue visuelle accélérée?
Ensuite au delà des bénéfices directes et personnels que cela apporte je crois qu'il est sain de se demander dans quelle situation on peut utiliser ces appareil sans que son entourage le ressente négativement mais là c'est un
autre débat que nous on auront peut-être l'occasion d'évoquer ici.

Arsene a écrit :

...en attendant mieux, n'ayant ni souris (possibilité de choisir son focus) ni possibilité d'appréhender le contenu global d'un seul coup.

Oui d'ailleurs à ce sujet, on ne peut pas non plus se fier sur les évènement clavier puisque certain sont doté d'un stylet, enfin je crois.

Sais tu quels sont les appareils les plus répandus?
Modifié par Hermann (17 Jul 2007 - 19:43)

Bonjour

Hermann a écrit :
Sais tu quels sont les appareils les plus répandus?

Ben contrairement aux ordis où les OS ne sont pas légion, les navigateurs en nombre restreint et les changements peu fréquents, la vitesse à laquelle apparaissent et disparaissent les modèles de portables (quelques mois) rend impossible toute tentative d'établir un profil-type... En attendant - comme dit plus haut - une normalisation à venir de ces UA on fait avec ce qu'on a.

Hermann a écrit :
C'est une astuce intéressante mais trop contraigante à mon goût

C'est un peu plus qu'une astuce... L'enjeu est celui de l'utilisabilité dans tous les cas. La proposition n'est peut-être pas la bonne mais la question reste ouverte.

Hermann a écrit :
On peut aussi se demander quel type de site est utile sur un appareil portatif. Le côté pratique est évident mais est ce qu'on peut lire de long textes sur de petits écrans sans fatigue visuelle accélérée?

La question centrale est celle du contenu unique pensé en conséquence. On peut se poser celle de la pertinence de phrases introductives systématiques pour les longs textes, suivies d'un lien "passer l'article" par exemple et que CSS masquerait pour les screen ??? Je ne sais pas, y'a tout à faire

Une chose est à peu près sûre, c'est que la consultation par handheld va aller croissante et que la différence entre sites consultables ou pas (ou plutôt très-utilisables et peu-utilisables) sera plus problématique, en terme d'audience, que la différence qu'on connaît sur ordis.

A partir de là se pose effectivement la question du double site... question qui n'est pas farfelue et doit faire l'objet d'une réflexion poussée. Personnellement j'ai la même attitude qu'avec une tendance - aujourd'hui en perte de vitesse - consistant à produire un site "normal" et un site "accessible aux personnes à handicap".

L'affichage d'un contenu est le résultat de rapports de force entre
- des producteurs de machines qui ont tendance à n'aller vers les standards que forcés,
- des utilisateurs qui sont en demande de contenus pleinement consultables,
- des gens comme nous qui doivent tenir compte des contraintes posées par les uns et les autres.

Si on ne développe que des sites uniques on participe (faiblement, mais bon...) à la valorisation des UA standardisants. L'idée est la suivante : dans le monde du portable - plus que dans celui de l'ordi, entre autres à cause du prix et de la rotation rapide - le mimétisme et la prescription sont importants : on achète le même modèle qu'untel parce que ceci ou cela. Si un modèle X permet une consultation que le modèle Y ne permet pas, ou moins aisément, le modèle X se vendra mieux. Si ce modèle X implémente les standards et que le modèle Y ne le fait pas, je ne vois pas pourquoi je produirais deux sites distincts ?

En produisant des sites standards et en s'appuyant sur la demande de "sites utilisables" (le public se fout qu'ils soient respectueux ou pas des standards) on s'inscrit dans une démarche cohérente telle que défendue ici sur Alsa.

C'est à peu près tout ce qu'on peut faire pour le moment

Bizarre, j'avais prévu une CSS pour media handheld pour mon site et ce test ne semble pas le prendre en compte...

Même si ça peut être un argument commercial, il est illusoire de croire que l'on peut obtenir la même expérience utilisateur depuis un Smartphone ou un ordinateur de bureau.
De plus, même si l'iPhone n'implémente pas les feuilles de styles handheld, on peut aisément lui adresser une feuille de styles adaptée grâce aux medias queries.

Patidou a écrit :
on peut donner la même feuille de style css à handeld et iphone

Non d'office, oui en option. L'utilisateur doit être libre de pouvoir choisir si le mode de consultation offert par Apple ou LG (iPhone et Viewty) lui convient ou pas. Disons qu'il faudrait éviter que les utilisateurs soient confrontés à différentes techniques de consultation (par zoom ou design approprié) selon le site, sinon on passe un peu à côté du problème... Un bouton "version mobiles" me paraît pour le moment un bon compromis.

Arsene a écrit :
Disons qu'il faudrait éviter que les utilisateurs soient confrontés à différentes techniques de consultation (par zoom ou design approprié) selon le site

De toutes façons, je pense que dès que l'on fait du design pour mobile, il faut linéariser la mise-en-page et ne plus utiliser de colonnes. Il y a un bon article chez pompage sur le sujet. Il faudra faire attention aux tailles de caractères, et à certains javascript qu'il faudra désactiver.

Je me pose aussi des questions sur les images de grandes tailles qui ont un rôle informatif (ex : titre du site en png avec attribut alt). Je sais qu'Opera passe par un serveur pour mouliner les grandes images mais pour les autres? Que faire?

J'ai rien dit pour les images, la réponse est dans l'article de pompage
Modifié par Patidou (12 Mar 2008 - 15:25)