Les utilisateurs comprendraient-ils le fractionnement d'une fonctionnalité de l'application Android par autorisation?
Supposons que je développe une application pour Android qui prennent en charge une utilisation hors ligne, comme un client de messagerie ou Usenet. Pour autant que je sache, la plupart des tablettes sont uniquement Wi-Fi, et le l'utilisateur est susceptible d'être absent du Wi-Fi pendant plusieurs minutes à plusieurs heures à la fois. Par exemple, un utilisateur peut être un passager dans les transports en commun et ne pas transporter un smartphone avec un plan de connexion. Comment puis-je satisfaire les deux non les utilisateurs techniques qui veulent des fonctionnalités et les utilisateurs techniques qui sont sensibles à ce que les applications peuvent faire pour empiéter sur leur vie privée?
Si le lecteur a été gâché par des connexions Internet toujours actives au cours de la dernière décennie, voici un rappel du fonctionnement de la fonctionnalité hors ligne: un utilisateur hors ligne peut lire des messages qui ont déjà été téléchargés et composer de nouveaux messages qui vont dans une boîte d'envoi. Lorsqu'une connexion Internet devient disponible, l'utilisateur s'attend à ce que l'application se "synchronise": se réveille, envoie tous les messages dans la boîte d'envoi et télécharge les nouveaux messages qui sont devenus disponibles. Ensuite, l'utilisateur peut à nouveau se déconnecter et travailler avec ces messages.
Certains utilisateurs souhaitent une synchronisation opportuniste chaque fois que l'appareil découvre qu'une connexion est devenue disponible. Mais d'autres utilisateurs pourraient penser que le ACCESS_NETWORK_STATE permission ou surtout le READ_CONTACTS l'autorisation est trop intrusive dans la vie privée de l'utilisateur et refuserait de télécharger une application qui demande cette autorisation.
"Besoin de mon carnet d'adresses? [Expletive] éteint."
-- épine
Et on me dit les autorisations ne peuvent pas être rendues facultatives dans Android avant Marshmallow; uniquement la configuration matérielle requise peut être rendue facultative . Et sur Android, l'état du réseau n'est pas considéré comme une fonctionnalité matérielle facultative.
Un réponse à "Est-il possible d'avoir des autorisations" facultatives "dans Android?" recommande de diviser la fonctionnalité d'une application en plusieurs applications répertoriées sur Google Play Store:
- "FooMail" est l'application principale, avec seulement
INTERNETpermission. Si seule cette application est installée, l'application fonctionnerait toujours avec ses propres contacts et laisserait l'utilisateur demander une synchronisation au sein de l'application. Toutes les fonctionnalités sont utilisables, à l'exception de remplir "À" avec des contacts extérieurs et la synchronisation automatique. - "FooMail: Contacts" utilise
READ_CONTACTSpour interroger les contacts à l'échelle du système afin de remplir le champ "À:" dans le courrier. - "FooMail: Background Sync" crée un service d'arrière-plan qui utilise le
ACCESS_NETWORK_STATEautorisation de découvrir lorsque la connexion Internet est devenue disponible et de demander une synchronisation si les données d'arrière-plan sont activées à l'échelle du système. - "FooMail: Sync on Device Start" crée un service d'arrière-plan qui utilise le
RECEIVE_BOOT_COMPLETEDautorisation de découvrir quand l'appareil a fini de démarrer et de demander une synchronisation si les données d'arrière-plan sont activées à l'échelle du système. De cette façon, même si la batterie de l'appareil se décharge complètement ou qu'une mise à jour du système OTA a été installée, l'utilisateur est informé que de nouveaux messages sont disponibles pour une lecture hors ligne une fois que l'appareil est rallumé. Il peut être prudent de combiner ce plug-in avec Background Sync.
Une fois les applications installées, toute l'interface utilisateur serait dans "FooMail" et les applications "plug-in" agiraient comme des services qui communiquent avec "FooMail". Les utilisateurs sensibles à la confidentialité n'installeraient que "FooMail" et se synchroniseraient manuellement en ouvrant l'application et en déroulant la liste des messages. Les utilisateurs qui souhaitent des fonctionnalités supplémentaires installeraient l'application principale et tous les plug-ins, et le paramètre permettant d'activer une fonctionnalité présente dans un plug-in dirigerait l'utilisateur vers la page du plug-in sur Google Play Store. Les utilisateurs comprendraient-ils facilement la fonctionnalité d'une application divisée en plusieurs entrées sur Google Play Store? Si ce n'est pas facile, quelle est la meilleure façon d'accommoder à la fois les utilisateurs non techniques et les utilisateurs sensibles à la confidentialité?
Installer 4 applications pour faire 1 chose est mauvais UX
App Overload est une chose réelle et les gens hésitent davantage à mettre des choses sur leur téléphone en général. Si vous avez besoin de plusieurs téléchargements d'applications avant que l'utilisateur ne puisse terminer sa tâche, de nombreuses personnes ne s'en soucieront pas ou pire encore pourront télécharger l'application principale uniquement pour découvrir qu'elle ne fonctionne pas sans 3 autres applications, à quel point elles laissent une mauvaise vérifier et supprimer l'application principale.
Je comprends tous les détails techniques de votre question et les raisons qui les sous-tendent, mais pour l'utilisateur final, rien de tout cela n'a d'importance. La seule chose qui compte pour un utilisateur de smartphone est how much better will my life be if I put this app on my device?
Google et Facebook sont tous deux passés à ce modèle
Google docs est divisé en plusieurs applications et Facebook a une application pour afficher votre flux et une autre application pour la messagerie qui était disponible pendant environ un an avec très peu de téléchargements avant d'insister pour que tous les utilisateurs qui voulaient envoyer un message à leurs amis Facebook soient tenus de télécharger le application messenger et tout l'enfer s'est déchaîné .
La division des applications en plusieurs parties est idéale pour les entreprises avec plusieurs équipes qui y travaillent, mais n'est généralement pas très bien reçue par l'utilisateur final.
Les utilisateurs super techniques peuvent comprendre
La doublure argentée est que, selon votre public cible, certaines personnes pourraient comprendre la décision et voir ce que vous faites comme une option plus sûre. La plupart des gens ne comprendront pas pourquoi l'application est divisée en plusieurs parties et y voient un avantage là où ils ont le contrôle, mais il pourrait y en avoir quelques-uns qui ne peuvent trouver que le contrôle qu'ils recherchent dans votre application partitionnée.
Si vous envisagez plusieurs applications pour les autorisations, optimisez la structure pour des préoccupations réalistes de l'utilisateur.
Tout utilisateur raisonnable * qui autorise l'accès "INTERNET" à une application autorisera également "ACCESS_NETWORK_STATE".
Ainsi, s'ils souhaitaient installer l'application de base "FooMail", ils trouveraient une option d'ajouter "FooMail: Background Sync" assez particulière.
Ensuite, à première vue, "FooMail: Sync sur le démarrage de l'appareil" semble inutile, car les téléphones ne sont presque jamais redémarrés *, donc la synchronisation ne mettra à jour les e-mails qu'une seule fois dans une lune bleue?
Désormais, une préoccupation légitime et largement compréhensible est l'accès aux "Contacts". Une large section transversale de Android peut apprécier la possibilité d'affiner le contrôle ici.
Notez que maintenant avec seulement deux options restantes, nous pouvons maintenant empaqueter pour une installation en une seule étape
- FooMail
- FooMail Pro (avec synchronisation des contacts)
(* oui, il y aura toujours 1 utilisateur sur 10 000 dans un cas spécial déraisonnable. En bref, ne concevez PAS pour eux.
Une note de bas de page essentielle est que le niveau de détail exprimé dans la question peut être normal pour les utilisateurs techniques, mais est anormal pour la population générale - le livre Les détenus dirigent l'asile: pourquoi les produits de haute technologie nous rendent fous et comment pour restaurer la santé mentale communique bien.)
Les utilisateurs peuvent ne pas comprendre la distinction entre le noyau et l'utilitaire, mais ils ont probablement de l'expérience avec la distinction entre la version Lite et la version Pro. Donc:
- Créez une application distincte, FooMail Background Sync
- Annoncez que la synchronisation en arrière-plan coûte normalement 4,99 $, mais pour le moment, les utilisateurs de FooMail peuvent la télécharger pour seulement 0,99 $
- Les utilisateurs qui n'auraient pas été satisfaits de télécharger gratuitement la synchronisation d'arrière-plan seront désormais ravis de payer pour le télécharger.
Je ne sais pas si cela fonctionnerait vraiment, mais ce serait intéressant à tester.
Approche de la famille d'application
Du point de vue des utilisateurs, ne application doit pouvoir se suffire à elle-même et offrir un service à l'utilisateur. Lorsque nous pensons aux applications existantes qui font cela, comme le messager de Facebook et Google Docs, chacune offre quelque chose de indépendant à l'utilisateur final.
Android M offre le modèle d'autorisations basé sur les exigences. Je ne suis pas pleinement conscient de cela, mais je suppose que les développeurs auraient une compréhension de l'autorisation accordée par l'utilisateur et que ce module peut prendre vie et fonctionner.
Outre Facebook et Google, il existe d'autres sociétés relativement petites qui font de même. Comme Any.do qui propose des outils de productivité comme le gestionnaire de tâches et le calendrier, et ces deux outils ont quelque chose à offrir individuellement à l'utilisateur final en tant qu'application autonome. Selon moi, cela devrait être votre premier critère lorsque vous souhaitez diviser votre candidature.
Dans votre exemple, vous souhaiterez peut-être développer le module de contacts en tant que gestionnaire de contacts entièrement différent, qui peut en principe être distinct du système de messagerie. Ensuite, il est logique d'avoir deux applications offrant des fonctionnalités différentes pour l'utilisateur final.
Approche plug-in
Il existe certaines applications comme le navigateur Dolphin, les thèmes SwiftKey qui fonctionnent sur le modèle de plug-in. Les applications secondaires ou les plug-ins de ces combinaisons doivent obligatoirement avoir installé l'application principale. Cette approche est toujours basée sur les services qu'elle offre à l'utilisateur. Il fonctionne principalement comme une extension des services de base. Cette distinction se produit du point de vue fonctionnel et non des limitations techniques/faisabilité.
Rappelez-vous toujours, pour un utilisateur, qu'il est important que votre application résolve clairement les problèmes commerciaux auxquels il est confronté. Votre division et votre modularisation ne devraient dépendre que de la valeur ajoutée et de l'interdépendance de ces éléments du point de vue de l'utilisateur.
Les utilisateurs d'Automate comprennent les plug-ins.
Automate by LlamaLab possède un système de plug-in. L'application principale nécessite très peu d'autorisations. L'activation d'une fonctionnalité nécessitant l'emplacement de l'appareil, par exemple, amène l'utilisateur à la page du plug-in de localisation automatique sur Google Play Store. Cette application nécessite des autorisations de localisation et, une fois installée, l'application principale Automate accède aux emplacements via un service fourni par le plug-in. la page des développeurs de LlamaLab sur Google Play Store répertorie l'application principale et les dix plug-ins, mais l'utilisateur n'aurait généralement pas besoin de visiter la page des développeurs, car Automate amène l'utilisateur directement au plug-in correspondant.