1479 sujets

Web Mobile et responsive web design

Rediriger les mobiles

Pages :
Bonjour,

Je cherche actuellement un moyen fiable de rediriger automatiquement les utilisateurs mobiles vers une adresse dédiée, de type m.domaine.com.
L'idée est de proposer non seulement une présentation adaptée au périphérique mais aussi et surtout un contenu adapté (on exclut donc l'idée des media queries).

Si la solution du browser sniffing côté serveur est sans conteste la plus efficace en termes de performances, elle implique le listage d'une quantité gigantesque d'UA sans cesse renouvelée.

J'en suis donc venu à me rabattre sur un simple test JavaScript de résolution (couplé aux meta qui vont bien pour l'iPhone) avec redirection "le plus tôt possible" vers l'adresse mobile le cas échéant. Vous pouvez voir un exemple en ligne sur i5.be/W2. La solution n'est pas parfaite puisqu'elle charge tout de même une part (minime) de la version "large" du site mais c'est ce que j'ai trouvé de mieux pour le moment. La désactivation JavaScript éventuelle n'est à mon sens pas problématique puisqu'elle conserve la possibilité de visiter la version "large" du site, même si l'expérience utilisateur en demeure amoindrie.

Qu'en pensez-vous? Avez-vous d'autres moyens de faire cette redirection proprement?
Tu peux effectuer la redirection souhaitée via le mod_rewrite d'Apache, à l'aide d'un .htaccess.
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*iphone [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*nokia [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^autre-agent-utilisateur-mobile
RewriteRule (.*)  http://m.domaine.com/$1  [QSA,L]

Soit dit en passant, pourquoi balkaniser le site en question en y dédiant un sous-domaine pour les navigateurs mobiles ? Smiley rolleyes Les feuilles de styles handheld et autres only screen and (max-device-width: 480px) ne suffiraient-elles pas ? Smiley cligne
Modifié par Victor BRITO (08 Dec 2009 - 22:36)
Victor BRITO a écrit :
Soit dit en passant, pourquoi balkaniser le site en question en y dédiant un sous-domaine pour les navigateurs mobiles ? Smiley rolleyes Les feuilles de styles handheld et autres only screen and (max-device-width: 480px) ne suffiraient-elles pas ? Smiley cligne

J'ai l'impression de ne pas avoir été lu là pour le coup. Smiley sweatdrop
À la rigueur, tu ne réserves la redirection que pour les agents utilisateurs qui ne prennent pas en charge le média handheld ou la syntaxe des media queries de CSS 3. Autrement dit, tu laisses tranquilles Opera Mini, Opera Mobile et Safari pour l'iPhone. Smiley cligne
Modifié par Victor BRITO (08 Dec 2009 - 22:49)
J'ai justement un script à faire pour cela.

Dans mon cas, ça ne peut être QUE du javascript (ce script va être installé sur une tripoté de sites différents auxquels je n'ai pas accès, tout ce que je peux faire c'est leur envoyer le .js)

Quelle est la meilleure solution selon vous ?
Détecter le UA ?
Est-ce que je ne risque pas d'avoir à faire une liste énorme pour savoir quel type de navigateur est autorisé ou pas ?
Victor BRITO a écrit :
À la rigueur, tu ne réserves la redirection que pour les agents utilisateurs qui ne prennent pas en charge le média handheld ou la syntaxe des media queries de CSS 3.

Bon, c'est pas comme si le message disait, en substance, «les media queries ne sont pas suffisantes car je souhaite présenter un contenu adapté», hein?
Slt Benjamin Smiley cligne

Je ne vois pas trop l'intérêt de rediriger vers un m.ndd, avec les probs de double gestion que ça peut poser : maintenir, conformer, etc.
Me semble plus efficace de loader directement des contenus spécifiques ou réorganisés en proposant au moment de la requête initiale toute une batterie de tests pour détecter diverses choses (on en a discuté dans un fil ici il y a quelques mois) et envoyer à l'UA le type de contenus qu'il attend. On a au final un seul contenu qui sera découpé ou proposé différemment selon l'UA requérant.

On dit en gros à l'UA d'appeler la bonne CSS, le bon JS, la bonne page, le bon menu. Quel que soit le cas de figure il n'y a qu'une seule ressource à monter/maintenir (pages, menus...) et qu'une seule URL. L'intérêt d'avoir une seule URL est par ex que tu peux utiliser un QRcode pour l'encoder.Tu peux donc la flasher avec un mobile et l'envoyer à un browser sur ordi.

J'ai tout dernièrement monté ce genre de truc. Un QRcode sur des affiches ouvrait la page des événements du jour sur mobiles (disons monsite.com/aujourdhui). Si j'avais envoyé ensuite de mon mobile vers mon ordi l'URL "m.monsite.com/aujourdhui" il aurait fallu encore une gestion supplémentaire pour lui dire de retourner sur www. Alors qu'avec une seule URL tout se passe en mode auto.

La démarche de considérer qu'il existe un "domaine prioritaire" (www.) et des "domaines secondaires" (m.) n'est pas très productive, d'ailleurs Google, Facebook ou Twitter l'ont abandonnée. Avec les nouvelles technologies disponibles - et ça va aller en s'accroissant - on a besoin de considérer qu'il n'y a qu'un seul web, qu'il est non-balkanisé et qu'il marche partout. Le gros du boulot est désormais en amont : comment organiser les contenus et comment les structurer de façon à les rendre utilisables selon les requêtes opérées. Ces requêtes peuvent venir de couples utilisateurs+UA mais aussi de machines, de puces RFID, d'une API, etc. (internet des objets). Sans parler évidemment des mondes virtuels.

Vaut mieux essayer de penser "usage global" que "solutions spécifiques".Sinon on revient au "optimisé pour NS" d'il y a 10 ans Smiley smile
Perso je comprends Benjamin : en créant un site adapté on peut fournir un site plus léger (html et images) et plus adapté*. Maintenant je suis contre la redirection (déconseillée par Apple également) : je préfère un gros bouton bien visible sur le site normal, le passage au site mobile (ou inversément) serait géré par un cookie.

Attention au duplicate content… Smiley smile

*Le site de Maître Eolas en version normale et mobile.
Arsene a écrit :
Slt Benjamin Smiley cligne

Je ne vois pas trop l'intérêt de rediriger vers un m.ndd, avec les probs de double gestion que ça peut poser : maintenir, conformer, etc.
Me semble plus efficace de loader directement des contenus spécifiques ou réorganisés en proposant au moment de la requête initiale toute une batterie de tests pour détecter diverses choses (on en a discuté dans un fil ici il y a quelques mois) et envoyer à l'UA le type de contenus qu'il attend. On a au final un seul contenu qui sera découpé ou proposé différemment selon l'UA requérant.
(…)


Salut Arsene, désolé mais j'aime pas trop : ça veut dire qu'avec chaque nouvelles UA, il va falloir réécrire les tests de détection alors qu'avec un site séparé et un cookie on évite ces problèmes. Dans le cas du site de maître Eolas, il n'y a même pas de problèmes de maintenance car c'est le même contenu qui est extrait de la base de données, il est juste inséré dans un gabarit adapté.
Patidou a écrit :


Salut Arsene, désolé mais j'aime pas trop : ça veut dire qu'avec chaque nouvelles UA, il va falloir réécrire les tests de détection alors qu'avec un site séparé et un cookie on évite ces problèmes. Dans le cas du site de maître Eolas, il n'y a même pas de problèmes de maintenance car c'est le même contenu qui est extrait de la base de données, il est juste inséré dans un gabarit adapté.


Slt Patidou Smiley cligne
Non j'ai pas dit qu'il fallait détecter l'UA individuellement mais déterminer des "types de comportements" (liés à la taille de viewport, à l'acceptation ou pas de JS, de CSS handheld, etc) et générer les contenus (tirés de la BDD partagée ou de fichiers XML peu importe) en conséquence. Avec le même nom de domaine il n'est pas très compliqué de sélectionner les contenus (tri sélectif selon attentes et capacités) et des les utiliser selon les besoins (affichages par CSS, mais pas que).Tu as donc exactement le même résultat qu'avec www+m. mais sans les désagréments.

Edit :
Patidou a écrit :
il est juste inséré dans un gabarit adapté.

La question justement n'est pas "d'insérer selon les gabarits" mais de ne laisser sortir du serveur que ce dont l'UA a besoin, et organisé selon ses capacités.
Modifié par Arsene (09 Dec 2009 - 13:25)
Arsène: la démarche que tu proposes me paraît tout à fait judicieuse pour couvrir les besoins de la majorité des sites axés "contenu" (magazines, portails, …) mais inadaptée lorsque le contenu "desktop" et "mobile" n'ont presque aucun lien. Exemple: un portfolio mettant en scène de grands screenshots sur la version "desktop" et ne proposant que les informations de contact sur la version mobile.
On peut naturellement débattre du bien-fondé de ce type de décision mais j'aimerais dans ce sujet rester centré sur la question du redirect Smiley smile

Donc, pour en revenir à la question initiale: quelle méthode privilégier, et que pensez-vous de la méthode que je propose?
Salut all,

se sujet m'intéresse beaucoup, j'ai trouver ces codes sur le net

RewriteEngine On
RewriteCond %{REQUEST_URI} !^http://m.monsite.fr/.*$
RewriteCond %{HTTP_ACCEPT} "text/vnd.wap.wml|application/vnd.wap.xhtml+xml" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "acs|alav|alca|amoi|audi|aste|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "dang|doco|eric|hipt|inno|ipaq|java|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-" [NC,OR]
RewriteCond %{HTTP_USER_AGENT}  "maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|opwv" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "palm|pana|pant|pdxg|phil|play|pluc|port|prox|qtek|qwap|sage|sams|sany" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|w3cs|wap-|wapa|wapi" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "wapp|wapr|webc|winw|winw|xda|xda-" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "up.browser|up.link|windowssce|iemobile|mini|mmp" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "symbian|midp|wap|phone|pocket|mobile|pda|psp" [NC]
RewriteCond %{HTTP_USER_AGENT} !macintosh [NC] #*SEE NOTE BELOW
RewriteRule ^(.*)$  http://m.monsite.fr/  [L,R=302]


édit > avec cette méthode cela redirige bien vers l'adresse en question mais il n'affiche pas la page : "cette page contient trop de redirection serveur"

sinon il y a une autres piste sur se fil > http://www.webmaster-hub.com/topic/32014-infos-pour-script-redirection-vers-partie-mobile/ à tester ....
Modifié par Mani (02 Mar 2010 - 13:19)
Pour ma part, il y a deux problématiques mais qui devraient nous obliger à concevoir les sites mobiles de manière spécifique. Si après on peut optimiser le code pour avoir un seul ensemble de pages / scripts, tant mieux.

D'abord, en situation de mobilité, l'utilisation d'un site est fondamentalement différente. On ne cherche pas les mêmes infos en mobilité que devant son bureau. Il faut des infos classées par priorité, pertinentes, utiles et un chargement rapide. Ce qui veut dire une conception de page avec une autre stratégie. Si on convertit du contenu "automatiquement" avec un CSS (handheld display:none), on rate cette étape d'analyse.

Ensuite d'un point de vue technique, si on peut avoir un code générique qui adapte les contenus (images, tags wtai: ou tel:, etc) en fonction de l'UA du navigateur, c'est à mon avis l'idéal. Une recherche google 'service adaptation mobile' devrait trouver plein de solutions à ce sujet.

Une dernière remarque - ce n'est pas parce que des navigateurs modernes type iPhone ou Android peuvent afficher des pages complexes qu'il faut en profiter et avoir des pages de plusieurs centaines de Ko. En fait tous les téléphones partagent le même réseau 3G et des fois 2G (et le serveur web ne sait jamais la qualité de couverture et la bande passante utilisée), la latence sur les réseaux 3G/2G est très importante, etc. D'où l'absolue nécessité de concevoir des pages légères et adaptées.

F.M.
Bonsoir,

Ce débat est très intéressant et j'ai eu à faire le choix la semaine dernière.
J'ai opté pour la redirection vers un sous domaine type m.monsite.com en en interdisant l'indexation par les robots.
Je tenais absolument, à la base, à conserver le même domaine, exactement les mêmes URL qu'on soit sur mobile ou non mais j'ai eu trop peur :
- Que Google se dise que je fais du cloacking : deux contenus différents selon le User Agent
- Que si la version mobile contient un noindex alors que l'autre non (pour éviter de me faire pénaliser pour cause de cloacking)... il désindexe tout les site

Du coup je pars sur un m.monsite.com avec noindex, follow. Solution bancale si jamais un moteur indexais les sites mobiles Smiley ohwell

J'ai presque envie de dire qu'il n'y a pas de solution à l'heure actuelle. Impossible pour moi de tenter la solution domaine unique car si mon site génère la quasi totalité de mon chiffre d'affaire.
Je suis aussi de l'avis d'avoir un sous-domaine du type mobile.domaine.com ou m.domaine.com, pour les raisons citées plus haut.

Par contre il ne faut pas négliger les moteurs de recherche mobile, ils existent déjà. Google en est un example parfait, il sait indexer les sites mobiles en tant que tels.

Par exemple si on est sur son smartphone et qu'on fait une recherche Google, les sites mobiles connus par Google sortiront avec une plus grande priorité. Quand on s'enregistre dans Google Analytics je pense que Google détecte déjà le type de site (mobile ou pas). Il le fait par détection du langage utilisé, donc il faut déclarer du XHTML-MP dans l'entête.

C'est d'ailleurs un des grands avantages des sites mobiles par rapport aux applis, on les trouve par Google (Mobile) Search...

F.M.
Bonjour,

Ayant passé plus de deux heures à décortiquer les résultats de recherche Google Mobile et Standard, impossible, chez moi, de voir la moindre différence dans les résultats.
Es-tu sur de ce que tu dis ?

Sinon, pour avoir tout de même fait l'essai, je vous confirme qu'indexer la version mobile et la version classique n'est pas à faire : -45 % de trafic sur mon site principal dès l'indexation, retour à la normale progressif depuis la désindexation de la version mobile.
Pages :
Sujet clos
Aller à