2009-03-08 7 views
9

Comment puis-je commencer le développement d'un site qui peut être parcouru à partir de téléphones mobiles? Par exemple, si vous naviguez sur le site Gmail à partir d'un iPhone, le site est différent du site normal. Vous devez concevoir deux sites différents pour le faire? Comment puis-je savoir si le site est accessible par un navigateur mobile?Comment puis-je concevoir un site pour les téléphones mobiles

Répondre

21

Vous n'avez pas besoin de concevoir deux sites différents, mais vous le souhaitez probablement s'il est important de laisser les utilisateurs mobiles accéder à votre site.

Il existe plusieurs façons de résoudre ce problème, chacune avec ses avantages et ses inconvénients. Je suppose que votre site a ses informations dans une base de données, et publie ces données en utilisant un ensemble de modèles? (Comme un site Ruby on Rails ou Django, un site PHP, un blog, etc.) Si vous avez codé manuellement un tas de pages HTML statiques, cela demandera beaucoup plus de travail.

1: Même HTML, différentes feuilles de style pour l'écran et MOBILE

L'idée: Vous livrez la même structure HTML à toutes les demandes. Vous créez une feuille de style pour SCREEN et une pour MOBILE.

Bon: Pour vous, le programmeur. Il est plus facile pour vous de conserver 2 feuilles de style que de conserver 2 sites de modèles totalement distincts.

