#webmobile

Website Design 2011-2016

El 21 de Abril los sitios no adaptados para móviles perderán posicionamiento en Google

Hace más de un mes Google anunciaba a través de su Blog Oficial de Webmaster, en el post: Finding more mobile-friendly search results que las webs que no estén preparadas para móviles, el 21 de abril perderán posicionamiento con respecto a otras webs optimizadas.

Por ello, ha empezado a enviar mensajes a los webmasters de webs que no están preparadas para el Día D: el 21 de abril, como en este…

Bonjour à tous, 

Face à la part de plus en plus importante de mobinautes au sein de la clientèle de La Maison des Antilles, nous avons souhaité optimiser votre expérience de navigation sur notre site internet.

Désormais, où que vous soyez, vous aurez la possibilité de faire vos achats et de consulter nos produits. Notre volonté est être au plus proche de vous et de répondre constamment à vos besoins. 

Ainsi, la fonctionnalité responsive design de notre site internet, vous procurera une véritable facilité de prise en main depuis votre smartphone. 

Toutes nos catégories, seront donc directement accessibles en quelques clics. 

Alors à vos téléphones, prêt, c'est parti ! ;)

L'équipe de la Maison des Antilles.

Le concept de "survol" d'élément sur mobiles (périphériques "touch") a toujours été assez incongru.

Pourtant l'événement CSS :hover, que l'on retrouve historiquement sur un grand nombre de menus déroulants par exemple, est plutôt bien  supporté par les périphériques mobiles.

