アプリのスレッドディスカッションUI
私が開発しているシステムでは、顧客のメモを管理するためのUIを作成する必要があります。顧客メモは、顧客サービス担当者が書き込む顧客に関連するテキストのメモです。たとえば、メモは次のようになります。
このお客様は早朝に電話をかけたくないので注意してください。コールバックが必要な場合は、午後に行います。
また、メモを「返信」することもできます。次に例を示します。
注1（カスタマーサービス担当者が作成）：
顧客は注文を受け取りませんでしたが、どうなりましたか？
注2（カスタマーサービス担当者bが作成）：
顧客が間違った住所を入力したことが判明
注3（カスタマーサービス担当者aが作成）：
私は顧客に電話して、彼女に彼女の住所を尋ねました。今はすべて良いはずです。
上記の例のように、応答は1レベルの深さしかありません。
これを提示する私の考えは次のとおりです。
すべてのメモ（各メモに関するメタデータを含む）を表示する1つの大きなグリッドを用意します。上記の例のように、同じ返信チェーンの一部であるメモは、グリッド内で隣同士に表示され、返信チェーンの最新のメモが上部に表示されます。返信チェーンの各メモが「接続されている」ことを伝えるために、以下の画像のように、返信チェーンの各メモの左端の列が同じ色になるようにしたいと思います。これは良い考えですか？したがって、グリッドをスクロールすると、どのノートが関連していて、どのノートが関連していないかをすぐに理解できます。 
ちなみに、これはレガシーフレームワークで作成されたデスクトップアプリケーションで、あまり機能しません。だから、派手すぎるものを提案しないでください。
1つのスレッド内で2つの異なるタイプの情報（メタ情報、メッセージ、メタ情報、メッセージ、メタ情報、メッセージなど）を混在させます。メタ情報での作業もメッセージでの作業も適切ではありません。
次のことを検討してください。
1つのメッセージに関連するすべてを1行/行に入れます。例えば：
Subject | Customer Service rep | Date | Message
または
Message | Subject | Customer Service rep | Date
次に、smbがメッセージフローのみに関心がある場合、1つの列を読み取ります。 smbが日付（たとえば、顧客の要求を解決するのにかかった時間など）に関心がある場合は、別の列に焦点を当てます。誰にとっても読みやすく、調べやすくなります。
これらの種類の問題を「メモ」で解決することは、アイテムが開いているか閉じているかが決定的な解決策である「ケース」を使用するよりも望ましくありません。あなたがそのようなことをすることができないと仮定して、私はこのようなことを試みます： 
ここでは、件名が最初にリストされ、連続するノートで同じである場合は繰り返されません。スレッドが長すぎる場合は、デフォルトで古いメッセージを非表示にして、ユーザーがクリックして詳細を表示できるようにすることができます。
複数の理由から、色だけでスレッドを定義することは避けます。
- アクセシビリティ-ユーザーはそれらを区別できない場合があります。
- より多くの作業-使用する色と、それらが何かを意味するかどうかを考える必要があります
- 余分な重量-おそらく画面に多くの情報が表示されますが、これは最も重要なことではありません。できれば明るい色で強調することは避けます。
さらに、実際の日付の代わりに「メモからの日数」を使用することを検討します（ただし、日付をロールオーバーした場合でも、誰かが日付を確認できるようにします）。私の経験では、エージェントは主にこれをとにかく精神的に計算しようとします。私たちが彼らのためにそれをするなら、それは彼らがより速く働くのを助けます。