Convient de mettre les problèmes connus directement dans le logiciel?

J'ai pris en charge la maintenance d'une application Android, et il y a quelques problèmes résiduels que j'ai plus ou moins résolus, mais qui ont toujours des problèmes en raison des différentes versions d'Android OS.

Par exemple, l'envoi d'une demande Web avec la classe MediaPlayer a des en-têtes HTTP personnalisés supprimés par le système d'exploitation avant l'envoi de la demande, mais uniquement sur Android 4.X (j'ai testé de manière exhaustive), ce qui entraîne l'échec de cette fonctionnalité particulière car elle repose sur sur ces en-têtes.

Il s'agit d'un problème connu et j'essaie de le contourner, mais serait-ce une bonne idée d'avoir un contrôle conditionnel comme

if (OS.VERSION == 4) {
    knownIssueDialog(This feature will not work on your Android version... etc.");
}

Évidemment, nous aurions cela noté sur notre canal de support, mais je me demande si ce serait une bonne idée (en supposant que tout est gardé à jour) d'avoir ces problèmes connus également intégrés dans le logiciel, et de les présenter quand et où cela est nécessaire, comme ce que j'ai décrit ci-dessus.

Nous continuons à recevoir plusieurs mauvaises critiques et beaucoup d'e-mails d'assistance basés sur ce type de problèmes, donc dans mon esprit, cela ferait gagner beaucoup de temps et de maux de tête à tout le monde en bloquant simplement une fonctionnalité dont on sait qu'elle ne fonctionne pas correctement.

Je vois deux problèmes potentiels:

1. Les utilisateurs n'ont probablement jamais rien vu de tel qu'une boîte de dialogue "problème connu" auparavant; beaucoup d'utilisateurs pourraient tout simplement ne pas comprendre ce que cela signifie.
2. Il y a un peu de surcharge de développement - il faudrait s'assurer de garder une trace de ces problèmes quelque part dans le code. Heureusement, avec les annotations Java, toute vérification conditionnelle comme celle-ci pourrait être précédée de @KnownIssuequelque chose comme ça, ce qui rend leur recherche / modification très simple.

Est-il judicieux de mettre des invites de «problème connu» dans le logiciel?

Edit : J'ajouterai que c'est un problème qui vient de se produire il y a environ une semaine. J'ai à moitié résolu le problème et il est très peu probable que je puisse le résoudre pour 4.X car c'est le système d'exploitation qui cause le problème. Je pourrais publier une nouvelle version avec le correctif et rendre à nouveau heureux 50% de la base d'utilisateurs, et avertir les autres 50% (utilisateurs 4.X) que le problème persistera sur 4.X, et suggérer une mise à niveau (ou quelque chose ). La question est de savoir si cela doit être fait dans le logiciel (c.-à-d. Afficher une boîte de dialogue pour les utilisateurs 4.X), ou simplement les laisser nous spammer pour soutenir les e-mails disant "votre correctif n'a pas fonctionné !!!" puis dirigez-les vers la page d'assistance qui aborde le problème plus en détail.

Oui, cela est très acceptable pour certaines fonctionnalités plus obscures, surtout lorsqu'elles sont cachées dans le menu d'options. Il est peut-être préférable de désactiver les boutons et d'ajouter du texte supplémentaire "cette fonctionnalité sur XXX et en dessous" ou "cette fonctionnalité fonctionne de manière optimale sur XXX et au-dessus" si elle ne fonctionne que partiellement.

Non, ce n'est pas acceptable sur une fonction clé qui occupe 75% de l'écran lorsque vous démarrez votre application. Vos utilisations seront vraiment ennuyées à chaque fois qu'elles verront le pop-up. Vous feriez mieux de simplement cacher la fonctionnalité, pas besoin de pousser vos utilisateurs sur quelque chose qu'ils ne peuvent pas résoudre.

Ce serait différent si vos utilisateurs pouvaient facilement le réparer, par exemple en installant une application supplémentaire. J'ai souvent vu des messages comme "Pour utiliser cette option, vous devez installer l'application (gratuite) de boussole" ou "Pour utiliser cette option, vous devez mettre à niveau vers l'application pro payante", etc.

En fin de compte, vous pouvez le faire, mais uniquement après un examen attentif et après l'échec d'autres solutions, pas comme un raccourci rapide. Cela ennuiera vos utilisateurs, mais cela pourrait être un compromis acceptable que vous faites.

(ps. J'ai l'impression que cette question devrait aller à UX )

Plusieurs mauvaises critiques + des tonnes d'e-mails d'assistance == clients mécontents. Allez-vous les rendre heureux en «échouant plus gracieusement» pour certaines conditions? Peut être. Cependant, si j'étais vous, je repenserais si j'ai publié le logiciel prématurément et j'aurais dû résoudre certains de ces problèmes avant qu'ils ne soient soumis au client.

Mise à jour: S'il s'agit d'un problème non résolu en raison de l'environnement, je mettrais l'invite pour informer les utilisateurs (ET le faire également documenter et envoyer par e-mail). Cela fonctionne pour un problème isolé comme celui-ci, mais je ne le conseillerais pas comme solution générale pour n'importe quel `` bug connu ''. S'il y en a beaucoup, vous faites quelque chose de mal.

Si les fonctionnalités problématiques sont disponibles via des options, des boutons ou quelque chose de similaire, vous pouvez désactiver ou masquer ces éléments: je m'attends à ce que cela soit moins frustrant pour l'utilisateur que de se voir proposer une fonctionnalité pour se faire dire "ne fonctionne pas". Si vous savez que cela ne fonctionnera pas, ne le faites pas apparaître comme il le pourrait.

• La désactivation de l'option / bouton vous permettra d'ajouter une note indiquant "non pris en charge sur votre système d'exploitation".
• Masquer l'option / le bouton ne déroutera pas les nouveaux utilisateurs, mais pourrait provoquer des plaintes de la part des utilisateurs existants qui ne sont plus en mesure de trouver l'élément.