Le widget de chat de Kookee avait une seule tâche, et il la faisait bien : un visiteur pose une question, l’assistant répond à partir du centre d’aide et cite l’article utilisé. Puis le visiteur clique sur la citation, et le widget le laisse tomber. La page change, ou un nouvel onglet s’ouvre, et la conversation qui a produit la réponse se retrouve quelque part derrière lui.
Le clic qui aurait dû être le meilleur moment de l’échange était celui qui y mettait fin.
J’ai donc reconstruit le widget. Ce n’est plus seulement un chat : il a trois onglets, Accueil, Demander et Aide, et un lecteur d’articles. C’est en ligne depuis aujourd’hui, et voici les règles que j’ai suivies pour le construire.
1. Un article s’ouvre là où la question a été posée
Une source sous une réponse, un lien dans une réponse, un article dans une liste : tous s’ouvrent désormais dans le widget, dans un lecteur avec un bouton retour. La page derrière ne bouge pas, et la conversation non plus.
Le lecteur, c’est la page d’article du centre d’aide à la taille du widget : une table des matières, le même vote « Cet article vous a-t-il aidé ? », et un bouton Poser une question sur cet article qui transmet le titre de l’article au chat. Un article de blog ou une entrée du journal des modifications s’ouvre de la même façon, avec des boutons de réaction à la place du vote.
Si votre site gère déjà lui-même les clics sur les sources, rien ne change : votre gestionnaire garde la main, et le lecteur ne s’en mêle pas.
2. Toutes les visites ne commencent pas par une question
Un chat vide demande au visiteur de commencer par le plus difficile : mettre le problème en mots. Beaucoup de gens ouvrent un widget de support pour jeter un œil — voir si quelque chose est en panne, ce qui a changé, ou s’il existe un article dont le titre correspond à peu près.
Accueil est fait pour eux. Il affiche votre dernière annonce, vos propres liens, les dernières entrées du journal des modifications et les derniers articles de blog, ainsi que les articles d’aide les plus consultés, avec un champ de question en haut pour ceux qui savent quoi demander. Aide, c’est le centre d’aide lui-même : un champ de recherche et vos collections, chacune avec son nombre d’articles.
Rien de tout cela n’est du nouveau contenu. Accueil et Aide sont construits à partir de ce que vous publiez déjà, et une liste vide est masquée plutôt qu’affichée sans rien dedans.
Demander, c’est le chat de toujours, avec votre message d’accueil et quelques questions suggérées pour démarrer d’un seul geste.
3. N’importe quel lien de votre page peut ouvrir un article
La meilleure place pour une aide, c’est à côté de ce qu’elle explique : un point d’interrogation près d’un champ de réglages, un lien « Comment fonctionne la facturation ? » sur la page des tarifs. Jusqu’ici, ce lien devait mener ailleurs.
Ajoutez un attribut à n’importe quel élément, et un clic ouvre l’article dans le widget :
<a href="/help/getting-started" data-kookee-article="getting-started">Comment démarrer</a>Deux détails comptent ici. Le href reste, donc le lien fonctionne toujours quand le widget est bloqué ou pas encore chargé. Et un clic avec Ctrl, Cmd ou Maj enfoncé, ou avec le bouton du milieu de la souris, n’est pas intercepté : qui demande un nouvel onglet obtient un nouvel onglet. Les règles complètes sont dans Ouvrir les articles d’aide dans le widget.
4. Les textes vivent dans le tableau de bord, l’apparence dans votre code
J’ai beaucoup hésité sur ce point. Un widget a deux sortes de paramètres, et elles ont leur place à des endroits différents.
Ce qu’il dit — ses onglets, son titre, son message d’accueil, ses questions suggérées et ses liens — change souvent et relève rarement d’un développeur. Tout cela est enregistré dans le tableau de bord, dans l’onglet Personnaliser, avec un aperçu en direct, et une modification enregistrée arrive sur votre site en une minute environ, sans déploiement.
Son apparence — thème, position, couleur d’accent, bouton de lancement — n’est pas stockée du tout. Elle reste dans l’extrait de code de votre site. Une apparence chargée depuis un serveur arrive après l’affichage du bouton de lancement, d’où un clignotement ; et un même projet tourne souvent sur plusieurs sites qui ne doivent pas se ressembler. Le tableau de bord aide quand même : l’onglet Installation est un petit générateur avec aperçu qui écrit l’extrait pour vous.
Là où les deux se recoupent, le code l’emporte, clé par clé. Un site multilingue passe les textes traduits dans son code et laisse le tableau de bord décider du reste.
5. La requête de paramètres ne doit jamais faire tomber le widget
Des paramètres enregistrés, cela veut dire que le widget les demande maintenant au serveur, et chaque nouvelle requête est une nouvelle façon d’échouer. Je lui ai donc donné le moins de pouvoir possible :
Elle est faite une fois par chargement de page, et le navigateur garde la réponse une minute.
Elle ne compte pas dans votre quota mensuel d’API. Lire des paramètres à chaque affichage de page, ce n’est pas à cela que sert un quota.
Si elle échoue, le widget revient au simple chat qu’il était avant. Le visiteur voit moins d’onglets, jamais une erreur.
Ce que j’ai laissé de côté
Ce n’est pas un chat en direct. Aucun agent n’attend de l’autre côté : l’assistant répond à partir de vos articles, et vos instructions lui indiquent où envoyer les gens quand il ne peut pas répondre.
Il ne s’active pas non plus tout seul. Chaque widget déjà installé reste un simple chat jusqu’à ce que vous cochiez les onglets dans le tableau de bord.
Pour l’obtenir
La balise script en profite sans aucune modification de votre site. En React, passez à @kookee/react 1.11.0 et @kookee/sdk 1.11.0. Ouvrez ensuite Widget du site → Personnaliser dans votre projet et activez les onglets : Ajouter les onglets Accueil et Aide à votre widget détaille chaque étape, et Installer le widget du site sur votre site web couvre une première installation.