En effet, les "touch devices" reconnaissent :hover lors du tap au doigt sur l'événement, un peu comme s'il s'agissait d'un clic (malgré un délai d'attente de 300ms).

Mais tout ça risque de se compliquer dans les prochains temps...

Il se trouve que certains périphériques ont d'ores et déjà laissé tomber cette mauvaise interprétation de :hover et ne le supportent plus comme on pouvait l'espérer jusque là.

C'est le cas par exemple, les derniers smartphones et tablettes sur Windows 8 : un menu déroulant basé sur CSS :hover ne fonctionnera plus puisqu'il se refermera dès que vous décollerez le doigt.

En clair, vous pouvez ouvrir le menu global, mais ne pourrez pas atteindre les liens qu'il contient.

Alors que faire ?

Détecter le touch (modernizr, zeptoJS), ou au pire employer d'autres événements (JS onclick, CSS :focus, :target, :checked),

Utiliser des événements appropriés tels que Pointer Events,

Employer des alternatives pour les vieux navigateurs tels que HandJS

Guardate il vostro sito web da uno smartphone. Come vi sembra? Se non avete apportato correttivi nella realizzazione è probabile che appaia in miniatura. 

Chi lo visita dovrà ingrandire e scorrere le pagine lateralmente per trovare le informazioni che ricerca. Perfetto su PC, il sito non ha lo stesso aspetto su dispositivo mobile.

Ottimizzare e rendere fruibili i siti web per il mobile significa non rendere illegibili le vostre informazioni online sull'unico dispositivo sempre acceso e a portata di mano dei Clienti.  

Cet article est une version remaniée et mise à jour d'un billet éponyme publié il y a quelques mois.

On sait depuis un bon bout de temps à présent que les écrans de nos smartphones et tablettes sont des mythomanes et nous font croire tout un tas de fourberies à leur propos.

On a commencé par mettre un moment à comprendre qu'un écran mobile ne disposait non pas d'un seul type de largeur (et de hauteur), mais de trois :

largeur "constructeur"

largeur "device-width" (ou screen.width en JS)

largeur de fenêtre (viewport)

Mais les contrevérités ne s'arrêtent pas là, loin de là.

Voici donc la liste officielle des mensonges véhiculés par les constructeurs mobiles et qui embrouillent les esprits des développeurs web aujourd'hui encore.

Toutes les affirmations suivantes sont FAUSSES, au moins en partie :

On détecte un iPhone 4 (ou 5)  en testant si sa largeur en portrait correspond bien à 640 pixels.

On détecte un iPad 3 (ou plus) en testant si sa largeur en portrait correspond bien à 1536 pixels.

La largeur de fenêtre (viewport) sur mobile est de 980px.

La valeur de device-width correspond à la taille d'écran d'un mobile.

La valeur de device-width est fixée une fois pour toute pour chaque périphérique.

La valeur de device-width change selon l'orientation du mobile.

Il faut utiliser une meta viewport de valeur "width=device-width".

Il faut utiliser une meta viewport.

Un iPhone 4 (ou 5) est doté d'un écran "HD".

On gère les écrans HD en produisant des images de taille doublée.

EDIT : Les explications de ces affirmations se trouvent à présent détaillées dans une conférence que j'ai présentée lors de Web-5 à Béziers en juin 2013 : "10 Révélations sur le Web mobile".

Je vous invite à consulter les slides de cette conférence librement disponibles sur Slideshare à l'adresse www.kiwi.gg/web5

  Quelques ressources très intéressantes pour étayer le sujet, à lire très consciencieusement :

Alsacréations : comprendre le Viewport dans le Web mobile

Goetter : Viewport, adieu width=device-width ?

Apple : configuring the Viewport

Wikipedia : Display resolution

Résumé de l'article, pour les pressés : CSS offre des moyens de déployer des menus de navigation sur mobile sans nécessiter de requêtes et traitements JavaScript. Mais en contrepartie, les inconvénients sont souvent nombreux (bidouilles, compatibilité). au final, JavaScript a encore de beaux jours devant lui. Une page regroupant ces différentes techniques est visible à l'adresse http://goetter.fr/nav/

Pascal Cauhepe a eu la bonne idée de me proposer une discussion au sujet des menus de navigation en pur CSS sur Branch.com. J'ai pensé qu'il serait utile d'en partager publiquement mes élucubrations, afin d'obtenir des avis, suggestions et idées extérieures.

On va commencer par les généralités, et un premier "inconvénient" inhérent au choix de CSS par rapport à JavaScript : un menu déroulant implique une notion de comportement. Or le langage destiné à gérer le comportement est JS et non CSS.

Second inconvénient commun à toutes les navigations CSS : la compatibilité. Quelle que soit la solution choisie, elle sera moins compatible qu'un équivalent en JavaScript… dès lors que le navigateur mobile a activé JS.

Je vais à présent passer rapidement en revue les différentes solutions CSS à disposition pour cibler un événement (j'en oublie peut-être) et susceptibles d'être employées pour une navigation:

:hover 

:focus 

:checked 

:valid 

:target 

:hover

Avantages :

compatibilité maximale

simple à mettre en place, pas de bidouilles ni de code HTML inutile, à part un onclick="" pour certains navigateurs (Firefox mobile, Opera mini)

pas de requête et traitement JS nécessaire

Inconvénients :

ne correspond pas au même événement sur desktop (survol) et sur mobile (touch)

on ne peut pas refermer simplement le menu

pas de navigation possible au clavier

ciblage limité en CSS (on ne peut avoir d'action que sur un frère ou un enfant)

Un exemple de menu avec CSS :hover

:focus

Avantages :

compatibilité relativement importante

simple à mettre en place, quelques bidouilles HTML (onclick="" pour certains navigateurs, et tabindex="0" pour prendre le focus)

correspond au même événement sur desktop (clic) et sur mobile (touch / clic)

pas de requête et traitement JS nécessaire

Inconvénients :

pas reconnu par anciens smartphones (ex. Android 2.1 et 2.3)

on ne peut pas refermer simplement le menu sur mobile

pas de navigation possible au clavier

ne permet pas plusieurs sous-niveaux de menu

ciblage limité en CSS (on ne peut avoir d'action que sur un frère ou un enfant)

Un exemple de menu avec :focus

:checked

Avantages :

compatibilité assez importante

correspond au même événement sur desktop (clic) et sur mobile (touch / clic)

on peut refermer simplement le menu sur mobile en recliquant sur le bouton

permet plusieurs sous-niveaux de menu

pas de requête et traitement JS nécessaire

Inconvénients :

pas reconnu par certains navigateurs (ex. Opera mobile, Opera mini, Firefox mobile)

quelques bidouilles HTML nécessaires (label et input checkbox masqués pour faire fonctionner l'événement + onclick="" pour certains navigateurs)

ciblage limité en CSS (on ne peut avoir d'action que sur un frère ou un enfant)

Un exemple de menu avec :checked

:valid

Avantages :

compatibilité assez importante (un peu meilleure que :checked)

correspond au même événement sur desktop (clic) et sur mobile (touch / clic)

on peut refermer simplement le menu sur mobile en recliquant sur le bouton

permet plusieurs sous-niveaux de menu

pas de requête et traitement JS nécessaire

Inconvénients :

quelques bidouilles HTML nécessaires (label et input checkbox required pour faire fonctionner l'événement + onclick="" pour certains navigateurs)

ciblage limité en CSS (on ne peut avoir d'action que sur un frère ou un enfant)

 Un exemple de menu avec :valid

:target

Avantages :

compatibilité assez importante

correspond au même événement sur desktop (clic) et sur mobile (touch / clic)

permet plusieurs sous-niveaux de menu

pas de bidouilles HTML nécessaires (à part un onclick="" pour certains navigateurs)

ciblage intéressant en CSS (on peut cibler n'importe quelle ancre dans la page)

pas de requête et traitement JS nécessaire

Inconvénients :

nécessite une ancre dans la page et peut générer des "sauts en haut de page"

casse l'historique de navigation (5 clics sur le menu = 5 retours en arrière nécessaires dans l'historique)

on ne peut pas refermer simplement le menu sur mobile (sauf en bidouillant à l'aide d'un 2è bouton caché)

Un exemple de menu avec :target

Et pour finir : JavaScript :)

Avantages :

compatibilité maximale (si JS est activé)

correspond au même événement sur desktop (clic) et sur mobile (touch / clic)

on peut refermer simplement le menu sur mobile en recliquant sur le bouton

on peut facilement cibler n'importe quel élément de la page

permet plusieurs sous-niveaux de menu

Inconvénients :

requête et traitement JS nécessaire

nécessite souvent d'implémenter des fonctionnalités / détections complémentaires qui complexifient le code initial (onresize, timeout, zoom utilisateur, etc.)