Driver.js : bibliothèque Vanilla JS pour les visites produit, les mises en avant et l’aide contextuelle

 (driverjs.com)
4 points par GN⁺ 2023-07-25 | 1 commentaires | Partager sur WhatsApp
  • Il s’agit d’une bibliothèque JavaScript légère permettant d’ajouter des visites produit et des mises en avant aux écrans où il faut guider les utilisateurs dans le produit
  • Elle fonctionne sur une base Vanilla JavaScript, sans dépendances, et prend en charge les principaux navigateurs ainsi que les appareils mobiles
  • C’est un projet open source sous licence MIT, écrit en TypeScript, qui met en avant la personnalisation et la prise en charge de l’accessibilité
  • Elle est adaptée aux parcours de guidage intégrés au produit, comme l’onboarding utilisateur, la focalisation de l’attention, l’aide contextuelle et l’encouragement à l’adoption de nouvelles fonctionnalités
  • Elle cumule plusieurs millions de téléchargements et 26K GitHub Stars ; des exemples de démarrage et la documentation sont disponibles dans la documentation officielle

Nature de la bibliothèque et périmètre de prise en charge

  • Driver.js est une bibliothèque JavaScript légère qui aide les utilisateurs à comprendre un produit grâce à des visites produit, des mises en avant et de l’aide contextuelle
  • Basée sur Vanilla JavaScript, elle peut être utilisée sans dépendance supplémentaire et est écrite en TypeScript
  • Ses principales caractéristiques en matière de prise en charge et de configuration sont les suivantes
    • prise en charge des principaux navigateurs et des appareils mobiles
    • haut niveau de personnalisation
    • structure légère et fonctionnalités riches
    • licence MIT
    • API facile à utiliser
    • prise en charge de l’accessibilité
    • prête pour les frameworks

Usages dans le produit

  • Onboarding utilisateur : permet d’expliquer pas à pas comment utiliser le produit et de guider les utilisateurs en répondant aux questions courantes
  • Réduction des distractions : permet de mettre en avant des éléments importants afin de concentrer l’attention de l’utilisateur sur une zone précise
  • Aide contextuelle : permet de fournir des explications d’usage et de l’aide au moment opportun, directement dans le produit
  • Adoption des fonctionnalités : permet de mettre en avant les nouvelles fonctionnalités et d’expliquer leur usage pour éviter que les utilisateurs ne passent à côté

Documentation et informations sur le projet

  • Davantage d’exemples et la marche à suivre pour démarrer sont disponibles dans la documentation
  • Le dépôt GitHub est kamranahmedse/driver.js, et le nombre d’étoiles GitHub affiché est de 26K

À lire aussi

