Metaの関連ドキュメントへのリンクをDiscourse全体にもっと含める

コンテキスト

Discourse チームは、管理エクスペリエンスの改善を求めていることをいくつかの場所で言及しています。

問題

Discourse には多くの設定と多くのドキュメントがありますが、適切なドキュメントを適切なタイミングで見つけることは難しいでしょう。

機能

Discourse の設定やメニューの多くの場所に、対応するドキュメントへのリンクを https://meta.discourse.org/docs に追加できる可能性があります。

たとえば、Discourse インストールにリンクされている Understanding Discourse Trust Levels のブログ投稿があります。

しかし、それ以外にも多くのものがあります。

たとえば、カテゴリを削除する方法があります。

カテゴリ削除ボタンが表示されるモーダルに含めると、関連性があり便利だと思われます。

リンクでも構いませんが、各ケースでリンクである必要はありません。ドキュメントにリンクする疑問符ボタンにすることも、「続きを読む…」などにすることもできます。

Discourse チームは、ドキュメントを主要なものから始めて閲覧し、ソフトウェアのどこにそのドキュメントをリンクするのが最も適切かを判断できます。

(別名「ジャストインタイム」)

他のソフトウェアの例

Ghost(オープンソースのブログソフトウェア)には、必要なときにドキュメントにリンクされている場所がいくつかあります。

たとえば、この「詳細はこちら」ボタンは関連ドキュメントにリンクされています。

ここでも同様です。

これが Feature または UX に該当するかどうか確信が持てなかったので、必要に応じて移動してください。

「いいね!」 5

それには少し同意しかねます。作成できるヘルプコンテンツにはさまざまなスコープがあります。Diátaxisモデルに従うと、チュートリアル、ハウツーガイド、リファレンス、説明があります。

チュートリアルはおそらくアプリ自体にリンクする場所があり、たとえば「これがどのように機能するかを学びたい」という意図でページに入った場合、そのページが自己説明的でなくても学ぶことができます。ソフトウェアのコースを完了できるチュートリアルセンターさえあるかもしれません。

他の3つのカテゴリについては、少し問題があります。

カテゴリ設定ページにアクセスすると、20個の異なる操作を行いたい場合があります。そこにハウツーガイドを配置すると、検索する必要のあるリストになり、探しているものが必ずしも専用のハウツー記事になるとは限らないという期待があるため、リストを検索するのではなく、Googleでその質問を入力する可能性が高いです。

オフサイトのリファレンスは、私が毎日対処しなければならない厄介なものです。「リファレンスマニュアル」があり、スライダーやボタンの各機能が次のように説明されています。

キャンセルボタン: 変更を適用せずにダイアログを閉じます。
OKボタン: 変更を適用してダイアログを閉じます。

このリファレンスを使用すると、セクションに到達する前に多くの技術的な内容をスクロールする必要があり、実際には数語でオプションを言い換えるツールチップが必要だったのに、ということになります。

カテゴリを削除しようとすると、現在の動作はほぼ望ましいものです。ボタンが表示され、通常はグレー表示されていますが、疑問符が付いており、クリックすると次のように表示されます。

このカテゴリはサブカテゴリがあるため削除できません。

または:

このカテゴリには25852個のトピックがあるため削除できません。最も古いトピックは…

動作は良好で、何が問題で、次のステップは何かがわかります。投稿やサブカテゴリを大量に削除する必要があります。「カテゴリを削除する」ハウツーガイドをアプリにリンクしても改善されません。

もちろん、これは根本的な問題に対する応急処置にすぎません。なぜ投稿が含まれているカテゴリを削除できないのでしょうか? システム上のサブフォルダやファイルを含むフォルダを削除できますが、サブカテゴリや投稿を含むカテゴリを削除できないのはなぜですか?これらの奇妙な制限がなければ、そもそもアプリにハウツーガイドが必要になることはありません。

そして最後に、説明です。これは「信頼レベルの理解」というブログ記事です。初めてこれに出会ったとき、それはかなり混乱していました。「6年前のランダムなブログ記事が、あなたが持っている最高のドキュメントなのですか?」そして、それはリファレンス記事にリンクされており、すべてをテーブルにリストアップしていますが、これは私が期待していたもの(ただし、期待していた方法では並んでいませんでした)に近かったです。説明はタスクを直接理解するのに役立たないため、タスクが完了する場所に配置してもあまりうまくいきません。


最終的に、ドキュメントはいくつかの場所(たとえば、オンボーディングやデザインが失敗した場合)で重要ですが、主にデザインに焦点を当てるべきだと思います。誰かがウェブサイトを説明するのを読んだりビデオを見たりすることは、めったに望ましい経験ではありません。

「いいね!」 5

はい、過去にゲームデザインを学んだ者として、私も心から同意します。(あなたはAudacityのデザイナーだと記憶しています。ちなみにAudacityはよく使っており、大変感謝しています!)

また、すべてのユースケースにおいて、「管理者は何をしたいのか、それをどのように最もよく支援できるか?」という考えから始めて、全体的なエクスペリエンスをゼロから再考する必要があると思います。これにより、プロセスがよりよく伝えられるだけでなく、プロセス自体も可能な限りわかりやすくなるでしょう。

例として挙げられた、トピックが含まれているカテゴリを削除できないという件について、ソフトウェアがそれを処理するより洗練された方法としては、次のようなものが考えられます。トピックが含まれているカテゴリを削除しようとしたときに、まず次のような提案をする可能性があります。

  • すべての既存トピックを別のカテゴリに移動する、または
  • すべての既存トピックを「未分類」に入れる、または
  • カテゴリ内のすべてのトピックを削除する

その後、カテゴリを削除してもよいか確認する。

Discourseチームがこの段階でより段階的な変更を目指していることを考えると:

私は、最も人気のある/一般的な/主要なドキュメントに、最も関連性の高い場所へのリンクを追加するという、より簡単な解決策を求めていました。

(カテゴリ削除体験の改善についてここで話し合ったフィードバック/提案については、後で新しいトピックを作成するかもしれません。)

この提案はとても気に入りました。@bloomexperiment さん、取り上げていただきありがとうございます!現在、ドキュメントの一般的な構造と分類の改善に取り組んでおり、この種の機能もそのプロセスの一部として検討する価値があると思います。ドキュメントのロードマップに追加して、どのように実装するのが最善か検討します。

「いいね!」 2

古いトピックを復活させてしまい申し訳ありません。また、現在行われている管理検索や全体的な管理エクスペリエンスの改善についても十分に認識しています。ここ数週間、サイト設定の各名前がMetaの関連ドキュメントトピックへのリンクになっていればと何度も思いました。過去数年間、Metaのドキュメントは大幅に改善され、現在では非常に包括的で、整理されており、有益です。

例:

上記の例では、「Backup location」が Configure automatic backups for Discourse のようなMetaトピックにリンクすることを望みます。

これらのサイト設定名のそれぞれが、関連するMetaスレッドにリンクする段階に徐々に近づくことは可能でしょうか?DiscourseのコードにURLをハードコーディングしたくないかもしれませんが、サイトテキストなどに含めることは可能だと思います。

これらのリンクをすべて行う作業はかなり大きいですが、セルフホストユーザーの間でクラウドソーシングされた取り組みが可能かもしれません。

「いいね!」 3