ヘルプシステムの設計

Question

デスクトップアプリ（Win32）のヘルプシステムを実装していて、それを設計する方法を探しています。

ヘルプシステムにはどのような構造が必要ですか、ユーザーにとって実際に役立つものは何ですか？ 例えばヘルプシステムはFAQの大きなリストである必要がありますか（Office 2010のヘルプはこのように見えます）？または、すべてが何をするのかを文書化して説明する機能リストである必要があります（これは、ユーザーがすでに知っている機能がどのように機能するかわからない場合にのみ役立つ可能性があります）

エンドユーザーにどのような知識を期待する必要がありますか？File-> Open Projectが現在のプロジェクト（存在する場合）を閉じ、既存のプロジェクトを開くというヘルプファイルに書き込むのはおそらく少し意味がありません。

ここで私が探しているのは、いくつかのガイド、優れたヘルプシステムに必要な一連の機能、およびユーザーがトピックを見つけられるようにトピックを整理する方法です。

Answer 1

「プロジェクトを開く」は、プロジェクトの定義、およびプロジェクトの開始に関連するその他のより一般的な説明と手順を参照するのに適した場所でもあります。

一般に、CHMヘルプには、状況依存ヘルプ（file-> openの場合に一般的）と、一般的な目次、全文検索、およびインデックスのいずれかを介してアクセスします。最近のアプリは、コンテナごとに1つのヘルプページ（ダイアログ、またはプルドーンメニュー）のみを作成しているようです。ここでは、画面上のすべてのアイテム（注釈付きのスクリーンショットなど）が一覧表示され、各アイテム（チェックボックス、メニューエントリ）の補題は表示されません。 GUI。煩雑さやナビゲーションが少なく、多くのポイントで必要なのはかなり短い説明だけです

状況依存ヘルプに加えて、ヘルプシステムを介してヘルプを閲覧することもできます。

CHMは、目次（TOC）、索引、およびオプションで全文検索のサポートを備えた、電子書籍にかなり似ています。

インデックスと全文検索は、ユーザーがコンテンツを検索するための方法です。 主な違いは、インデックスがより管理されており、有効にすると全文検索がほぼ自動的に行われることです。

TOCは、本のTOCのように機能するノードのツリービューであり、「電子書籍」の一般的な構造を固定する必要があります。 FAQは通常、この目次の付録です。

これに加えて、ウェブサイトのホームページのようなデフォルトの「エントリ」ページがあります。ユーザーを最も一般的に検索されるトピックにナビゲートする必要があります。

マイクロソフト製品と比較して注意してください。エンドユーザー/開発者がまだ利用できないシステムを使用することもあります。

グッドヘルプはこれらすべての要素を使用します。

Answer 2

ヘルプには大きく2つのスタイルがあります。参照ベース（つまり、このチェックボックスはどういう意味ですか？）とタスクベース（XYZを実現するにはどうすればよいですか？）です。

最初にタスクベースのチュートリアルを作成し、必要に応じてFAQでバックアップすることをお勧めします。