L'application native iOS devrait-elle être distinctement différente de la version mobile du site Web réactif?
J'étais dans une session de formation, où une salle remplie de concepteurs apprenait le prototypage iOS dans Xcode, et il y avait un individu qui venait de Apple pour s'assurer que tout dans le cours était fait correctement, et s'il y avait des questions, elle serait le point de contact (rappelez-vous, elle était développeur). Ensuite, elle a évoqué un point où les applications iOS natives devraient être distinctement différentes du site mobile réactif d'un site Web.
L'idéologie d'Apple est que l'application native iOS devrait être différente de leur expérience Web, mais à partir des données que nous obtenons, les utilisateurs ne font pas de distinction entre mobile et natif et que l'expérience dans les deux devrait être cohérent.
Je pense qu'ils ne devraient pas avoir des expériences différentes, et tirer parti des actifs du Web dans l'application native devrait être la voie à suivre (applications hybrides: Amazon le fait, Twitter le fait, mais Apple doesn ' t).
J'ai téléchargé l'application native d'Apple, et oui, leur expérience est différente. Mais pourquoi? Pourquoi une application native pour mobile doit-elle avoir une sensation différente? Le fait-il? Mais si ce n'est pas le cas, pourquoi Apple fait-il cela? Y a-t-il quelque chose que nous, le public, ignorons? Si nous n'avons pas besoin d'expériences très différentes, alors pourquoi avoir à créer une application iOS doit être une chose (en mettant de côté qu'elle est plus rapide et plus réactive en termes d'interactions et d'animations - disons simplement que la réactivité est égale dans les deux environnements).
Si votre application est la même que votre site Web, pourquoi avoir une application?
En tant qu'utilisateur mobile, cela me rend fou de voir comment chaque site Web essaie de me convaincre de télécharger une application dédiée, qui s'avère souvent n'être que la même fonctionnalité Web reconditionnée. Cela n'ajoute aucun avantage à l'expérience utilisateur .
Je suis sûr que l'entreprise en question pense que c'est un avantage marketing majeur d'avoir une icône dédiée encombrant mon écran d'accueil, mais je trouve cela ennuyeux. Et comme ces applications sont souvent mal faites, elles créent beaucoup de sentiments négatifs envers l'entreprise lorsque j'essaie de les utiliser.
C'est quelque chose que "les données [que vous obtenez]" peuvent ne pas capturer. Si vous demandez simplement aux utilisateurs d'évaluer l'application elle-même, vous ne capturez peut-être pas l'expérience d'être invité à télécharger et à utiliser l'application dans leur environnement téléphonique. Il y a un net inconvénient ici si votre application finit par se sentir comme un site Web, à mon avis (subjectif mais très fort).
Bref, si vous allez faire une application:
- Il devrait avoir une raison d'existence . Il devrait y avoir un besoin pour que le site Web ne réponde pas bien. Et je parle d'une raison que l'utilisateur souhaite , pas d'une raison pour laquelle l'entreprise souhaite qu'il soit sur le téléphone de l'utilisateur.
- Cela devrait bien fonctionner comme une application, s'intégrant dans l'environnement du téléphone. Souvent, cela signifie avoir une apparence native. Je suppose qu'une application qui ne respecte pas les conventions de la plate-forme, mais qui fonctionne bien et accomplit sa tâche, peut fonctionner correctement dans certains cas. Ne pas avoir une apparence native est un risque, car cela peut signifier qu'il est contre-intuitif pour les utilisateurs.
Cette diatribe pourrait être un peu mal dirigée, et je m'excuse si elle ne s'applique pas vraiment à vous. Mais même si cela ne décrit pas directement votre entreprise/client, je pense toujours que c'est une bonne façon de penser au problème.
Le Android pourrait jeter le Apple sur Windows
Lorsque vous fournissez un aspect semblable à Apple sur un site Web, les personnes visitant le site qui utilisent Android, tablettes Samsung, téléphones Windows, tablettes Surface et ordinateurs portables Windows verront la même chose ? Dans l'affirmative, voyez-vous comment l'expérience Apple Apple peut ne pas être familière - ou bien accueillie - par des utilisateurs non Apple?
Si vous excusez cette analogie cassée, c'est comme demander aux gens qui vont au Burger King ou au Kentucky Fried Chicken de s'habiller avec un costume de clown Ronald McDonald avant de pouvoir passer leur commande.
Il devrait certainement y avoir une différence entre l'application native et la page Web mobile. Non seulement le point de dan1111 sonne vrai - pourquoi s'embêter avec une application iOS si vous ne faites que reconditionner la page Web sans la changer beaucoup - mais vous devriez le faire jouez sur les points forts de la plateforme.
Qu'est-ce qui est important sur une page Web mobile?
- Petite empreinte de téléchargement
- Voyez rapidement ce qui est important
- Permettre à l'utilisateur d'effectuer des fonctionnalités susceptibles de le faire sur un téléphone
Vous finissez par jeter beaucoup de choses que vous garderiez sur l'application de bureau, non? Beaucoup de Javascript, probablement. Beaucoup d'images. Médias. Disposition plus simple, fonctionnalités réduites, pour qu'il s'affiche rapidement et amène l'utilisateur où il va le plus rapidement possible.
D'un autre côté, votre application native présente des avantages distincts.
- Il peut être préchargé d'images, de supports, etc., pour donner une réponse de type bureau sur une page mobile.
- Vous pouvez utiliser des scripts sans avoir à vous soucier des gros téléchargements de bibliothèques Javascript et des problèmes similaires qui pourraient entraîner le chargement d'une page Web mobile.
- Vous pouvez utiliser des structures natives, telles que des spinners/dropdowns/etc. qui sont familiers à l'utilisateur
- Vous pouvez utiliser des fonctionnalités intégrées pour fournir une aide contextuelle plus efficace et, dans certains cas, interagir plus facilement avec d'autres applications (par exemple, lancer Twitter ou Facebook)
Donc, si vous décidez d'écrire une application native, vous devez le faire dans le but de tirer parti de ces choses. Si vous affichez simplement du texte, pourquoi s'embêter? Les pages Web mobiles le font très bien. Mais si vous pouvez profiter de l'application native pour fournir de meilleures fonctionnalités pour une réactivité similaire, et qu'il s'agit en fait d'une fonctionnalité utile , alors suivez cette voie.
Longue histoire courte? Parce qu'il n'y a aucun moyen sur terre que votre site Web réactif (ou l'application cordova d'ailleurs) fournisse à l'utilisateur Apple avec une Apple expérience une sorte d'application. Et essentiellement de mon point de vue, c'est de cela qu'il s'agit, pas hybride ou natif, mais "l'expérience Apple".
Si vous connaissez ios, vous pouvez dire simplement en utilisant une application s'il s'agit d'une application hybride ou d'une application xcode pure conçue en suivant les directives Apple Apple.
Comme quelqu'un l'a dit, lorsque vous concevez des applications hybrides ou des sites réactifs, vous fournissez essentiellement aux utilisateurs l'expérience Android, la même Android expérience qui me fait je veux jeter mon téléphone, les contrôles ne sont pas les mêmes, beaucoup de fonctionnalités ne sont pas implémentées (secouer pour défaire etc ...) et ainsi de suite.
Une application native doit être différente du Web réactif, cela dépend du cas d'utilisation.
Parfois, une application Web réactive est idéale pour les nouveaux utilisateurs qui souhaitent essayer le produit, et une application native est idéale pour les utilisateurs fréquents qui sont plus intéressés par le produit.