Conception de sites Web réactifs contre site Web séparé pour mobile
La conception Web réactive est à la mode ces jours-ci. ce qui signifie créer un même site Web et optimisé pour tous les appareils.
Il existe également des sites Web qui convertissent les sites Web de bureau en site Web mobile
j'ai aussi trouvé ces raisons contre
Dans le monde, de nombreux utilisateurs utilisent encore Internet sur la 2G. La 3G n'est pas disponible sur tous les téléphones et dans tous les pays/villes. La vitesse est donc un facteur important pour charger uniquement le code requis, les images sur le mobile de l'utilisateur.
Quels sont les autres avantages d'avoir un site Web mobile distinct?
Tout le contenu, les images et les interactions disponibles sur le site Web Desktop doivent-ils être disponibles lorsque l'utilisateur accède au même site sur Mobile?
Un inconvénient d'un site mobile séparé avec un contenu et des images optimisés est la maintenabilité car nous devrons gérer 2 sites pour Desktop et Mobile.
Je pense que la décision entre un site réactif unique et plusieurs sites ciblant différents appareils se résume à savoir si vous suivez ou non le mantra de LukeW, "conception pour mobile d'abord".
Si vous concevez d'abord pour mobile, il est presque trivial de reconfigurer la disposition/le flux pour s'adapter également à l'utilisation du bureau. Il existe également de nombreux autres avantages ... tels que le mobile vous obligeant à vous concentrer vraiment sur l'expérience utilisateur ... en réduisant l'ensemble des fonctionnalités aux besoins fondamentaux de l'utilisateur. Vous avez tendance à vous retrouver avec un système beaucoup moins gonflé et beaucoup plus simple lorsque vous vous concentrez sur Mobile ... ce qui est également un énorme avantage pour les utilisateurs de bureau.
ALORS, s'il y a toujours un besoin de fonctionnalités "avancées" pour les utilisateurs de bureau, il peut y avoir un ensemble "add-on" de fonctionnalités du site pour eux.
Le plus grand avantage de la méthodologie, à mon humble avis, est toute la future maintenance. Vous avez maintenant UNE base de code. C'est un avantage évident pour l'équipe de développement, et aussi un avantage moins évident pour les utilisateurs finaux (le principal avantage étant qu'il n'y aura pas de partage entre les fonctionnalités en fonction de l'appareil qu'ils utilisent).
Je pense qu'un bon exemple de ce qui est mal fait est Flickr. Ils ont un site mobile qui est assez bon, mais qui n'a peut-être que 75% des fonctionnalités dont on a généralement besoin. Il faut donc toujours cliquer sur la version "bureau". Le problème avec la version de bureau est qu'elle n'est pas optimisée pour les mobiles, il y a donc encore des choses que l'on ne peut pas faire car ils dépendent de HOVER ou FLASH. C'est incroyablement frustrant en tant qu'utilisateur.
Je travaille actuellement sur un projet où nous maintenons la version mobile d'une application de bureau. Malheureusement, nous devons le faire parce que l'application de bureau a été conçue isolément il y a de nombreuses années et a une interface utilisateur si pauvre, qu'elle ne fonctionnera tout simplement pas sur un appareil mobile (pensez à des dizaines d'iFrames ... ugh).
Ainsi, alors que nous construisons une assez bonne version mobile, il est difficile de ne pas grincer des dents au niveau des efforts et de l'argent gaspillés en obligeant les équipes à maintenir deux bases de code distinctes pour le même système.
Je pense que cela dépend vraiment du type de site dont vous parlez: pour les blogs, les sites de petites entreprises et autres petits sites à usage unique, ils sont généralement assez bons.
Pour les sites plus complexes, la réponse ne suffit généralement pas, simplement parce que les utilisateurs mobiles ont des objectifs et des besoins différents lorsqu'ils visitent un site Web.
Voici un peu de Nielen's Mobile Ergonomie Update : "Le deuxième point est plus conceptuel - et plus difficile à accepter pour certaines personnes: lorsque vous avez un écran plus petit, vous devez limiter le nombre de fonctionnalités à celles qui comptent le plus pour le cas d'utilisation mobile. "
Pour les sites qui sont en cours de conception à partir de zéro, suivre la première approche mobile offrira de nombreux avantages et correspond naturellement à l'approche de conception réactive.
Pour les sites qui envisagent désormais de livrer sur mobile, il est peu probable que l'application de techniques "réactives" fonctionne ou soit acceptable pour l'entreprise. Ils ont presque certainement passé des semaines, voire des mois, à négocier les exigences de contenu interservices et le positionnement pour des raisons commerciales et marketing - suggérant maintenant que la disposition des pages changera en fonction de la taille de l'écran ne va pas bien.
De nombreux sites mobiles performants ont été créés pour compléter l'expérience de bureau. Que celles-ci soient livrées en tant que site séparé ou gérées via une certaine forme de détection d'appareil en appliquant une redirection ou en sélectionnant un modèle optimisé pour mobile avant la livraison de la page, c'est là que les vraies décisions ont lieu.
L'application rétrospective de techniques réactives peut être effectuée, mais elle repose sur une structure html extrêmement solide - malheureusement, la plupart des sites au fil du temps perdent leur intégrité initiale.
Les techniques réactives sont la pratique requise pour créer de futurs sites conviviaux - malheureusement, ils ne sont pas la seule partie de la livraison réussie d'expériences mobiles, ce que la plupart des exemples `` regardez mobile est facile '' et les articles de blog ne mentionnent pas réellement.
L'exemple que vous donnez dans mobstac semble être un service qui réutilise un flux rss pour mobile, ce qui est intéressant pour une entreprise d'optimisation mobile, leur site n'est pas réactif!
Le design réactif n'est pas seulement un mot à la mode, c'est la voie à suivre. Une conception réactive signifie servir un site Web adapté à l'appareil/à la résolution. Servir de grandes images sur un appareil mobile (vitesse de téléchargement lente) est tout simplement une mauvaise conception réactive. Votre application doit être suffisamment intelligente pour afficher les tailles d'image appropriées en fonction de la résolution d'écran avec laquelle elle fonctionne.
Construire un site séparé? Voulez-vous vraiment maintenir deux sites distincts qui sont presque identiques? Si la fonctionnalité souhaitée par vos utilisateurs mobiles n'est disponible que dans la version de bureau, vous allez frustrer vos utilisateurs.
La conception réactive est vraiment la seule solution appropriée à long terme. Tout le reste va juste être une "solution miracle" et introduire des incohérences et des bugs que vous devrez maintenir à l'avenir.
Étant donné que je suis d'accord avec les 7 premiers arguments , je répondrais à votre question indirectement, en parlant du processus de sélection d'une conception de sites Web réactifs.
Si vous répondez "oui" aux questions suivantes, je recommanderais de choisir un design réactif.
- La taille de vos pages mobiles et de bureau est similaire
- Vous avez la même architecture pour les deux sites
- Les utilisateurs n'auront pas besoin de passer de la version mobile à la version de bureau lorsqu'ils sont sur leurs téléphones
- Le CSS extra mobile n'est pas ingérable
- Votre site ne comprend pas un grand nombre d'images.
- Vous n'avez pas besoin d'écrire beaucoup de code JavaScript supplémentaire
Donc, fondamentalement, je fais attention de ne pas avoir beaucoup de contenu caché, de grandes images et d'écrire beaucoup de CSS et JavaScript supplémentaires. Parfois, il est beaucoup plus facile d'aller avec un site séparé.
Les bons candidats pour une conception Web réactive sont les blogs et les petits sites. Il ne sera pas judicieux d'essayer l'approche sur un grand site de commerce électronique.
Quels sont les autres avantages d'avoir un site Web mobile distinct? -> il n'y a pas de pros. La taille de l'écran mobile est si fragmentée de toute façon que même si vous créez un site Web distinct, il devra également être réactif.
Quelques vues de google sur le sujet, avec l'inclinaison sur leur moteur de recherche - plus de référencement possible que l'avantage pour l'utilisateur final:
http://www.seroundtable.com/google-mobile-seo-official-15264.html
Voici une réponse très courte. Les avantages d'une conception réactive l'emportent sur les avantages d'avoir un site Web et mobile séparé. Je vais m'étendre.
Le seul véritable avantage d'avoir un site mobile séparé est que vous pouvez plus facilement optimiser l'expérience utilisateur et les actifs pour les limites d'un environnement mobile. Cependant, étant donné l'état de la technologie mobile, je pense que ces avantages peuvent être réalisés avec une conception réactive.
Les avantages d'une conception réactive incluent les plus évidents: une base de code unique pour travailler avec et la bravade de travailler sur le bord d'attaque. Je pense que l'un des avantages les moins tangibles, mais toujours extrêmement positifs, de la conception réactive est un meilleur code. Vous êtes obligé de penser à votre conception et de créer votre code de manière modulaire et bien organisée. Cela rapporte des dividendes depuis longtemps. De plus, les boîtes à outils pour les conceptions réactives s'améliorent, de sorte que vous pouvez cibler les actifs ou les fonctionnalités presque aussi facilement que si vous aviez deux sites.
Je pense que vous bénéficierez davantage à long terme d'une conception réactive.
P.S. - Consultez également le mot à la mode "Amélioration progressive". Elle s'applique à cette discussion.
Je plaiderais pour le cas d'avoir un site Web mobile distinct, non seulement en termes de conception visuelle et de différences techniques telles que les tailles d'écran et les interfaces tactiles.
Je pense que la chose la plus importante à noter est que le but de l'utilisateur d'utiliser votre site mobile peut être très différent de celui du site de bureau.
Par exemple, supposons que vous gérez un site pour une pizzeria. Les informations les plus importantes qu'un utilisateur mobile souhaiterait sont probablement:
- Votre adresse, coordonnées et horaires d'ouverture
- Le menu
- Peut-être un simple formulaire pour faire une réservation ou une commande
Comparez cela à l'expérience de bureau, où les utilisateurs pourraient être plus désireux d'explorer. Ils pourraient, par exemple, être intéressés par le processus de fabrication de pizza, et peut-être même par où vous vous approvisionnez en ingrédients, et des liens vers ces sites. Ils pourraient même être intéressés par l'histoire de votre restaurant et d'autres informations "intéressantes".
Donc, en bref, mon avis est qu'il est toujours préférable d'avoir un site mobile séparé intégrant des fonctionnalités qui seront utiles pour les utilisateurs en déplacement ou ne nécessitant pas l'expérience de bureau complète.