Blackberry et media Handheld ?

(reprise du message précédent)

Raphael a écrit :
De notre côté, on va devoir s'acheter un iphone ou deux

Sinon il y a l'ipod touch ou l'émulateur avec xcode mais là il faut un mac...

Laurie-Anne a écrit :
J'avais lu un article à ce sujet (mais je ne saurais plus donner le lien) qui disait (en résumé) que de nombreux fabriquand décidaient délibérément de ne pas faire reconnaitre le media handheld, parce qu'il considéraient que les développeur allaient fournir pour ce média une version plus moche et que donc il était préférable pour les utilisateurs que ce soit la feuille de style destinée à screen qui soit utilisée.

C'est pas exactement ça, déjà parce que les fabricants s'en tamponnent de ce qu'on livrera
Handheld est problématique au sens où (1) ça pourrait laisser croire que une feuille handheld règle la question des mobiles, ce qui est faux - la question des mobiles est : quel contenu on leur envoie ? - et donc ne pas implémenter handheld contraint soit à penser des sites plus light soit à se poser la question de la préparation des contenus en amont de la distribution, et (2) l'évolution des outils rend handheld évidemment caduque à terme. Cette dimension qui n'était pas du tout évidente à percevoir il y a deux trois ans est aujourd'hui largement acquise, et développer handheld pour un fabricant est aujourd'hui une perte de temps/énergie/argent, etc. Donc effectivement on constate que handheld est de moins en moins implémenté. Dans un sens c'est une bonne nouvelle.

Quand à votre prob de BlackBerry vous ne devriez pas vous en préoccuper. Si un UA n'implémente pas de façon standard les contenus normés, on est dans deux cas de figures : soit c'est parti pour plusieurs années (cas IE où il peut se passer 2, 3, 4 ans entre deux versions) et on trouve des correctifs (hacks, commentaires conditionnels, etc), soit on est sur mobiles et la rotation du parc est telle que les modèles qui ne restituent pas correctement les standards disparaitront de façon quasi-darwinienne par sélection naturelle.

Je reste persuadé que la détection non pas de l'UA mais de la fenêtre/viewport reste un filtre efficace permettant de proposer optionnellement une feuille CSS à part (handheld ou pas), mais surtout de générer des contenus distincts. Il n'y a aucun intérêt à proposer sur mobile l'équivalent exact d'un site screen. Dans le cas d'Alsa il me paraîtrait plus pertinent par exemple de proposer le forum par défaut à l'ouverture (je parie que la consultation Alsa sur mobiles est - hors essais actuels - à 95%-99% du forum) et de découper les pages des posts pour n'en présenter que deux ou trois au lieu des vingt actuellement en screen. Ça c'est autrement plus important que de se demander si sur tel ou tel modèle la mise en page est jolie ou pas, non ?

J'ai parfois l'impression qu'on refait un bond en arrière pour revenir à l'équivalent iPhone du "optimisé pour IE" honni d'autrefois. Ce n'est pas la bonne démarche que de se préoccuper de tel ou tel outil de sortie qui ne tient pas compte (ou insuffisamment, ou mal) des standards. Ça ne vaut même pas les 10 minutes à se demander pourquoi. Par contre passer 10 minutes de plus à faire en sorte que l'utilisabilité/ergonomie sur mobiles soit mieux prise en compte, notamment à travers la pertinence des contenus distribués (lesquels ? comment ? pourquoi ?) me parait bien plus utile. Se lancer dans tout un binz pas possible pour détecter qu'il s'agit bien d'un Bold 9000 pour afficher au final des pages avec 50 scrolls me parait légèrement surréaliste

