S'il y a une erreur connue dans une fonctionnalité, devons-nous avertir nos utilisateurs ou simplement désactiver la fonctionnalité?
Dans cet exemple, Facebook Connect (techniquement Facebook Login) a un bogue ouvert qui empêche les utilisateurs IE8 de se connecter. Il envoie des messages d'erreur, et il n'est pas clair pour les utilisateurs que l'erreur est sur Facebook. C'est un bug assez cohérent, donc nos utilisateurs IE8 ne pourront jamais se connecter jusqu'à ce que Facebook corrige le bug.
Devrions nous…
- Émettre un avertissement ou une alerte après avoir cliqué sur le bouton, mais avant que Facebook ne donne une erreur?
- Mettre un avertissement autour du bouton de connexion FB disant que cela ne fonctionnera pas?
- Supprimer complètement l'option de connexion FB jusqu'à ce que le bug soit corrigé?
- Supprimer le bouton de connexion FB et faire savoir aux gens que c'est à cause d'un bug du côté FB?
- Utilisez votre idée encore meilleure? Qu'Est-ce que c'est?
Je suis d'accord avec TamDenholm en ce que vous ne devez pas afficher l'option de connexion pour les utilisateurs IE8.
Cependant, je pense qu'il y a des utilisateurs qui font se soucient. Par exemple:
- J'ai peut-être créé un compte à l'aide de FB connect dans un autre navigateur
- J'utilise peut-être un autre ordinateur (la plupart des environnements d'entreprise utilisent/forcent IE)
Ce sont probablement encore des cas Edge, mais je fournirais un lien du type "Pourquoi ne puis-je pas me connecter en utilisant Facebook?". Tout utilisateur qui choisit ce lien peut être informé du problème et proposé une solution de contournement ("utiliser un navigateur pris en charge").
Vous ne devez pas du tout afficher la connexion Facebook pour les utilisateurs IE8 et ne pas expliquer pourquoi non plus, l'utilisateur s'en fiche. Les personnes cherchant spécifiquement à se connecter avec Facebook qui utilisent IE8 et n'opteront PAS pour la solution alternative que vous leur avez proposée sont un très petit nombre de personnes.
En supposant que vous ayez un moyen approprié pour les clients de vous contacter sans vous connecter ou vous inscrire, s'ils se soucient beaucoup, ils vous enverront un courriel pour vous poser des questions sur la connexion à Facebook, mais je serais surpris si vous receviez une seule demande.
Lorsque le bogue est corrigé, vous pouvez ajouter la connexion Facebook, si vous voulez vraiment le promouvoir, envoyez un e-mail aux comptes qui utilisent IE8, en leur disant qu'il est désormais disponible, en supposant que vous vous connectez ce genre de chose.
La démographie des utilisateurs qui vous préoccupe est absolument minuscule, ceux qui utilisent IE8 et nécessitent une connexion Facebook et n'utiliseront PAS la solution alternative. Ceux qui préféreraient peut-être utiliser ces deux technologies iront probablement avec l'alternative que vous leur fournissez.
Autres choses à examiner, vous êtes-vous assuré que le bogue est à 100% la faute de Facebook? De plus, quelqu'un de la communauté des développeurs a-t-il trouvé une solution?
Je pense que la transparence et une bonne communication font partie d'une bonne relation client. Donc, si une fonctionnalité est défectueuse, vous devez la mentionner dans un article de blog ou un Tweet pour faire savoir aux utilisateurs qu'elle est en cours de résolution.
Si vous le pouvez, désactivez la fonctionnalité de la manière la plus rapide afin de pouvoir résoudre le problème réel (mais ne laissez pas les utilisateurs perdre leur temps à essayer d'utiliser une fonctionnalité défectueuse entre-temps). Selon l'importance de la fonctionnalité, il peut être utile de pointer les utilisateurs vers une alternative (soit dans l'interface utilisateur, soit si l'explication est trop longue, il suffit de les pointer vers la page de blog/support qui l'explique).
Naturellement, tout cela ne s'applique que s'il ne faut pas plus de temps pour expliquer/rediriger/désactiver que pour résoudre réellement le problème.
Et, bien qu'il ne s'applique pas dans ce cas particulier, un bon SCM peut également être d'une grande aide. Idéalement, si votre code est suffisamment modulaire, vous pouvez simplement restaurer cette partie de l'application à la dernière révision de travail et ne pas avoir à traiter tout cela sur le site de production. Et à titre préventif, la prochaine fois que vous déployez des modifications, vous effectuez des tests de régression approfondis avant de pousser les modifications sur le site de production.