コンテキスト
Discourseチームは、いくつかの場面で管理者エクスペリエンスの改善を模索していることを明言しています。
問題
Discourseには設定が多数あり、ドキュメントも膨大です。しかし、必要な瞬間に適切なドキュメントを見つけることは難しいでしょう。
機能提案
Discourseの設定やメニューにおいて、対応するドキュメント（Documentation - Discourse Meta ）へのリンクが貼られる場所をさらに増やすことができます。
例えば、Discourseのインストール時には、Understanding Discourse Trust Levels というブログ記事へのリンクが貼られています。
しかし、リンクされていないドキュメントもたくさんあります。
例えば、カテゴリの削除方法に関するガイドがあります。
カテゴリ削除ボタンが表示されるモーダル画面にこの情報を関連付けたり、役に立つ形で含めると考えられます。
単なるリンクであっても構いませんが、ケースによってはリンクだけでなく、ドキュメントへのリンクを示す「？」ボタンや、「続きを読む…」などの表記にすることも可能です。
Discourseチームは、主要なドキュメントから順にドキュメントを閲覧し、ソフトウェア内のどこにそのドキュメントへのリンクを貼るのが最も適切かを探り出すことができます。
（つまり「ジャストインタイム」です）
他のソフトウェアの例
オープンソースのブログソフトウェアであるGhostでは、必要な場面でドキュメントへのリンクが提供されています。
例えば、この「詳細を見る」ボタンは関連するドキュメントにリンクしています：
こちらの場合も同様です：
この提案が Contribute > Feature か Contribute > UX のどちらに該当するかは明確ではありませんが、適宜移動していただければ幸いです。
「いいね！」 5
それには少し同意しかねます。作成できるヘルプコンテンツにはさまざまなスコープがあります。Diátaxisモデルに従うと、チュートリアル、ハウツーガイド、リファレンス、説明があります。
チュートリアルはおそらくアプリ自体にリンクする場所があり、たとえば「これがどのように機能するかを学びたい」という意図でページに入った場合、そのページが自己説明的でなくても学ぶことができます。ソフトウェアのコースを完了できるチュートリアルセンターさえあるかもしれません。
他の3つのカテゴリについては、少し問題があります。
カテゴリ設定ページにアクセスすると、20個の異なる操作を行いたい場合があります。そこにハウツーガイドを配置すると、検索する必要のあるリストになり、探しているものが必ずしも専用のハウツー記事になるとは限らないという期待があるため、リストを検索するのではなく、Googleでその質問を入力する可能性が高いです。
オフサイトのリファレンスは、私が毎日対処しなければならない厄介なものです。「リファレンスマニュアル」があり、スライダーやボタンの各機能が次のように説明されています。
キャンセルボタン: 変更を適用せずにダイアログを閉じます。
OKボタン: 変更を適用してダイアログを閉じます。
このリファレンスを使用すると、セクションに到達する前に多くの技術的な内容をスクロールする必要があり、実際には数語でオプションを言い換えるツールチップが必要だったのに、ということになります。
カテゴリを削除しようとすると、現在の動作はほぼ望ましいものです。ボタンが表示され、通常はグレー表示されていますが、疑問符が付いており、クリックすると次のように表示されます。
このカテゴリはサブカテゴリがあるため削除できません。
または：
このカテゴリには25852個のトピックがあるため削除できません。最も古いトピックは…
動作は良好で、何が問題で、次のステップは何かがわかります。投稿やサブカテゴリを大量に削除する必要があります。「カテゴリを削除する」ハウツーガイドをアプリにリンクしても改善されません。
もちろん、これは根本的な問題に対する応急処置にすぎません。なぜ投稿が含まれているカテゴリを削除できないのでしょうか？ システム上のサブフォルダやファイルを含むフォルダを削除できますが、サブカテゴリや投稿を含むカテゴリを削除できないのはなぜですか？これらの奇妙な制限がなければ、そもそもアプリにハウツーガイドが必要になることはありません。
そして最後に、説明です。これは「信頼レベルの理解」というブログ記事です。初めてこれに出会ったとき、それはかなり混乱していました。「6年前のランダムなブログ記事が、あなたが持っている最高のドキュメントなのですか？」そして、それはリファレンス記事にリンクされており、すべてをテーブルにリストアップしていますが、これは私が期待していたもの（ただし、期待していた方法では並んでいませんでした）に近かったです。説明はタスクを直接理解するのに役立たないため、タスクが完了する場所に配置してもあまりうまくいきません。
最終的に、ドキュメントはいくつかの場所（たとえば、オンボーディングやデザインが失敗した場合）で重要ですが、主にデザインに焦点を当てるべきだと思います。誰かがウェブサイトを説明するのを読んだりビデオを見たりすることは、めったに望ましい経験ではありません。
「いいね！」 5
はい、過去にゲームデザインを学んだ者として、私も心から同意します。（あなたはAudacityのデザイナーだと記憶しています。ちなみにAudacityはよく使っており、大変感謝しています！）
また、すべてのユースケースにおいて、「管理者は何をしたいのか、それをどのように最もよく支援できるか？」という考えから始めて、全体的なエクスペリエンスをゼロから再考する必要があると思います。これにより、プロセスがよりよく伝えられるだけでなく、プロセス自体も可能な限りわかりやすくなるでしょう。
例として挙げられた、トピックが含まれているカテゴリを削除できないという件について、ソフトウェアがそれを処理するより洗練された方法としては、次のようなものが考えられます。トピックが含まれているカテゴリを削除しようとしたときに、まず次のような提案をする可能性があります。
- すべての既存トピックを別のカテゴリに移動する、または
- すべての既存トピックを「未分類」に入れる、または
- カテゴリ内のすべてのトピックを削除する
その後、カテゴリを削除してもよいか確認する。
Discourseチームがこの段階でより段階的な変更を目指していることを考えると：
私は、最も人気のある/一般的な/主要なドキュメントに、最も関連性の高い場所へのリンクを追加するという、より簡単な解決策を求めていました。
（カテゴリ削除体験の改善についてここで話し合ったフィードバック/提案については、後で新しいトピックを作成するかもしれません。）
hugh
(Hugh Lashbrooke)
5
この提案はとても気に入りました。@bloomexperiment さん、取り上げていただきありがとうございます！現在、ドキュメントの一般的な構造と分類の改善に取り組んでおり、この種の機能もそのプロセスの一部として検討する価値があると思います。ドキュメントのロードマップに追加して、どのように実装するのが最善か検討します。
「いいね！」 2
古いトピックを復活させてしまい申し訳ありません。また、現在行われている管理検索や全体的な管理エクスペリエンスの改善についても十分に認識しています。ここ数週間、サイト設定の各名前がMetaの関連ドキュメントトピックへのリンクになっていればと何度も思いました。過去数年間、Metaのドキュメントは大幅に改善され、現在では非常に包括的で、整理されており、有益です。
例：
上記の例では、「Backup location」が Configure automatic backups for Discourse のようなMetaトピックにリンクすることを望みます。
これらのサイト設定名のそれぞれが、関連するMetaスレッドにリンクする段階に徐々に近づくことは可能でしょうか？DiscourseのコードにURLをハードコーディングしたくないかもしれませんが、サイトテキストなどに含めることは可能だと思います。
これらのリンクをすべて行う作業はかなり大きいですが、セルフホストユーザーの間でクラウドソーシングされた取り組みが可能かもしれません。
「いいね！」 3
