Un bouton d'export d'informations / logs

Je vois de plus en plus de personnes qui demandent de l’aide sur le Forum et c’est toujours difficile de comprendre le problème sans un minimum d’informations.
Je propose un bouton dans la partie Paramètres > Système qui permettrait d’extraire un fichier (ou un texte) contenant les informations de base (version Gladys, version système, périphérique sur lequel Gladys est installé) et un extrait des derniers logs (par service ?).

Cela permettrait à des utilisateurs novices d’obtenir de l’aide plus facilement sur le forum.

Je suis d’accord sur le problème, pas forcément avec la solution.

Revenons donc à la base du problème.

Quels sont les types de problèmes utilisateurs qu’on rencontre sur le forum ?

  1. Un périphérique non-géré par Gladys qu’il pensait gérer dans Gladys mais n’arrive pas à le gérer.
  2. Un périphérique non découvert par Gladys alors qu’il devrait être compatible selon le site.
  3. un bug d’interface

Si tu vois d’autres cas précis de post sur le forum dis moi :slight_smile:

Dans 1., c’est un souci de communication: notre doc n’est pas assez riche et l’utilisateur pensait que ça allait marcher, alors que nous ne gérons pas le périphérique. L’interface aurait pu le prévenir en lui disant “Aucun périphérique détecté. Est-ce que votre périphérique est bien dans la liste des périphériques géré ? [INSERER LIEN VERS LISTE ICI]”.

Dans 2. c’est un souci de clarté d’interface. L’interface pourrait donner plus de retours sur ce que le code backend “voit” en “brut”. Il faut voir service par service comment on pourrait rendre l’interface plus clair avec des retours d’états plus fin de la data concrètement reçu par le backend. Exemple: dans le cas du Xiaomi, on pourrait afficher une liste de 10 derniers messages reçus par Gladys, en format quasi brut.

Dans le cas 3., souvent une simple description de comment reproduire le bug suffit à le reproduire côté dev.

Le problème que je vois avec une solution type “on sort un fichier export de l’instance Gladys et l’utilisateur le met sur le forum”, est qu’on incite l’utilisateur a être passif dans son débuggage, et que ça place l’utilisateur dans une relation “utilisateur <-> support client” avec le forum. Le fichier risque d’être un gros pavé remplit de jargon tech, que l’utilisateur ne lira pas (car illisible pour un non initié), il le copiera seulement sur le forum.

Le résultat ? La charge de support sur le forum ne va faire qu’augmenter, et la satisfaction utilisateur va paradoxalement diminuer car l’utilisateur devra attendre un retour d’un “expert”, “expert” qui ne sera pas disponible car il aura trop de requêtes à répondre.

Ce que je vois plutôt

L’utilisateur devrait avoir pour moi toutes les clés en main dans le produit pour voir ce qui ne va pas, et être ainsi acteur de sa résolution de problème.

Il faut faire une passe service par service pour identifier les points souvent bloquants, et ajouter dans l’interface plus de messages (d’erreurs, d’information) clair pour chaque point bloquant identifié.

Pour les simples soucis de compréhension (qu’est ce qui est compatible gladys?), il faut réussir à mieux rediriger vers la documentation au lieu du forum pour que l’utilisateur puisse s’auto-répondre et avoir sa réponse sans attendre :slight_smile:

Qu’en pense tu ?

Je sais que mon post peut faire hyper complet pour la simple fonctionnalité que tu demandais, mais je pense qu’il est crucial de poser les bonnes bases pour s’éviter des heures de support inutile là ou une simple interface plus clair suffit souvent. C’est des petits choix d’UX simple comme ça qui vont faire que la v4 va pouvoir se “scaler” à plusieurs milliers d’utilisateurs ou pas.

@VonOx @AlexTrovato je vous tag ici, je pense qu’il y a un gros chantier à venir sur ce sujet.

Actuellement on a vraiment aucune information quand quelque chose ne va pas sur certains intégrations (Z-Wave, Bluetooth, Xiaomi), il y a une vrai réflexion à avoir pour qu’on puisse faciliter le debug, toujours dans l’esprit user-friendly de la v4 et en laissant le maximum de bille à l’utilisateur pour qu’il puisse se faire une idée lui même de ce qui ne va pas.

Je vais prendre un exemple simple: le service Xiaomi.

Récapitulatif des demandes qu’on a :

  • “Je n’arrive pas à activer le mode développeur sur mon gateway xiaomi” -> préciser dans l’UI que seule les gateway xiaomi old gen sont compatible. Un lien vers la documentation pourrait être adapté.
  • “Je ne vois aucun périphériques” -> Questions de débug classique devrait apparaitre dans l’UI: Est-ce que le gateway est sur le même réseau que Gladys ? Est-ce que le mode développeur a bien été activé sur le gateway Xiaomi ? "
  • “J’ai un capteur qui est affiché mais pas un autre” -> Dans l’UI, devrait apparaitre: “Voilà la liste des 10 derniers messages que j’ai reçu du gateway Xiaomi, et voilà pour chaque message ce que j’ai extrait”. Exemple: “sensor_ht” => “temperature sensor”, “aq2.blablabbla” => “not recognized”.

Je pense qu’en travaillant sur l’UI au lieu de rediriger sur le forum, tout le monde y gagne: l’utilisateur trouve ses réponses dans le produit, et nous on est moins sollicité pour des problèmes mineurs.

1 Like

Tout à fait d’accord pour éviter que le forum se transforme en support client. C’est très chronophage et parfois infantilisant pour les utilisateurs.
J’aime bien l’idée que les services répondent à quelques normes d’interaction utilisateur. Je pense qu’on a tous la vision technique mais que l’UX demande quelques efforts pour faciliter son utilisation.
Et on ressent bien dans cette v4 l’orientation que tu veux donner. Ce qui est compliqué lors de l’intégration de matériel, c’est la diversité des périphériques et des cas de bug.

Je vais essayer de proposer une page supplémentaire d’Aide dans la documentation avec un guide pour identifier les principaux problèmes connus et donner plus d’autonomie aux utilisateurs.
On peut aussi ajouter une FAQ en bas des pages Intégrations (cas des gateway Xiaomi par exemple).

Je pense aussi qu’il faut différencier les utilisateurs néophytes qui veulent installer et tout configurer juste en cliquant et ceux qui savent développer, lire les logs, se connecter à Docker etc.
Les deux catégories seront gagnantes s’il y a plus d’informations dans Gladys (doc et produit) et la deuxième catégorie aura peut-être plus envie de comprendre/corriger des bugs ou de se lancer dans des intégrations supplémentaires.

1 Like

je pense que c’est plus dans le produit que doivent se trouver ces aides. La documentation est une aide supplémentaire en mode tuto, mais le produit doit être la source de vérité par défaut.

La question a se poser c’est : quand tu installe une app sur ton iPhone, tu t’es déjà référé à un manuel d’utilisation ? Perso, jamais :smiley:

Tout fonctionne et quand il y a un bug dans une app, l’app me le dit dans l’app: ça doit être pareil dans Gladys.

1 Like