Donc au final offrons plutôt une "prime au standard" en travaillant pour les UA qui les respectent (et pour les utilisateurs qui s'en servent) en améliorant la qualité du service web, plutôt que l'inverse : à chercher comment pallier aux insuffisances on accrédite la démarche consistant à faire reposer sur les producteurs de contenus seuls la responsabilité de l'insatisfaction utilisateur potentiellement liée à l'absence de leur prise en compte. Faudrait quand même pas perdre de vue le "until user-agents..." des Wcag qui nous accordent ce fardeau de façon temporaire.
Modifié par Arsene (11 Mar 2009 - 16:15)

Arsene a écrit :
pour afficher au final des pages avec 50 scrolls me parait légèrement surréaliste

Ah oui surtout quand on tombe sur une intervention d'Arsène

Merci pour ce retour et ce recul parfois nécessaire

Disons que là où le bât blesse c'est quand un decideur/marketeux vous demande si vous savez faire des sites compatibles mobiles, que vous répondez "oui" et qu'il ajoute "ah bon, parce que j'ai testé alsacreations.com sur mon blackberry (ben oui, les pro ont "tous" un BB) et que le résultat est un peu foireux comparé au site de ma société tout en tableaux de mise en page et pas du tout optimisé web mobile".

Et là, ça le fait moins.

@arsene: je ne suis pas d'accord sur la comparaison optimisé IE/iPhone. Apple ne fait que conseiller un mécanisme de css3 : les media queries, ce qui, à terme, devrait profiter à tous les mobiles.

Raphael a écrit :
Disons que là où le bât blesse c'est quand un decideur/marketeux vous demande si vous savez faire des sites compatibles mobiles

On ne peut rien contre ça. Il faut prendre le temps d'expliquer, de recadrer, de réinsérer la question dans des questionnements plus généraux... du coup c'est vrai que ça fait parfois des posts un peu longs

@Patidou : je ne parlais d'Apple mais des sites sites "optimisés pour iPhone" qu'on commence à voir apparaître.

Arsene a écrit :
Il faut prendre le temps d'expliquer, de recadrer, de réinsérer la question dans des questionnements plus généraux...

Clairement. Mais au final le résultat sera le même : si votre site ne passe pas sur *son* mobile, c'est plouf.

Arsène a raison dans le fond, surtout dans une réflexion longue durée d'accessibilité, des respects des normes, etc.

Par contre je suis plutôt d'avis, comme l'expose assez bien Raphaël, de tenter d'éviter le "plouf". A moins de pouvoir se permettre de refuser de bosser sur des projets 100% propre.....




j'en avais déjà parler il y a un certain temps. mais je pense que travailler avec une solution telle que celle-ci se rapproche plus de la réalité, mais si elle ne colle pas du tout avec la philosophie actuelle qu'on est arrivé avec peine à imposer pour le browser "classique ordinateur"

http://www.mobilemultimedia.be/fr/index.php

la détection se fait par Uaproof ou user agent, grâce à une api que nous offre ce site, nous récupérons en retour bon nombre d'infos nécessaires à des applications web mobile.

il est même possible en contacter le webmaster de négocier pourquoi pas une solution spéciale pour vous.

Arsene a écrit :
@Patidou : je ne parlais d'Apple mais des sites sites "optimisés pour iPhone" qu'on commence à voir apparaître.

Ah ok, j'avais mal compris. Puis ces vrai que quand tu regardes le code de ces sites soit disant optimisé c'est divite à tous les étages. Bye bye la sémantique.

Patidou a écrit :
Bye bye la sémantique.

Mais bonjour le marketing.

Pour qui veut devenir riche, et à condition d'être à peu près privé de toute dimension éthique dans son travail (business is business) je conseille de se débrouiller pour être vite dans les premiers googelisables dans la catégorie "sites pour iPhone". C'est un réservoir à phynances quasi inépuisable pour les trois ans à venir.

Quant à la réaction "ça marche pas sur mon BB, DONC ça ne marche pas", elle strictement la même que "mon site web marche chez moi, DONC ça marche partout". Aussi aberrante. Contre l'aberration il n'y a rien à faire. La seule différence est très prosaïque : dans le premier cas tu perds un client potentiel, dans le deuxième tu empoches son pognon. Sinon c'est pareil. Ça appelle le même genre d'attitude et de réaction qu'en tant que professionnels on doit à son client. Vaste débat.

J'aurais tendance à être moins catégorique.
A partir du moment où ça fonctionne "proprement" à l'aide de handheld et media queries et que pour un ou deux cas particuliers (genre BB) on se serve d'un User Agent (un peu comme les commentaires conditionnels pour corriger IE), ça me semble être un bon compromis.

Tu n'irais pas jusque là Arsène ?

La question est plus compliquée : tu n'arriveras JAMAIS à déterminer (contrairement aux navigateurs screen) le nombre et l'identifiant des UA à discriminer. Chaque semaine de nouveaux modèles apparaissent sur le marché et courir derrière eux est perdu d'avance. Il faudrait une sorte de bench qui liste tout ça en temps réel...

Dans un vieux post j'avais exposé ma méthode qui me donne de bons résultats. Entre temps elle a un peu évolué. Du coup ça va recouper ton post (à mon avis inutile) sur les tests CSS.

Le principe :

1. on sait que l'enjeu de la discriminination-reconnaissance s'appuie sur quelques facteurs connus : CSS handheld reconnue ou pas, JS présent ou pas, SESSIONS possibles ou pas, MEDIA_QUERIES ou pas.

2. si UA ne réagit ni à CSS ni à JS ni à MQ ni aux sessions il affichera par défaut ce qu'il pourra (souvent screen plus ou moins réadaptée => version écran dégradée)

3. on teste la validité JS
- si JS reconnu on détermine width et viewport et on crée une session
- sinon affichage par défaut

4. on teste la validité MEDIA_QUERIES
- si reconnu idem, on détermine width et viewport et on crée une session
- sinon affichage par défaut

5. on teste la validité CSS :
- si handheld est reconnue il la prend
- si elle n'est pas reconnue => on lui propose moobil.css (ou handheld si on veut)

A ce stade on sait que UA, s'il n'est pas en mode par défaut (no-JS no-CSS) est disponible pour afficher des contenus paramétrés. On lui envoie une page de contenus (une page XML dans mon exemple en ligne). Selon la façon dont il aura réagi aux tests il affichera le contenu différemment :

- si JS, MQ et pas handheld => environnement "moobil" par créa de session
- si JS MQ et handheld => handheld prend en charge l'affichage
- si pas JS mais MQ + handheld => idem
- si ni JS ni MQ ni handheld => screen dégradée

Dans l'ordre des environnements favorables, l'idéal est qu'il reconnaisse JS : handheld n'a plus d'importance. Du coup une gestion particulière des contenus XML est envoyée selon la configuration.

Au final on a un contenu unique (page.xml) et une interface unique (index.php) MAIS selon les UA (écrans d'ordi ou mobile ? JS ou pas ? CSS handhel ou pas ?) on sert au final des contenus complètement distincts.

Exemple en ligne : http://serv.agat.net/a/ (pour les tests les URL courtes c'est plus sympa pour les mobiles-users )

1. ouvrez cette URL dans un navigateur normal : la page présente en haut les détails techniques et dans le cadre le contenu XML traité (http://serv.agat.net/a/page.xml)

2. réduisez la fenêtre à la largeur d'un mobile (300 > 400px) et relaod : si JS actif le point 5 (CONTENU) propose la version pour mobiles => clic

3. Affichage mobile :
- CSS active => moobil.css utilisée
- SESSION => moobil
- contenu XML réorganisé : les <h3> sont devenus des liens à cliquer pour atteindre les sous-contenus (en terme hiérarchique HTML)

4. Testez sur vos mobiles, ça marche pareil. Deletez la session (7 RE-INIT) pour recommencer.

note : si le titre h1 "Ma page web" est blue = CSS screen / "cyan" = CSS handheld / "green" = CSS moobil

On a donc là un système économique qui permet de gérer la "question mobile" sans passer par une analyse de reconnaissance/discrimination autre que celle des capacités techno de l'UA et qui sert des contenus spécifiques selon les résultats obtenus à chaque étape du test. Comme dit, au pire ça sert du screen dégradé, ce qui est l' "état normal" d'un iPhone ou d'un BB.... et au mieux ça sert du contenu profilé. Du coup ensuite c'est Ajax qui prend le relais pour afficher dynamiquement les contenus dans le cadre => si on en est là c'est que JS est actif et donc Ajax utilisable

Dans cet exemple les noms d'images sont restés les mêmes mais en dev réel ils sont modifiés pour aller récupérer une version réduite générée par GD

('tain, encore un post de 1000 kilomètres )

(( PS : en prod je place le lien "Version mobile" en tête de flux (avec les skiplinks) via un gros bouton submit ))
(( PS 2 : et il va de soi que la "mutation" (h3 => a) s'opère où on veut et sur la balise qu'on veut))
Modifié par Arsene (12 Mar 2009 - 12:08)

Arsène... ton dernier post... proposition... tu le revois un peu avec Raphael, vous tombez plus ou moins d'accord et ça fait un superbe article à mettre sur le site..

et en plus t'auras gagné un Kiwiz


c'était ma façon de dire que c'était très intéressant et que cette technique mérite d'être développé et exposé au grand jour .

Dindon a écrit :
c'était ma façon de dire que c'était très intéressant et que cette technique mérite d'être développé et exposé au grand jour .

J'ai l'impression que ça fait des années que j'en parle et d'ailleurs ce lien avait déjà été mis en ligne il y a plus d'un an. Donc rien de nouveau.

Rien de nouveau..( c'est toi qui le dit ) mais je verrais bien ça dans les tutos ou en article, plutot que dans un post qui va se perdre dans le méandre du forum...

Hmmm...
- handheld
- media query
- JS
- Sessions

... tout ça fait vraiment beaucoup de paramètres !

On se croirait à l'époque IE4 - NS4

Pas d'accord. La logique c'est de fonctionner un peu comme avec object : "si tu sais pas faire ça alors fais ça" en allant du plus complexe au plus simple. Ce n'est pas le paradis bien sûr mais je ne vois pas comment faire autrement pour rester le plus large possible sans passer par des détections modèle par modèle. Ni JS ni MQ ni les sessions ne sont limitatifs/rédhibitoires/obstructifs, ça tente juste de paramétrer les affichages au plus près des capacités de la machine : à plus qu'elle sait faire à mieux qu'on ajuste.

Arsene a écrit :
Pas d'accord.

Je ne dis pas que la méthode est mauvaise. Je trouve simplement que devoir prendre en compte au-moins 4 paramètres de test est assez fastidieux.

Je dis juste que le nombre de cas différents à tamiser fait penser à l'époque des guerres des navigateurs où personne ne respectait vraiment de standards.

... Mais ta méthode me semble très bonne (notamment JS).

Raphael a écrit :
le nombre de cas différents à tamiser fait penser à l'époque des guerres des navigateurs où personne ne respectait vraiment de standards

Ah, pas bien compris alors. On est effectivement exactement dans ce cas de figure, oui. Sauf qu'au lieu d'avoir deux navigateurs à gérer on a 200 mobiles D'où l'idée que la détection modèle par modèle n'est pas maintenable sur la durée.

Bonjour messieurs

je fais une petite incursion dans votre discussion, je suis tombé sur le thread car vous y pointez mon site (http://www.mobilemultimedia.be/fr/)

Vous n'allez peut etre pas me trouver très objectif vu que je propose de la détection mobile mais pour avoir passé ces 10 dernières années dans le milieu des telecoms, je peux vous dire qu'il n'existe aujourd'hui pas beaucoup d'alternatives. Si on veut réellement se lancer dans le mobile et offrir une expérience optimale pour tous les téléphones, il faut savoir ce que les téléphones sont capables d'afficher et ça peut se faire par le biais d'un système de détection comme le mien ou par des technologies plus sophistiquée basée sur des proxys.

Tout n'est pas blanc ou noir naturellement, si vous voulez faire un site qui "fonctionne" sans pour autant offrir une expérience extraordinaire, vous pouvez vous baser sur des familles de navigateurs et visant très large. Cela dépend de vos priorités et des moyens à votre disposition. Les paramètres à prendre en compte en priorité sont la taille d'écran et la capacité du navigateur à lire le xHTML.

Si je devais imaginer le système parfait, je pencherais pour un système qui répertorie les navigateurs et non pas les téléphones. Donc plutot que de classer un Nokia avec un autre Nokia parce qu'il a des caractéristiques similaires, je dirais plutot qu'il faut grouper les différentes générations de navigateurs car elles sont disponibles chez plusieurs constructeurs et groupent un paquet de téléphones. Je pense par exemple à des navigateurs comme NetFront ou Openwave, chaque version a ses spécificités et peut donc etre adressée avec un code particulier. Le gros problème de ce genre de technique, c'est qu'il faut qualifier les navigateurs manuellement avant de pouvoir tirer des conclusions...ça prend du temps et ça coute de l'argent! Bref tant qu'on aura pas une concentration des navigateurs comme sur internet, il n'existera pas de solution facile pour gérer tout ça.