Driver.js: 製品ツアー・ハイライト・コンテキストヘルプのためのVanilla JSライブラリ

 (driverjs.com)
4 ポイント 投稿者 GN⁺ 2023-07-25 | 1件のコメント | WhatsAppで共有
  • 製品内でユーザーを案内する必要がある画面に、製品ツアーとハイライトを追加できる軽量JavaScriptライブラリ
  • Vanilla JavaScriptベースで動作し、依存関係がなく、主要ブラウザーとモバイルデバイスをサポート
  • TypeScriptで書かれたMITライセンスのオープンソースで、カスタマイズ性とアクセシビリティ対応を特徴としている
  • ユーザーオンボーディング、注意喚起、コンテキストヘルプ、新機能の採用促進といった製品内ガイドフローに適している
  • 数百万ダウンロードとGitHub Star 26Kを持ち、開始用のサンプルとドキュメントは公式ドキュメントで確認できる

ライブラリの性格と対応範囲

  • Driver.jsは、製品ツアー、ハイライト、コンテキストヘルプによってユーザーの製品理解を助ける軽量JavaScriptライブラリ
  • Vanilla JavaScriptベースのため追加の依存関係なしで利用でき、TypeScriptで記述されている
  • サポート・構成面での特徴は以下のとおり
    • 主要ブラウザーとモバイルデバイスをサポート
    • 高いカスタマイズ性
    • 軽量構成と豊富な機能
    • MITライセンス
    • 使いやすいAPI
    • アクセシビリティ対応
    • フレームワーク対応済み

製品内での活用方法

  • ユーザーオンボーディング: 製品の使い方を段階的に説明し、一般的な質問に答えるよう案内できる
  • 注意散漫の排除: 重要な要素をハイライトし、ユーザーの視線を特定の領域に集中させられる
  • コンテキストヘルプ: 製品内で必要な瞬間に使い方とヘルプを提供できる
  • 機能採用: 新機能をハイライトして使い方を説明し、ユーザーが見逃さないようにできる

ドキュメントとプロジェクト情報

関連記事

