Lors du développement de nos applications mobiles, elles passent par une phase de développement, une phase d'AQ et sont finalement mises en production. Nous créons des versions distinctes des applications pour chaque environnement, entre autres raisons, car elles accèdent à différents systèmes backend et sont créées pour différents groupes cibles (développeurs, testeurs, utilisateurs finaux)
Nous avons constaté que les différentes versions peuvent se retrouver entre les mains de mauvaises personnes, comme les versions de développement se retrouvent entre les mains de l'équipe AQ. Cela peut prêter à confusion car les différents groupes cibles n'ont que des comptes d'utilisateurs sur les systèmes backend pertinents (dev/qa/prod) et par conséquent, rencontreront des erreurs lors de l'utilisation de builds incorrects. La formalisation et l'automatisation de notre processus de construction devraient atténuer le risque que cela se produise, et nous y arrivons, mais afin de le prouver à toute épreuve, nous voulons distinguer visuellement les différentes versions, de sorte qu'il sera capturé immédiatement si quelque chose glisse à travers les fissures .
Après un peu de recherche sur Google, il semble que des arrière-plans marqués par l'eau soient utilisés sur le Web, mais je me demande s'il y a une meilleure façon pour le mobile car il n'y a peut-être pas beaucoup d'espace `` d'arrière-plan '' dans une application mobile. Je recherche également quelque chose de facile à reproduire dans toutes les applications, car nous utiliserons cette stratégie dans de nombreuses applications visuellement diverses.
Existe-t-il une meilleure stratégie pour distinguer visuellement les versions d'applications mobiles pour différents environnements (dev/qa/prod)?
La raison pour laquelle je pense que cette question est pertinente dans ce forum est que le mauvais choix pourrait distraire et dérouter les clients et les utilisateurs lors des tests d'acceptation, ce qui est fait sur l'environnement QA. Sinon, il serait facile de simplement changer la couleur de la barre de navigation par exemple.
Je vais supposer que vous avez besoin d'un marqueur persistant pour distinguer les versions (sinon vous pouvez le ranger dans un menu, une combinaison de touches cachées, etc.).
Dans ce cas, tout marqueur visuel distraira. Les questions de conception sont:
À quel point voulez-vous qu'il soit intrusif? S'il est essentiel que les utilisateurs sachent qu'ils sont dans une version de test, vous pouvez en fait souhaiter que le marqueur soit intrusif comme rappel persistant.
Quelles informations doit-il transporter? Faut-il simplement distinguer le dev du QA, ou doit-il porter les numéros de version, les dates, etc.
À quel genre de distraction êtes-vous sensible? par exemple pour les tests fonctionnels, vous pouvez être sensible aux marqueurs qui empiètent sur les contrôles ou font bouger le placement des contrôles, pour les tests d'expérience, vous pouvez être plus sensible aux couleurs intrusives qui peuvent fausser la réponse émotionnelle de l'utilisateur.
Voici un ensemble de marqueurs adaptés aux mobiles qui fournissent différents types et degrés d'intrusion et d'informations:
Vous seul pouvez déterminer ce qui convient le mieux à votre application, compte tenu des compromis impliqués.