Comment optimiser votre site web pour l’iPad et la réactivité du mobile pour les tablettes ?
Même les sites les plus propres et les mieux conçus peuvent être victimes de la conception et du développement de sites web réactifs que les tablettes créent. Si l’on considère ensuite le contenu des plugins et une foule d’autres problèmes, on ne sait parfois pas par où commencer. Alors, comment vous assurer que les personnes qui utilisent votre site sur l’une des technologies matérielles à la croissance la plus rapide au monde bénéficient de la meilleure expérience possible sur votre site ? La bonne nouvelle, c’est que votre site n’a pas besoin d’avoir l’air terrible sur un iPad.
Préparer votre contenu Web pour l’iPad
L’iOS 7 est là, l’iPad Air est là, Apple ne cesse de le mettre à jour. Cette année, les tablettes seront plus performantes que les PC et les ordinateurs portables réunis. Alors pourquoi, lorsque nous visitons des sites, ils ressemblent à de la merde sur nos iPads ?
Voici comment obtenir votre contenu web dans Safari sur les appareils iPhone OS, avec des informations spécifiques pour l’iPad – LOOKING AWESOME. Bien sûr, vous pouvez toujours nous appeler.
Safari sur iPad est capable d’offrir une expérience web “de bureau”. L’iPad a un grand écran 9.7″ et une connectivité réseau rapide, et Safari sur iPad utilise le même moteur de mise en page WebKit que Safari sur Mac OS X et Windows. Vous pouvez vous assurer que votre site web a un aspect et un fonctionnement parfaits sur l’iPad, et même créer de nouvelles expériences web tactiles pour vos clients, en tenant compte de quelques différences spécifiques entre l’iPad et d’autres plateformes.
Si vous avez accès à un iPad, testez votre site web à l’aide de l’iPad. Sinon, vous pouvez tester votre site web dans Safari sur iPad en utilisant le simulateur d’iPhone (Matériel -> Appareil -> iPad). L’iPad est disponible dans le simulateur d’iPhone dans iPhone OS 3.2 SDK beta 2 et plus, qui est disponible pour les membres du programme de développement d’iPhone. Dans les cas où il est possible de simuler un comportement similaire à celui de l’iPad dans Safari sur un ordinateur de bureau, les instructions sont données ci-dessous.
Testez votre site web sur l’iPad, et mettez à jour le code de détection de l’agent utilisateur si nécessaire.
De nombreux sites web effectuent des contrôles côté serveur sur la chaîne de l’agent utilisateur du navigateur afin de déterminer s’ils doivent ou non servir la version mobile de leur site web. Safari sur iPad est capable d’offrir une expérience web “de bureau”, et les utilisateurs s’attendront à cette expérience puisque l’iPad dispose d’un grand écran et d’une connectivité réseau rapide.
La liste 1-1 indique la chaîne de l’agent utilisateur Safari sur iPad. Elle identifie la version de Safari qui fonctionne sur l’iPad, et l’iPad est identifié comme un appareil mobile.
Liste 1-1 Chaîne de l’agent utilisateur Safari on iPad dans iPhone OS 3.2 SDK beta 3
Mozilla/5.0 (iPad ; U ; CPU OS 3_2 comme Mac OS X ; en-us) AppleWebKit/531.21.10 (KHTML, comme Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10
Notez que la chaîne de l’agent utilisateur Safari sur iPad contient le mot “Mobile”, mais pas le mot “iPhone”. Si vous diffusez actuellement du contenu mobile à un navigateur qui s’identifie lui-même comme “Mobile”, vous devez modifier vos contrôles de chaîne de l’agent utilisateur pour rechercher l’iPad et éviter de lui envoyer la mauvaise version de votre site. Les numéros de version de cette chaîne sont susceptibles de changer au fil du temps, à mesure que de nouvelles versions de Safari sur iPad sont disponibles. Tout code qui vérifie la chaîne de l’agent utilisateur ne doit donc pas se baser sur les numéros de version.
Simulation des requêtes HTTP de Safari on iPad dans Safari on the desktop.
Si vous ne pouvez pas faire de test avec un simulateur d’iPad ou d’iPhone, vous pouvez simuler une requête HTTP de Safari sur l’iPad dans Safari sur un ordinateur de bureau. Commencez par charger votre site web dans Safari sur Mac OS X ou Windows. Ensuite, cochez la case située à côté de “Afficher le menu Développer dans la barre de menu” dans le volet des préférences avancées de Safari, comme indiqué dans la figure 1-1.
Ensuite, sélectionnez Développer -> Agent utilisateur -> Autre dans le menu Safari. Vous serez invité à saisir une chaîne de caractères pour l’agent utilisateur. Copiez la chaîne d’agent utilisateur Safari sur iPad ci-dessus, puis collez-la dans la boîte de dialogue qui apparaît, comme indiqué à la figure 1-2.
Lorsque vous cliquez sur “OK”, le champ User-Agent de tout en-tête de requête HTTP sera paramétré sur la chaîne que vous venez de saisir, et la page se rechargera automatiquement. Lorsque la page se recharge, vous devez vérifier que vous ne servez PAS la version mobile de votre site web sur l’iPad. Vous pouvez vérifier que la chaîne de l’agent utilisateur de Safari sur iPad a été envoyée à votre serveur en inspectant les en-têtes de requête dans le volet Ressources de l’inspecteur Web de Safari, comme indiqué à la figure 1-3. Ce paramètre de chaîne d’agent utilisateur persiste sur une base par fenêtre.
Utiliser les technologies web standard du W3C au lieu de plug-ins
Les plug-ins ne sont pas pris en charge dans Safari sur iPad, ni dans Safari sur iPhone.
Si vous utilisez un plug-in pour afficher des éléments d’interface utilisateur tels que des menus ou d’autres éléments de navigation sur votre site web, ces éléments ne seront pas accessibles aux utilisateurs de Safari sur iPad ou de Safari sur iPhone. Veillez à inclure un chemin de code pour les plateformes qui ne prennent pas en charge les plug-ins, et pour les utilisateurs de plateformes de bureau telles que Mac OS X ou Windows qui peuvent avoir désactivé les plug-ins.
Si vous utilisez un plug-in pour intégrer de l’audio ou de la vidéo dans une page web, vous pouvez utiliser les balises HTML5 <audio> et <vidéo> pour diffuser du contenu audio et vidéo dans Safari sur iPad et iPhone. Ces balises fonctionnent de manière transparente avec le streaming HTTP en direct, et il est facile de structurer votre HTML pour revenir au contenu du plug-in dans les navigateurs qui ne prennent pas en charge ces éléments. Pour plus d’informations sur l’utilisation des balises HTML5 <audio> et <vidéo>, consultez le Guide Safari du HTML5 audio et vidéo, ainsi que les références des classes HTMLMediaElement, HTMLVideoElement et HTMLAudioElement dans la référence des extensions DOM de Safari.
Si vous utilisez actuellement un plug-in pour dessiner des animations dans vos pages web, vous pouvez utiliser une combinaison de transformations JavaScript et CSS3, de transitions et d’animations pour créer des animations dans Safari sur iPhone OS.
Tester sans plug-ins dans Safari sur le bureau
Si vous ne pouvez pas faire de test avec Safari sur un iPad ou en utilisant le simulateur d’iPhone, vous pouvez vérifier le bon fonctionnement de votre site web sans avoir à installer des plug-ins dans Safari sur le bureau. Commencez par désactiver la case à cocher située à côté de Activer les plug-ins dans le panneau des préférences de sécurité de Safari, comme indiqué dans la figure 4.
Ensuite, visitez votre site web. Les éléments des pages web qui utilisent des plug-ins peuvent être remplacés par des messages vous conseillant de télécharger ou de mettre à jour le plug-in requis. Dans Safari sur iPad, ces zones peuvent être vides.
Vérifiez les paramètres des balises de votre fenêtre de visualisation
Si vous avez spécifié des paramètres de visualisation pour votre page web dans Safari sur iPhone, vérifiez que ces mêmes paramètres conviennent pour Safari sur iPad. Plus précisément, si vous voulez que la largeur de la fenêtre corresponde à celle de l’appareil, vous devez utiliser la constante de largeur de l’appareil au lieu d’une valeur en pixels codés en dur. Par exemple, de nombreux sites web utilisent le paramètre indiqué dans la liste 1-2 pour régler la fenêtre d’affichage sur une largeur qu’ils considèrent comme adaptée à l’iPhone.
Listing 1-2Incorrect : Utilisation d’une valeur en pixels pour la largeur de la fenêtre d’affichage.
meta name=”viewport” content=”width=320″ /> <!— WRONG //—>
L’utilisation de la constante de largeur de l’appareil comme indiqué dans la liste 1-3 est une bien meilleure approche, car elle permet de régler la fenêtre de visualisation sur la largeur de l’appareil actuel.
Liste 1-3Correct : Utilisation d’une constante pour la largeur de la fenêtre d’affichage.
meta name=”viewport” content=”width=device-width”
Modifier le code qui repose sur le positionnement fixe du CSS
Le positionnement fixe CSS fonctionne dans Safari sur iPhone et iPad, mais pas comme on pourrait s’y attendre. Alors que les éléments qui utilisent le positionnement fixe dans Safari sur Mac OS X et Windows restent toujours à l’écran, les éléments qui utilisent le positionnement fixe dans Safari sur iPhone et iPad peuvent se retrouver hors écran lorsque les utilisateurs zooment et font un panoramique de la page web. Pourquoi cela se produit-il ?
Par définition, le bloc contenant un élément de page web qui utilise un positionnement fixe CSS est le viewport. Cela signifie que lorsque vous définissez la position : fixe avec une valeur inférieure et droite de 20px comme indiqué dans la liste 1-4, vous avez “fixé” la position d’un élément à 20 pixels au-dessus du bord inférieur de la fenêtre d’affichage, et à 20 pixels du bord droit de la fenêtre d’affichage.
Liste 1-4CSS positionnement fixe.
#fixed {
position : fixe ;
droite : 20px ;
en bas : 20px ;
hauteur : 100px ;
largeur : 100px ;
couleur de fond : violet ;
}
Dans Safari sur le bureau, la fenêtre de visualisation est analogue à la fenêtre – lorsque vous redimensionnez une fenêtre, vous redimensionnez la fenêtre de visualisation. Lorsque vous faites défiler une fenêtre, vous faites défiler la fenêtre. Ainsi, dans Safari sous Mac OS X et Windows, l’élément reste toujours à l’écran.
Dans Safari sur iPhone et iPad, la taille de la fenêtre est fixée à la taille de l’écran (moins les commandes de l’interface utilisateur de Safari), et ne peut être modifiée par l’utilisateur. Pour se déplacer sur une page web, l’utilisateur modifie le niveau de zoom et la position de la fenêtre en double-cliquant ou en pinçant pour faire un zoom avant ou arrière, ou en touchant et en faisant glisser pour faire un panoramique de la page. Lorsqu’un utilisateur modifie le niveau de zoom et la position de la fenêtre, il le fait dans une zone de contenu visible de taille fixe (c’est-à-dire la fenêtre).
Préparer une interface tactile
Bien qu’un clavier matériel externe soit une option à utiliser avec l’iPad, le principal moyen d’interagir avec le contenu web dans Safari sur iPad est le toucher. Le clavier logiciel apparaît dans Safari sur iPad et iPhone lorsqu’un contrôle de formulaire nécessitant une saisie de texte – comme <input type=”text”> ou <textarea> – est activé. Les utilisateurs ne devraient pas être obligés de se fier à un clavier pour naviguer sur votre page web.
De plus, les utilisateurs de Safari sur iPhone OS interagissent avec votre contenu web directement avec leurs doigts, plutôt qu’avec une souris. Cela crée de nouvelles possibilités pour les interfaces tactiles, mais ne fonctionne pas bien avec les états de survol. Par exemple, un pointeur de souris peut survoler un élément d’une page web et déclencher un événement ; un doigt sur un écran Multi-Touch ne le peut pas. Par conséquent, les éléments qui ne reposent que sur le déplacement de la souris, le survol de la souris, le mouseout ou la pseudo-classe CSS :hover peuvent ne pas toujours se comporter comme prévu sur un appareil à écran tactile comme l’iPad ou l’iPhone.
Vous pouvez manipuler les touches directement ou même détecter des gestes avancés dans Safari sur iPhone OS, en utilisant les événements DOM Touch : touchstart, touchmove, touchend et touchcancel.
Comme le fait de toucher et de maintenir Safari sur iPhone OS invoquera le dialogue Couper/Copier/Coller, vous pouvez également choisir de désactiver la sélection sur les éléments de l’interface utilisateur tels que les menus et les boutons en utilisant -webkit-user-select : aucun. Il est important de ne désactiver la sélection qu’en cas de besoin, en fonction de chaque élément. La sélection dans les pages web ne doit jamais être désactivée globalement.
Utiliser des zones de texte au lieu d’éléments pouvant être contenus
contenteditable n’est pas pris en charge dans Safari sur iPhone OS. Si vous utilisez contenteditable pour permettre la saisie de texte dans un élément de style (par exemple, <p contenteditable> ou <div contentediable>), vous pouvez remplacer cet élément de style par un élément de style <textarea>. Dans Safari sur iPad, iPhone, Mac OS X et Windows, vous pouvez personnaliser l’apparence des éléments <textarea> à l’aide de CSS.