Mauvais: Pour vos utilisateurs. Un site facile à utiliser sur un appareil mobile est généralement inefficace pour un navigateur normal. et les sites optimisés pour un ordinateur de bureau/ordinateur portable échouent souvent misérablement sur un appareil mobile. Évidemment, cela dépend de la façon dont vous codez vos pages, mais dans la plupart des cas, pousser votre site normal vers un navigateur mobile sera mauvais pour vos utilisateurs. (Voir http://www.useit.com/alertbox/mobile-usability.html pour un résumé de la recherche de la facilité d'utilisation récente de Jakob Nielsen sur les sites mobiles.)

2: Maintenir des sites distincts

(Gmail maintient encore plus de 2 systèmes Ils ont essentiellement différentes applications de conteneurs/modèles qui traiter les mêmes données: la version complète du navigateur AJAX, la version du navigateur HTML simplifiée, une version mobile de base, une application native Blackberry et une application iPhone native.)

Ceci est la norme émergente pour les sites qui se soucient vraiment d'avoir à la fois une présence mobile et de bureau. C'est plus de travail pour vous, mais en général c'est beaucoup mieux pour vos utilisateurs. En revanche, vous pouvez probablement créer un site HTML pur qui fonctionne pour mobile et qui sert de solution de repli pour l'utilisateur web rare qui n'a pas javascript, ou qui a des problèmes majeurs d'accessibilité qui les empêchent de en utilisant le site "complet". En outre, en fonction de votre base d'utilisateurs: aux États-Unis, les gens ont généralement accès à un ordinateur de bureau ou un ordinateur portable et utilisent leurs appareils mobiles pour accéder aux services auxiliaires. Par exemple, je réserve mes billets d'avion et ma voiture de location en utilisant mon ordinateur de bureau, mais je veux consulter mon code de réservation sur mon mobile. Dans de nombreux cas, vous pouvez limiter les fonctionnalités que vous proposez sur le site mobile et exiger que l'ordinateur complet effectue des cas d'utilisation inhabituels.

La procédure de base:

  1. Conception & construction UIs pour mobile et écran. Lancez les sites à deux adresses URL différentes; la convention émergente est www.yoursite.com pour la version de bureau, et m.yoursite.com pour la version mobile. (Cela permet aux utilisateurs de naviguer directement sur m.yoursite.com s'ils connaissent la convention.
  2. Sur www.yoursite.com, consultez l'agent utilisateur et testez-le pour voir si le navigateur de l'utilisateur est mobile. Si c'est le cas, dirigez l'utilisateur vers m.yoursite.com.
    1. Il y a des sniffers écrits dans différents langages de serveur (PHP, Perl, peu importe) que vous pouvez probablement utiliser. Vérifiez les licences. Here's an example of a sniffer written in php. De Wikipedia's article on user agent sniffing: «Les sites Web spécifiquement destinés aux téléphones mobiles, comme I-Mode de NTT DoCoMo ou les portails Vodafone Live de Vodafone, reposent souvent lourdement sur le sniffing des agents utilisateurs, car les navigateurs mobiles diffèrent souvent beaucoup les uns des autres. ont été fabriqués ces dernières années, alors que de nombreux téléphones plus anciens qui ne possèdent pas ces nouvelles technologies sont encore très utilisés, ce qui fait que les portails web mobiles génèrent souvent un code de balisage complètement différent en fonction du téléphone mobile utilisé pour les parcourir. petit (par exemple, redimensionnement de certaines images pour s'adapter à des écrans plus petits), ou assez étendu (par exemple, le rendu de la page en WML au lieu de XHTML). "
  3. Sur m.yoursite.com, fournissez un lien vers www.yoursite.com. Les utilisateurs qui cliquent sur ce lien NE doivent PAS être redirigés vers le site mobile, et la façon dont vous y parvenez dépend de votre implémentation.

Vous voudrez peut-être suivre Quirksmode pour ses articles émergents sur les tests mobiles.

3: Modèles de sortie différents blocs de données en fonction de l'agent utilisateur, et de maintenir séparés les feuilles de style

Comme (2), cela vous oblige à renifler l'agent utilisateur. Contrairement à (2), vous utilisez toujours la même logique de page et n'avez pas à gérer deux sites distincts. Cela peut convenir si vous ne faites que traiter un blog ou un site Web qui traite principalement de la lecture de données.

Dans votre code de modèle, vous pouvez dire des choses comme

if($useragentType != mobile) { 
    echo('bigBlockOfRelatedArticlesAndAds.php'); 
} 

Cela vous permet de conserver la plupart du temps un ensemble de fichiers de modèle. Vous pouvez également rationaliser les pages que vous envoyez à vos utilisateurs mobiles, afin qu'ils ne reçoivent pas une grosse page gonflée quand ils voulaient juste lire votre billet de blog ou autre.

1

Vous devez concevoir deux sites différents pour ce faire?

Oui

Comment puis-je savoir si le site est accessible par un navigateur mobile?

Votre langage de programmation a probablement un moyen de parcourir les informations du client. PHP, par exemple, a une variable superglobale $_SERVER qui a toutes sortes d'informations à la fois sur le serveur serveur et sur le client visiteur. Dans ce cas, vous seriez intéressé par la valeur de $_SERVER['HTTP_USER_AGENT'], ce qui donnerait le résultat suivant, dois-je visite une page:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16

Cela vous dit que je suis sous Mac OS X 10.5.6, en utilisant Safari 4.0. Il existe des mots clés connus pour divers navigateurs mobiles. Une version du navigateur de l'iPhone, par exemple, a l'agent utilisateur suivant:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

le « iPhone » donne déjà loin, mais il est confirmé par les mots-clés « Mobile » et « Safari »

2

Conserver C'est simple, pensez opera mini et vous l'aurez compris. (iPhone a plus hors d'un navigateur normal ...)

  1. Mettre l'accent sur le contenu

  2. Évitez les plugins

  3. Suivez les standards du Web

  4. Séparer le contenu de la mise en page/conception , utilisez css autant que posible.

  5. Utilisez du texte et des images.

Ajouter le reste des cloches et de sifflets si vous devez, mais assurez-vous que le site: le contenu s est toujours disponible même lorsque les cloches et de sifflets sont éteints. Si vous pouvez naviguer sur la page avec un simple navigateur comme Lynx et navigateur normal comme Firefox, alors vous êtes sur la bonne voie.

Pour plus d'informations ne hésitez pas à visiter le any browser campaign


Edit: Dans le cas où il est évident que vous travaillez avec différents pour différents types css de navigateurs, mais toujours utiliser le même contenu. Visitez le css zen garden pour une belle démo.


Mise à jour: Ajout d'un lien avec les types de médias css, et comme indiqué par d'autres, il est l'option du terminal mobile est intéressant.

1

La plupart des sites ont un sous-domaine un peu différent pour les sites mobiles (la plupart utilisent "m"). par exemple. flickr utilise m.flickr.com

(il y a une recommandation d'utiliser le .mobi TLD mais je ne l'ai jamais vu qui a utilisé)

Faire la conception super simple, ne pas utiliser trop de graphiques, où vous avez besoin de les garder comme aussi petit que possible. This pourrait être utile pour la conception.

Je construirais probablement un ensemble de pages différent pour les utilisateurs mobiles, en utilisant les mêmes objets de gestion, etc. que ceux que vous utilisez pour le site principal.

Si les différences entre la conception des deux sites ne sont pas grandes, vous pourriez être en mesure d'obtenir un moyen de simplement servir des fichiers CSS distincts?

2

Pour vérifier comment un weppage regarde dans un navigateur mobile utiliser Opera Mini Emulator

+0

En mode Opéra, vous pouvez utiliser Affichage> Petit écran. Cela ressemblera beaucoup à Opera Mini, mais il y a probablement des différences subtiles dans les comportements CSS et JavaScript. –

6

La majorité des appareils mobiles ces jours-ci prennent en charge « stylesheets mobile » qui sont simplement à afficher les feuilles de style alternatives les choses plus simples. Vous pouvez ajouter une feuille de style mobile à votre site de façon normale et inclure l'attribut media="handheld":

<link rel="stylesheet" type="text/css" href="/mobile.css" media="handheld" /> 

Ensuite, ces styles s'appliqueront aux mobiles. Le seul problème avec cette méthode est que si votre HTML est volumineux, le chargement de la page peut prendre un certain temps car la plupart des navigateurs mobiles sont plus lents (sauf Opera Mini). C'est pourquoi les plus gros sites comme flickr et digg utilisent des sites distincts.

Notes complémentaires:

  • Bulky HTML ne porte pas atteinte à Opera Mini autant parce qu'il utilise un proxy qui effectue le rendu envoie à l'extérieur alors une « image » particulière au dispositif.
  • Utilisez HTML simple et propre, vous pouvez envoyer la même chose aux navigateurs normaux et les appareils mobiles
  • Vous devrez vérifier sur les combinaisons de feuilles de style avec media attributs. Si l'IIRC ajoute le code ci-dessus, les navigateurs ignoreront la première feuille de style. Si vous ajoutez media="all" au premier, les deux seront utilisés (et vous pouvez donc remplacer les styles d'origine plutôt que de recommencer à zéro).
2

Consultez le projet WURFL. Son but est d'aider les développeurs à cibler plusieurs navigateurs téléphoniques, et a commencé il y a longtemps avant Mobile Safari, à l'époque de HDML, WAP et XHTML-MP. Il est cependant à jour, stockant les capacités des appareils modernes tels que l'iPhone. Il a des données sur plus de 400 périphériques, et a des bibliothèques en Java, PHP, Perl, Ruby, Python, .NET, C++. En fonction de la portée de votre application mobile, vous pouvez l'examiner. Here's une liste de sites qui utilisent WURFL.

Un autre projet connexe écrit par Luca Passani (le co-fondateur et le mainteneur de WURFL) est Switcher. Vous pouvez l'utiliser pour rediriger automatiquement vers la version mobile de votre site.

0

Votre site doit être limité au téléphone mobile qui peut prendre en charge le maximum d'exigences. vous ne pouvez même pas divertir tous les mobile phone.

Votre site Web doit avoir un ensemble différent de style CSS, et HTTP AGENT doit vérifier le type de client en fonction de la demande. La sélection Css doit avoir lieu.

Questions connexes