1 commentaires

 
GN⁺ 2023-07-25
Avis sur Hacker News

  • Non, le produit doit être conçu pour être compréhensible dès la première utilisation
    Apple est connu pour ne presque jamais faire ce genre de chose sur l’iPhone, alors que Sony impose ce type de procédure à chaque nouvel appareil
    L’onboarding devrait être un levier pour faire progresser l’utilisabilité ; ici, ce n’est pas un outil d’appoint, c’est pire, et nuisible

    • Dire qu’« Apple ne fait presque jamais ce genre de chose sur l’iPhone » plaide plutôt en faveur de la nécessité d’un tour du produit
      L’utilisabilité d’iOS est catastrophique, les affordances sont faibles et la découvrabilité aussi
      Il y a beaucoup trop de modes de saisie, surtout des gestes, que l’on ne connaît pas si personne ne vous les montre ou si l’on ne les cherche pas, et ils ne sont pas cohérents d’une app à l’autre, ni même entre les apps Apple par défaut
      Parfois, « glisser une ligne vers la gauche » veut dire « supprimer », parfois « actions supplémentaires » : c’est simplement le bazar
      Quand on observe des utilisateurs non techniques utiliser un iPhone, ils ignorent souvent plus de la moitié des fonctionnalités disponibles. Par exemple, avez-vous déjà vu quelqu’un utiliser « secouer pour annuler » ?
    • C’est peut-être pour ça que la moitié des utilisateurs d’iPhone ne savent toujours pas qu’on peut maintenir le clavier ou la barre d’espace enfoncés pour contrôler le curseur. Ce n’est qu’un exemple
    • Cette approche n’est pas pratique pour tout. Un téléphone doit être intuitif et, plus important encore, il n’est pas nécessaire de connaître tous les modes d’interaction dès le départ ; on peut les apprendre avec le temps
      Mais récemment, en m’inscrivant à HubSpot comme CRM, j’ai eu l’impression que, même si le produit était globalement bien organisé et intuitif, il est difficile, voire presque impossible, de le rendre aussi intuitif qu’un smartphone. Dans ce cas, un tour du produit est assez utile
    • Je suis d’accord pour dire qu’on veut toujours de l’utilisabilité et de la découvrabilité. Mais affirmer que tout devrait toujours être simplement découvrable me rappelle le débat mythique du compilateur suffisamment intelligent
      Autrement dit, c’est plutôt un idéal inatteignable qui n’existe pas dans la réalité
      Avec le niveau actuel d’expérience utilisateur, il est difficile d’être sûr qu’on puisse créer une UI qui n’ait absolument pas besoin de tour du produit, de documentation, de tutoriels vidéo, etc., surtout à partir d’un certain niveau de complexité
    • Pour une app grand public, je pense que c’est globalement vrai
      Mais les apps B2B, où les tutoriels de démo produit sont principalement utilisés, sont différentes. Un bon tutoriel produit est utile pour qu’un commercial guide le client dans l’app et la vende correctement à un prospect
      Si la taille des contrats se chiffre en dizaines ou centaines de milliers de dollars et que le produit est assez complexe, c’est une meilleure solution que de laisser les équipes commerciales et support éteindre les incendies en permanence

  • Suis-je le seul à fermer ce genre de choses le plus vite possible en râlant parce que ça m’agace ?

    • Moi aussi, mais pour être juste, il est fort probable que les utilisateurs techniques comme nous sur HN ne soient pas le public principal des produits qui intègrent ce genre de chose
    • Si on peut passer l’étape et y revenir plus tard, ça me va
      En général on peut passer, mais une fois qu’on a décidé de vraiment apprendre à utiliser l’app, il est presque impossible de trouver comment relancer le tour
    • Ça dépend du cas d’usage. Lors de l’onboarding des utilisateurs, cela réduit les e-mails au support envoyés parce qu’ils ne savent pas comment effectuer les tâches de base
      C’est aussi utile pour montrer une nouvelle fonctionnalité demandée, mais pas assez importante pour occuper de l’espace sur l’écran principal
      Ce n’est agaçant que quand ça pointe des évidences
    • Souvent, ça ressemble à une béquille pour compenser une mauvaise conception, mais certains produits ont tout simplement une complexité inévitable
    • J’ai vu plusieurs fois, dans les discussions sur l’UI, appeler ce genre de choses — pop-ups de téléchargement d’app, pop-ups de mailing list, encore téléchargement d’app, suivi sur les réseaux sociaux, encore téléchargement d’app — des nags. Probablement parce que « va te faire foutre » prend trop de caractères
      Entre ce qui aide et ce qui est hostile, il n’y a pas une ligne fine, mais une grosse ligne bien visible avec des gyrophares et une sirène

  • En tant qu’utilisateur, je déteste les tours de produit, mais en tant que développeur produit, j’espère toujours une alternative open source
    Cette bibliothèque a l’air assez chouette, les effets semblent fluides
    D’après ce que j’ai vu en créant quelques produits, même les tours de produit les mieux conçus sont fermés dans environ 90 % des cas sur les produits PME et grand public

  • J’aime un peu ce genre de fonctionnalité
    Il ne faut pas l’imposer aux nouveaux utilisateurs, il suffit de leur demander s’ils veulent faire le tour
    Il faudrait l’utiliser avec parcimonie, seulement lorsqu’une nouvelle fonctionnalité, un bouton ou un changement est ajouté à l’app, ne l’afficher qu’une fois par session, et proposer « fermer / faire le tour »
    Une expérience utilisateur intuitive reste préférable, mais un tour non obligatoire peut aider
    C’est mieux qu’un écran intermédiaire à la connexion pour annoncer des fonctionnalités

    • Par pitié, qu’on fournisse quelque part un menu d’aide avec une documentation correcte et la possibilité de relancer les tours
      Beaucoup de designers semblent penser que j’ouvre l’app en me demandant : « Quelle réjouissance ces gens formidables m’ont-ils préparée aujourd’hui ? », comme si j’avais du temps à perdre
      En réalité, la plupart du temps, j’ouvre l’app pour terminer une tâche précise tout de suite, et c’est le moment où je suis le moins réceptif à quelqu’un qui me met sous le nez les photos de son bébé-produit en me forçant à dire : « Oui, vraiment très joli »
      Le moment où je suis réellement disposé à faire un tour, c’est après avoir terminé mon travail, ou juste après avoir compris que je ne sais pas comment faire ce que je veux faire

  • Les tours de produit ne sont pas toujours mauvais, mais ils sont souvent mal implémentés, avec trop d’étapes qui n’apportent rien à l’utilisateur
    Un onboarding contextuel, comme des conseils intégrés, pertinent, comme un onboarding adapté par persona, ou orienté action, comme une checklist, est généralement meilleur
    Après avoir dirigé les équipes onboarding et formation in-app chez Dropbox, j’ai lancé Dopt [0], une bibliothèque de composants React et un SDK destinés à faciliter la création d’expériences d’onboarding plus contextuelles et moins intrusives, comme des conseils intégrés et des checklists, pas seulement des tours
    Avec Dopt, on peut aussi créer, si nécessaire, un tour en deux étapes pour présenter une nouvelle fonctionnalité, mais nous voulons offrir une boîte à outils plus large et meilleure pour tous les types d’onboarding et de formation
    [0] https://dopt.com/

    • Je me demande pourquoi le site web doit collecter des cookies. La première chose qu’on voit est un écran d’avertissement sur les cookies, ce qui fait se demander ce qui est suivi
      Et je me pose aussi des questions sur le « Hybrid work »
      À première vue, c’est bien de l’indiquer clairement, mais comme il existe des études[0] montrant que le télétravail à 100 % conduit à des employés plus productifs, je me demande pourquoi vous avez retenu l’hybride comme solution
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • Ça a l’air bien. Qu’est-ce qui le différencie de Shepherd[0] ?
    [0] : https://github.com/shipshapecode/shepherd

  • Le problème avec ce genre de visite guidée, c’est qu’elle vous met trop d’informations sous le nez en trop peu de temps, puis disparaît
    Quelques minutes plus tard, l’utilisateur se demande : « à quoi servait cette zone, déjà ? »
    Je l’ai utilisé autrefois en construisant une plateforme de pilotage de drones : le tableau de bord était complexe, et il fallait savoir avant de cliquer quelles zones servaient au pilotage et lesquelles au flux vidéo
    Mais les utilisateurs ne lisaient pas vraiment, hochaient la tête et cliquaient simplement sur Suivant ; au final, nous l’avons supprimé et ajouté des icônes d’information dans chaque zone, afin d’afficher une explication au survol

  • Pour faire quelque chose de similaire dans une application Redux, j’ai créé la bibliothèque https://github.com/Evernote/Aquaman. J’avais aussi créé la même chose pour React context, mais elle n’a pas été publiée en open source
    Ce qui manque ici, c’est que 1) l’état de l’application peut devoir déclencher une visite guidée, 2) il est très probable qu’on ait un jour besoin de flux en plusieurs étapes, et 3) la logique de changement d’état de ces flux doit être séparée de la logique de rendu
    Toutes les étapes d’un flux doivent être regroupées. Avec Aquaman, on pouvait implémenter cela

  • En tant qu’utilisateur, je déteste ça, mais en tant que développeur, c’est une bonne bibliothèque pour satisfaire les demandes de l’équipe produit

  • Aujourd’hui, j’ai vu une démo Walnut.io [1] pour un autre produit ; j’en ai sauté la majeure partie et je n’ai presque rien compris au produit
    À mon avis, cela dépend moins de l’outil lui-même que de qui conçoit la visite guidée du produit et comment
    Certains produits sont complexes et peuvent nécessiter des explications ou l’accompagnement d’un ingénieur solutions ou d’un responsable de compte. Aucun produit n’est assez extraordinaire pour n’avoir besoin d’aucune aide ni d’aucune visite guidée
    [1] https://walnut.io