Comment informer un utilisateur des problèmes de compatibilité (possibles)?
Situation:
Nous avons récemment mis à jour l'une de nos fonctionnalités logicielles avec de nouvelles fonctionnalités. La plupart du code source de cette fonctionnalité a été réécrit avec la compatibilité à l'esprit, ce qui signifie que si l'utilisateur passe à la nouvelle version, il ne verra que les nouvelles fonctionnalités impressionnantes.
La conversion fonctionne pour 98% des utilisateurs. Les 2% restants auront fait quelque chose qui était possible en raison d '"erreurs" dans la conception précédente qui a été corrigée, et ils devront mettre à jour leurs paramètres avant que la fonctionnalité ne fonctionne à nouveau.
Comment informez-vous ces utilisateurs qu'ils doivent vérifier leurs paramètres après la mise à niveau?
Je vois plusieurs solutions et je me demandais quelle serait la meilleure solution.
- Notez dans les journaux des modifications, indiquant que chaque utilisateur doit vérifier ses paramètres après l'installation
- Afficher une fenêtre contextuelle unique après le lancement du programme après la mise à niveau
- Afficher une fenêtre contextuelle unique après avoir utilisé la fonctionnalité pour la première fois après la mise à niveau
- Ne l'informez pas, c'est seulement 2% de la base d'utilisateurs et ils ont utilisé des erreurs de conception qui ne devraient pas être possibles en premier lieu.
À mon avis, la meilleure voie à suivre est la suivante:
Mettre à jour les journaux des modifications
Les bons développeurs lisent ceux-ci avant la mise à niveau et les attentes appropriées seront définies pour assurer une mise à niveau réussie. En outre, selon la structure de l'organisation, l'équipe de mise à niveau peut fournir une visibilité aux équipes nécessaires au sein de l'organisation qui seront affectées.
Fenêtre contextuelle unique
Peu importe si vous touchez 2% ou 90% de tous les clients.
Q: Les changements/corrections de bogues sont-ils globaux pour l'application?
Si les modifications sont globales - vous avez raison, affichez une fenêtre contextuelle/assistant unique guidant l'utilisateur administrateur à travers les modifications apportées et les paramètres/fonctionnalités affectés. L'interface graphique permet de décrire toutes les petites ou grandes modifications , que le client soit affecté ou non . Laissez le client décider s'il est concerné ou non. Ne faites pas d'hypothèses de votre côté.
Si les modifications ne sont pas globales et sont spécifiques au profil - Vous devrez peut-être montrer la même chose (peut-être même une version moins technique de l'assistant de mise à niveau) à chaque utilisateur afin qu'il puisse apporter ses modifications ou simplement reconnaître les modifications.
Modifications automatisées
Cela peut être une bonne idée dans la plupart des cas si vous "remplacez" des configurations et que vous savez que le changement est de 1 à 1 en termes de ce que l'utilisateur attend à la suite d'un tel paramètre.
Cependant, dans de nombreux cas, la configuration ou les paramètres ajoutent de nouvelles options ou caractéristiques ou fonctionnalités où vous ne pouvez pas faire d'hypothèses quant aux options qui peuvent être applicables à la configuration de votre client. Dans de tels cas, l'assistant de mise à niveau doit être utilisé pour éduquer l'utilisateur sur les options et paramètres nouvellement ajoutés et permettre à l'utilisateur de fournir des modifications de configuration correctes.
Comme vous le dites dans les commentaires ci-dessus:
si l'utilisateur utilise un paramètre "illégal", il passera au paramètre "légal" le plus proche possible.
Étant donné que vous détectez déjà le problème et que vous effectuez cette opération, vous ne devez informer que les utilisateurs concernés.
Vous souhaiterez peut-être également avoir une note de version qui avertit les utilisateurs avant d'installer la mise à jour (s'ils choisissent de ne pas la mettre à jour, ou s'ils peuvent prendre des mesures pour atténuer le problème).