1件のコメント

 
GN⁺ 2023-07-25
Hacker News の意見

  • いや、製品は初見でも理解できるように設計すべきだ
    Apple は iPhone でこういうことをほとんどしないことで有名な一方、Sony は新しいデバイスのたびにこうした手順を強いる
    オンボーディングでユーザビリティを無理やり押し通すようにすべきではない。これは補助ツールではなく、もっと悪く有害なものだ

    • 「Apple は iPhone でこういうことをほとんどしない」という話は、むしろ製品ツアーが必要だという側に近い
      iOS のユーザビリティはひどく、アフォーダンスが足りず、発見可能性も低い
      誰かに教えてもらうか検索しないと分からない入力方法、主にジェスチャーが多すぎるし、アプリごとに、Apple 純正アプリ同士でさえ一貫していない
      ある時は「行を左にスワイプ」が「削除」で、別の時は「追加操作」だったりして、とにかくぐちゃぐちゃだ
      非技術系ユーザーが iPhone を使っているのを見ると、可能な機能の半分も知らないことが多い。例えば「シェイクして取り消し」を使っている人を見たことがあるだろうか？
    • だから iPhone ユーザーの半分はいまだに、キーボードやスペースバーを長押ししてカーソル操作ができることを知らないのかもしれない。これは一例にすぎない
    • すべてにこの方式が実用的なわけではない。スマートフォンは直感的であるべきだし、さらに重要なのは、最初からすべての操作方法を知っている必要はなく、時間とともに覚えられることだ
      ただ最近 CRM として HubSpot に登録してみたところ、全体としてよく整理され直感的な製品だと感じつつも、スマートフォンほど直感的に作るのは難しい、あるいはほぼ不可能だと思った。こういう場合、製品ツアーはかなり役に立つ
    • ユーザビリティと発見可能性を常に求めたい、という点には同意する。だが、あらゆるものが常に自然に発見できるべきだという主張は、伝説上の十分に賢いコンパイラの議論のように聞こえる
      現実には存在しない、達成不可能な理想に近いという意味だ
      現在のユーザー体験の水準で、製品ツアー、ドキュメント、動画チュートリアルなどが一切不要な UI を作れるとは確信しにくいし、少なくともある程度複雑な製品ではなおさらだ
    • コンシューマー向けアプリなら、おおむねその通りだと思う
      だが製品デモのチュートリアルが主に使われるB2B アプリは違う。優れた製品チュートリアルは、営業担当者が顧客にアプリを案内し、見込み客にきちんと売り込むのに役立つ
      契約規模が数万〜数十万ドルで、製品もかなり複雑なら、営業・サポート担当が常に火消し対応を続けるより良い解決策だ

  • こういうものをできるだけ早く閉じて、うんざりだと愚痴るのは自分だけだろうか？

    • 私もそうだが、公平に見れば、HN にいる私たちのような技術系ユーザーは、こういうものを組み込んだ製品の主な対象ユーザーではない可能性が高い
    • スキップできて、後からもう一度できるなら問題ないと思う
      たいていスキップはできるが、アプリをきちんと学ぼうと思った後で再開する方法は、ほとんど見つけにくい
    • ユースケースによる。ユーザーをオンボーディングするとき、基本的な作業のやり方が分からないために来るサポートメールを減らせる
      また、メイン画面のスペースを占めるほどではないが要望のあった新機能を見せるのにも良い
      当たり前のことを指し示す時だけイライラする
    • たいていは悪い設計を補う松葉杖のように感じるが、製品によってはどうしても複雑さがある
    • UI の文脈で、こういうものやアプリダウンロードのポップアップ、メーリングリストのポップアップ、さらにアプリダウンロード、ソーシャルメディアのフォロー、またアプリダウンロードのようなものを小言と呼ぶのを何度か見た。たぶん「くたばれ」と呼ぶには文字数が多すぎるからだろう
      役に立つものと敵対的なものの間にあるのは細い線ではなく、点滅灯とサイレンの付いた大きくはっきりした線だ

  • 製品ユーザーとしては製品ツアーが嫌いだが、製品開発者としては常にオープンソースの代替を望んでいる
    このライブラリは効果が滑らかに見えてかなり良い
    個人的にいくつかの製品を作って見てきた限りでは、最もよく設計された製品ツアーでさえ、中小企業向け・コンシューマー向け製品では 90% ほどが閉じられてしまう

  • こういう機能は少しは好きだ
    新規ユーザーに強制せず、ツアーを見るか尋ねればいい
    アプリに新機能、ボタン、変更点が追加されたときだけ控えめに使い、セッションごとに一度だけ表示し、プロンプトは「閉じる/ツアーを見る」の選択肢だと良い
    アプリのユーザー体験が直感的である方が望ましいが、強制しないツアーは役に立つことがある
    機能告知用のログイン中間画面よりはましだ

    • どうか、まともなドキュメントとツアーを再実行できる機会を含むヘルプメニューをどこかに用意してほしい
      多くのデザイナーは、私がアプリを開く時に「今日はこの素敵な人たちがどんな楽しみを用意してくれたのかな？」と考え、時間を持て余していると思っているようだ
      実際には、今すぐ特定の作業を終わらせるためにアプリを開く場合がほとんどで、その瞬間は誰かが自分のプロダクトという子どもの写真を押し付けてきて「ええ、本当にかわいいですね」と言わせるのに最も向いていない時だ
      私が実際にツアーに前向きなのは、作業を終えた後か、やろうとしていることをどうすればよいのか分からないと気づいた直後だ

  • 製品ツアーが常に悪いわけではないが、ユーザーに意味のないステップが多すぎて実装が拙いことがよくある
    埋め込み型のヒントのように文脈に合っているもの、ペルソナ別のカスタムオンボーディングのように関連性があるもの、チェックリストのように行動志向のオンボーディングの方が概して良い
    Dropbox でオンボーディングとアプリ内教育チームを率いた後に Dopt [0] を始めた。これはツアーだけでなく、埋め込み型ヒントやチェックリストのような、より文脈的で邪魔になりにくいオンボーディング体験を簡単に作るための React コンポーネントライブラリと SDK だ
    Dopt では、必要なら新機能紹介用の 2 ステップツアーのようなものも作れるが、あらゆる種類のオンボーディングと教育のために、より大きく優れたツールボックスを提供したい
    [0] https://dopt.com/

    • なぜウェブサイトでクッキーを収集する必要があるのか気になる。最初に出くわすのがクッキー通知画面なので、何を追跡しているのか疑問に思う
      それから「Hybrid work」も気になる
      表面上は事前に明示しているのは良いが、100% リモート勤務の方が生産性の高い従業員につながるという研究[0]がある状況で、なぜハイブリッドを解決策として選んだのか気になる
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • 良さそう。Shepherd[0] と比べて何が違うのか？
    [0]: https://github.com/shipshapecode/shepherd

  • こういうタイプのツアーの問題は、短時間にあまりに多くの情報を目の前に突きつけて、そのまま消えてしまうことにある
    数分後、ユーザーは「このエリアは何をするところだったっけ？」と尋ねることになる
    以前ドローン操縦プラットフォームを作っていたときに使ってみたが、ダッシュボードが複雑で、どのエリアが操縦用で、どのエリアが映像フィード用なのか、クリックする前に知っておく必要があった
    ところがユーザーは読まずにうなずいて「次へ」ばかり押しがちで、結局それを削除し、各エリアに 情報アイコン を付けて、マウスオーバーすると説明を見られるように変えた

  • Redux アプリで似たようなことをするために https://github.com/Evernote/Aquaman ライブラリを作った。React context 向けにも同じものを作ったが、オープンソースとしては公開されていない
    ここで抜けている点は、1) アプリの状態がガイド付きツアーをトリガーする必要があるかもしれないこと、2) いずれは 複数ステップのフロー が必要になる可能性が高いこと、3) そのフローの状態変更ロジックはレンダリングロジックから分離されているべきだということ
    フローのすべてのステップは一緒にまとまっている必要がある。Aquaman ではそれを実現できた

  • ユーザーとしては嫌いだが、開発者としては プロダクトチームの要求 を満たすのに便利なライブラリだ

  • 今日、別の製品向けに Walnut.io [1] のデモを見たが、ほとんど飛ばしてしまい、その製品についてもほとんど理解できなかった
    ツールそのものより、プロダクトツアーの構成を誰がどのように行うかにかかっていると思う
    製品によっては複雑で、説明やソリューションエンジニア、アカウント担当者の案内が必要な場合もある。ヘルプやプロダクトツアーがまったく不要なほど驚異的な製品などない
    [1] https://walnut.io