そのため、前の記事で、製品内のメッセージの操作を開始しました。これにより、ユーザーが最も頻繁に目にするエラーや警告をすばやく正確に見つけることができます。 特に、タイムアウトや[キャンセル]ボタンの悪用など、コマンドでは再現が難しい問題をキャッチして修正できます。 同じ記事で、ユーザーが技術サポートに連絡する前に問題の解決策をユーザーに伝える方法について説明します-これは、既存のメッセージレジストリ、ナレッジベース、GUIの1つの小さな変更だけで十分です。
ポイント1：メッセージレジストリを完成させています
参加者：アナリスト、チーフナレッジベース。
前回メッセージレジストリを構築し、現在、すべてのAPP_ERRおよびAPP_WARNがExcelで整然とした行に配置されているとします。 各メッセージに対して、yourdomain.com / app_err_1以降の形式のリンクを生成します。 次に、ナレッジベースの責任者を見つけて、彼に何を提供できるか尋ねます。 当社の慣例が示しているように、メッセージの約70％は、テクニカルサポートコールに基づいて作成された既存の記事によって閉じられています。 残りについて考える必要がありますが、原則として、警告またはエラーごとに言いたいことがあります。
そのため、コンテキストの簡単な説明と新しいリンク（関連記事へのリンク）を含む別の列がメッセージのリストに追加されます。
ポイント2：実装
参加者：アナリスト、製品プログラマー、Webサーバーマスター。
両方のリンクのセットを実行する時間。 それらの1つであるyourdomain.com/app_err_1は、製品からの実際のメッセージに挿入されます-たとえば、「続きを読む」または「問題の解決を手伝ってください」という言葉の下。 2番目のセット-記事への実際のリンク-は、最初のリダイレクトとして機能し、その下にはサーバー上に実際のページがありません。
なぜこれをやっているのですか
ユーザーのいずれかが、冬の夜に何かをするためだけに、知識ベースから楽しい記事を読むことを決定することはまずありません。 原則として、何かがすでに起こっているか、または理解できない場合、技術文書が役立ちます。 何が起こったのかという文脈で直接記事へのリンクを提供し、不必要な努力なしに何が起こっているのかを人が理解するのを助け、最初に知識ベースを探し、次に知識ベースを探します。 さらに、特定のメッセージごとに記事を選択することで、既存のソリューションから最適なソリューションにユーザーを誘導できます。
どうしてこんな風にやるの
2つのリンクとそれらの間のリダイレクトを備えたシステムは、GUI、つまりアセンブリ、リリース、ローカリゼーション、その他の低速なものへのバインドを完全に解放します。 必要な記事が動的に添付される静的リンクのセットをインターフェイスに保持する方がはるかに簡単です。
同じシステムは、緊急通知にも最適です。 プログラム内の何かがうまくいかず、世界中の100万人のユーザーが毎日エラー番号125を受け取った場合、Webサーバーで1つのコマンドを実行すると、yourdomain.com / app_err_125の修復手順が記載された新しい記事が送られ、テクニカルサポートは安心してため息をつきます。 問題が解消されると、Webサーバー上の別のコマンドがリンクの下にあるおなじみのメイン記事を返します。
その他
そのようなシステムの使用は、それに関連する記事をかなり綿密に監視することを意味します：彼らは自動的に最も訪問者に変わるので、可能な限りあらゆる形でそれらを良い状態に保ち、更新し、磨き、入れた方が良いでしょう。 しかし、同じシステムがこれを行うのに役立ちます。 ほとんどすべてのテクニカルサポートプログラムでは、ナレッジベースの記事をユーザーのアプリケーションに関連付けることができます。 特定の記事に関連付けられているアプリケーションを確認すると、この状況でユーザーがテクニカルサポートにアクセスした方法と理由を理解できます。リンクに気付かなかったのですか？ 説明したソリューションを適用できませんでしたか？ うまくいかなかった？ -そしてすぐに行動を起こしてください。
したがって、わずかな1回の努力で、プログラマーからユーザーまで、プロセスのすべての参加者は、多くの時間、お金、神経を節約でき、多くの有益な結論を自分自身に与えることができます。