Driver.js: Vanilla-JS-Bibliothek für Produkt-Touren, Highlights und kontextbezogene Hilfe

 (driverjs.com)
4 Punkte von GN⁺ 2023-07-25 | 1 Kommentare | Auf WhatsApp teilen
  • Eine schlanke JavaScript-Bibliothek, mit der sich Produkt-Touren und Highlights auf Bildschirmen integrieren lassen, auf denen Nutzer innerhalb eines Produkts geführt werden sollen
  • Basiert auf Vanilla JavaScript, kommt ohne Abhängigkeiten aus und unterstützt wichtige Browser sowie mobile Geräte
  • Ein Open-Source-Projekt unter MIT-Lizenz, geschrieben in TypeScript, mit Fokus auf Anpassbarkeit und Unterstützung für Barrierefreiheit
  • Auf In-Product-Guidance-Flows zugeschnitten, etwa für Benutzer-Onboarding, Lenkung der Aufmerksamkeit, kontextbezogene Hilfe und die Förderung der Adoption neuer Funktionen
  • Verfügt über Millionen Downloads und 26K GitHub-Stars; Einstiegsbeispiele und Dokumentation finden sich in der offiziellen Dokumentation

Charakter der Bibliothek und unterstützter Umfang

  • Driver.js ist eine schlanke JavaScript-Bibliothek, die Nutzern mit Produkt-Touren, Highlights und kontextbezogener Hilfe dabei hilft, ein Produkt zu verstehen
  • Sie basiert auf Vanilla JavaScript, kann ohne zusätzliche Abhängigkeiten verwendet werden und ist in TypeScript geschrieben
  • Zu den Merkmalen bei Unterstützung und Konfiguration gehören:
    • Unterstützung für wichtige Browser und mobile Geräte
    • Hohe Anpassbarkeit
    • Schlanke Struktur und umfangreiche Funktionen
    • MIT-Lizenz
    • Einfach zu nutzende API
    • Unterstützung für Barrierefreiheit
    • Framework-ready

Einsatzweise innerhalb des Produkts

  • Benutzer-Onboarding: Kann die Nutzung des Produkts schrittweise erklären und dabei helfen, häufige Fragen zu beantworten
  • Ablenkungen reduzieren: Wichtige Elemente können hervorgehoben werden, damit sich die Aufmerksamkeit der Nutzer auf einen bestimmten Bereich richtet
  • Kontextbezogene Hilfe: Kann im entscheidenden Moment innerhalb des Produkts Anleitungen und Hilfestellungen bereitstellen
  • Funktionsadoption: Neue Funktionen können hervorgehoben und erklärt werden, damit Nutzer sie nicht übersehen

Dokumentation und Projektinformationen

  • Weitere Beispiele und eine Anleitung für den Einstieg bietet die Dokumentation
  • Das GitHub-Repository ist kamranahmedse/driver.js; die Zahl der GitHub-Stars wird mit 26K angegeben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-25
Hacker-News-Kommentare

  • Nein, ein Produkt sollte so gestaltet sein, dass man es auch beim ersten Ansehen versteht
    Apple ist dafür bekannt, das beim iPhone fast nie zu tun, während Sony einen bei jedem neuen Gerät zu solchen Abläufen zwingt
    Onboarding sollte die Nutzbarkeit fördern; andernfalls ist es kein Hilfsmittel, sondern etwas Schlechteres und Schädlicheres

    • Die Aussage „Apple macht so etwas beim iPhone fast nie“ spricht eher dafür, dass Produkttouren nötig sind
      Die Usability von iOS ist miserabel, die Affordance schwach und die Discoverability gering
      Es gibt viel zu viele Eingabemethoden, meist Gesten, die man nicht kennt, wenn es einem niemand zeigt oder man nicht danach sucht, und sie sind je nach App uneinheitlich, sogar zwischen Apples eigenen Standard-Apps
      Mal bedeutet „eine Zeile nach links wischen“ „löschen“, mal „weitere Aktionen“ — es ist einfach ein Durcheinander
      Wenn man nichttechnische Nutzer bei der Verwendung eines iPhones beobachtet, kennen sie oft nicht einmal die Hälfte der möglichen Funktionen. Hat man zum Beispiel jemals jemanden gesehen, der „Zum Rückgängigmachen schütteln“ verwendet?
    • Deshalb weiß vielleicht die Hälfte der iPhone-Nutzer bis heute nicht, dass man durch langes Drücken auf die Tastatur oder die Leertaste den Cursor steuern kann. Das ist nur ein Beispiel
    • Für alles ist dieser Ansatz nicht praktikabel. Ein Telefon sollte intuitiv sein, und noch wichtiger: Man muss nicht von Anfang an jede Interaktionsweise kennen, sondern kann sie mit der Zeit lernen
      Aber ich habe mich kürzlich bei einem CRM bei HubSpot angemeldet und fand das Produkt insgesamt gut organisiert und intuitiv, obwohl es schwer oder nahezu unmöglich ist, es so intuitiv wie ein Smartphone zu machen. In solchen Fällen ist eine Produkttour ziemlich hilfreich
    • Ich stimme zu, dass man immer Usability und Discoverability will. Aber zu behaupten, alles müsse jederzeit einfach so auffindbar sein, klingt wie die Diskussion um den legendären hinreichend intelligenten Compiler
      Also eher nach einem unerreichbaren Ideal, das es in der Realität nicht gibt
      Beim heutigen Stand der User Experience fällt es schwer zu glauben, dass man eine UI bauen kann, die keinerlei Produkttouren, Dokumentation oder Video-Tutorials braucht, und das gilt erst recht für auch nur einigermaßen komplexe Produkte
    • Für Consumer-Apps stimmt das größtenteils wohl
      Aber B2B-Apps, in denen Produkt-Demo-Tutorials hauptsächlich eingesetzt werden, sind anders. Gute Produkt-Tutorials helfen Vertriebsmitarbeitern dabei, Kunden durch die App zu führen und sie potenziellen Kunden richtig zu verkaufen
      Wenn Vertragsvolumen im Zehn- bis Hunderttausend-Dollar-Bereich liegen und das Produkt ziemlich komplex ist, ist das eine bessere Lösung, als dass Sales- und Support-Teams ständig Feuer löschen müssen

  • Bin ich der Einzige, der solche Dinge so schnell wie möglich wegklickt und sich dabei genervt beschwert?

    • Ich auch, aber fairerweise sind technische Nutzer wie wir auf HN wahrscheinlich nicht die Hauptzielgruppe von Produkten, die so etwas integriert haben
    • Wenn man es überspringen und später erneut aufrufen kann, finde ich es okay
      Überspringen geht meist, aber einen Weg zu finden, es später noch einmal zu starten, nachdem man beschlossen hat, die App doch richtig kennenzulernen, ist fast immer schwierig
    • Das hängt vom Anwendungsfall ab. Beim Onboarding von Nutzern verringert es Support-Mails, die entstehen, weil Leute nicht wissen, wie grundlegende Aufgaben erledigt werden
      Außerdem eignet es sich gut, um neue Funktionen zu zeigen, die zwar gewünscht wurden, aber nicht so wichtig sind, dass sie Platz auf dem Hauptbildschirm verdienen
      Nervig ist es nur, wenn auf Offensichtliches hingewiesen wird
    • Meist wirkt es wie eine Krücke, die schlechtes Design ausgleichen soll, aber manche Produkte haben nun einmal unvermeidlich Komplexität
    • Im Zusammenhang mit UI-Konzepten habe ich solche Dinge, App-Download-Popups, Mailinglisten-Popups, noch mal App-Download, Social-Media-Follow-Aufforderungen und wieder App-Download ein paar Mal als Nörgelei bezeichnet gesehen. Vermutlich nur, weil „Leck mich“ zu viele Buchstaben hat
      Zwischen etwas Hilfreichem und etwas Feindseligem liegt keine feine Linie, sondern eine große, unübersehbare mit blinkenden Lichtern und Sirenen

  • Als Produktnutzer hasse ich Produkttouren, aber als Produktentwickler wünsche ich mir immer eine Open-Source-Alternative
    Diese Bibliothek sieht ziemlich cool aus, die Effekte wirken flüssig
    Nach dem, was ich beim Bau einiger Produkte persönlich gesehen habe, werden selbst die am besten gestalteten Produkttouren bei KMU- und Consumer-Produkten zu etwa 90 % einfach geschlossen

  • Ich mag solche Funktionen ein bisschen
    Man sollte sie neuen Nutzern nicht aufzwingen, sondern fragen, ob sie eine Tour machen möchten
    Man sollte sie sparsam einsetzen, nur wenn der App neue Funktionen, Buttons oder Änderungen hinzugefügt wurden, sie nur einmal pro Sitzung anzeigen und den Prompt als Wahl zwischen „Schließen/Tour ansehen“ gestalten
    Eine intuitive User Experience der App ist besser, aber nicht erzwungene Touren können hilfreich sein
    Sie sind besser als ein Interstital nach dem Login zur Ankündigung von Features

    • Bitte bietet irgendwo ein Hilfe-Menü mit brauchbarer Dokumentation und der Möglichkeit, Touren erneut zu starten
      Viele Designer scheinen zu glauben, dass ich beim Öffnen einer App denke: „Was für einen Spaß haben diese tollen Leute heute wohl für mich vorbereitet?“ und unbegrenzt Zeit habe
      Tatsächlich öffnet man eine App meistens, weil man genau jetzt eine konkrete Aufgabe erledigen will, und genau dann ist man am wenigsten empfänglich dafür, dass jemand einem Fotos seines Produktbabys unter die Nase hält und ein „Ja, wirklich hübsch“ hören will
      Wirklich offen für eine Tour bin ich erst, nachdem ich meine Aufgabe erledigt habe oder gerade festgestellt habe, dass ich nicht weiß, wie ich das tun soll, was ich tun möchte

  • Produkttouren sind nicht immer schlecht, aber oft schlecht umgesetzt, mit zu vielen Schritten, die für den Nutzer bedeutungslos sind
    Kontextbezogene integrierte Tipps, relevantes personaspezifisches Onboarding oder handlungsorientiertes Onboarding wie Checklisten sind im Allgemeinen besser
    Nachdem ich bei Dropbox das Team für Onboarding und In-App-Education geleitet hatte, habe ich Dopt [0] gestartet, eine React-Komponentenbibliothek und ein SDK, mit denen sich nicht nur Touren, sondern auch kontextbezogenere und weniger störende Onboarding-Erlebnisse wie integrierte Tipps und Checklisten einfach erstellen lassen
    Mit Dopt kann man bei Bedarf auch Dinge wie eine zweistufige Tour zur Einführung neuer Funktionen bauen, aber ich möchte einen größeren und besseren Werkzeugkasten für alle Arten von Onboarding und Education bereitstellen
    [0] https://dopt.com/

    • Ich frage mich, warum auf der Website Cookies gesammelt werden müssen. Das Erste, was man zu sehen bekommt, ist der Cookie-Hinweis, daher frage ich mich, was dort getrackt wird
      Und ich frage mich auch wegen „Hybrid work“
      Oberflächlich betrachtet ist es gut, das vorab klar anzugeben, aber angesichts von Studien[0], laut denen 100 % Remote-Arbeit zu produktiveren Mitarbeitern führt, frage ich mich, warum Hybrid als Lösung festgelegt wurde
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • Sieht gut aus. Was ist im Vergleich zu Shepherd[0] anders?
    [0]: https://github.com/shipshapecode/shepherd

  • Das Problem bei solchen Touren ist, dass sie in kurzer Zeit zu viele Informationen direkt vor das Gesicht werfen und dann wieder verschwinden
    Ein paar Minuten später fragt sich der Nutzer dann: „Wofür war dieser Bereich noch mal da?“
    Ich habe so etwas früher beim Bau einer Plattform zur Drohnensteuerung verwendet, aber das Dashboard war komplex, und man musste vor dem Klicken wissen, welche Bereiche für die Steuerung und welche für den Video-Feed gedacht waren
    Die Nutzer haben das jedoch meist nicht gelesen, nur genickt und immer weiter auf Weiter geklickt; am Ende haben wir es entfernt und stattdessen in jedem Bereich ein Info-Symbol angebracht, sodass man per Mouseover eine Erklärung sehen konnte

  • Ich habe die Bibliothek https://github.com/Evernote/Aquaman gebaut, um in einer Redux-App etwas Ähnliches zu machen. Dasselbe habe ich auch für React context gebaut, aber nicht als Open Source veröffentlicht
    Was hier fehlt, ist, dass 1) der App-Zustand möglicherweise eine geführte Tour auslösen muss, 2) man wahrscheinlich irgendwann einen mehrstufigen Ablauf braucht und 3) die Logik für Zustandsänderungen in diesem Ablauf von der Rendering-Logik getrennt sein sollte
    Alle Schritte des Ablaufs sollten zusammen an einem Ort liegen. Mit Aquaman ließ sich das umsetzen

  • Als Nutzer mag ich so etwas nicht, aber als Entwickler ist es eine gute Bibliothek, um die Anforderungen des Produktteams zu erfüllen

  • Ich habe heute eine Walnut.io-[1]-Demo für ein anderes Produkt gesehen, sie größtenteils übersprungen und das Produkt trotzdem kaum verstanden
    Ich denke, es hängt weniger vom Tool selbst ab als davon, wer die Produkttour wie zusammenstellt
    Manche Produkte sind so komplex, dass sie Erklärungen oder die Begleitung durch einen Solutions Engineer oder Account Manager brauchen. Es gibt kein Produkt, das so erstaunlich ist, dass es überhaupt keine Hilfe oder Produkttour braucht
    [1] https://walnut.io