スレッド、または文字のチェーンは、Mail.Ru Mailで常に最も望ましい機能の1つです。ただし、「どの機能が欠けていますか？」という調査は、上級者（プログラマやhabrayuzerなど）の間で行われました。 オタクの間で2番目に人気のある機能は、おそらく2要素認証ですが、それについては別の記事で説明します。



ただし、すべてのユーザビリティテストでは、それほど高度ではないユーザーにとって、スレッドはかなり複雑であり、必ずしも便利な機能ではないことが示されました。 多くの人は、受信ボックスで文字を「失う」ことを恐れ、チェーン内の特定のメッセージへの応答方法などを理解できませんでした。



それにもかかわらず、私たち自身（Mail.Ru Mailチーム）にとって、最初のグループ（オタク、生産性バフ、プログラマー）に属する人々として、スレッドのアイデアは密接かつ明確でした。 そのため、高度なコミュニティの要望に応えて、オプションモードでスレッドを実装することにしました（文字のリストの右上隅にある[表示]メニューで有効にできます）。







ただし、解決は簡単ですが、それほど簡単ではありません。 論理を通して考える段階で、多くのニュアンスが明らかになりました。 スレッドはすでに他のメールサービスに実装されていますが、独自のアルゴリズムを開発する必要がありました。 第一に、一部の外国のソリューションは間違っているように思われたため、修正することにしました。第二に、メールの一部の基本機能のロジックが他の類似機能の動作と異なるため、単に「エクスペリエンスを採用」することは不可能です。



この投稿では、どのような困難が私たちを待っていたのか、どうやってそれを克服したのかについてお話したいと思います。

1.スレッドを「接着」する方法

1.1返信先を理解する



各文字にはメタ情報（サービスヘッダー）があります。 In-Reply-Toヘッダーは、開いたメッセージ（In-Reply-To）に対するメッセージの応答を示し、Referencesには、とりわけ、通信の最初の文字に関する情報が含まれます。 このようなサービスヘッダーがある場合は、これらのヘッダーで文字をグループ化するのが理にかなっています。 ただし、考慮しなければならない2つのニュアンスがあります。



最初：リダイレクトされた文字をどうするか？ 着信メッセージがリダイレクトされる場合、実際には、In-Reply-Toサービスヘッダーを持つ別のメッセージが表示されます。 このヘッダーは、転送された電子メールを示します。 この場合、接頭辞FWまたはFWDが件名に表示されます。 つまり、実際には、フォワードは別の答えです。 たとえば、Gmailは、このロジックに基づいて、メッセージを同じスレッドにリダイレクトします。



Mail.Ruの内部と外部のユーザーにインタビューを行った結果、原則として、ユーザーを通信に接続するのではなく、通信のトピックについてユーザーと個別に話し合うために手紙を送信することがわかりました。 だから-彼らは新しい「会話」を始めたいと思っており、古いままではありません。 したがって、そのような場合は新しいチェーンを開始することにしました。







第二に、時々、人々は、件名を手動で変更することにより、手紙に返信することができます。 その後、サービスのレターの見出しは正式にIn-Reply-Toとマークされたままになりますが、レターの件名は変わります。 私たちの研究の結果に焦点を当てて、人々が意識的に手紙の件名を変更すると、これは彼らにとっての新しいチェーンであることに気づき、そのような場合、サービスヘッダーにIn-Reply-Toが存在しても、別のスレッドも作成することを決定しました。



これら2つのニュアンスに基づいて、グループ化アルゴリズムは次のようになります。

• トピックを正規化します。たとえば、すべてのプレフィックス「Re」を捨てますが、「FWD」はそのままにします
• ヘッダーと1つの正規化された主題に関連するグループ文字

1.2自動郵送のグループ化について考える



見出しがない場合、グループ化するものがないという意味ではありません。 ソーシャルネットワークからの通知、オンラインストアからのプロモーションレター、タスクトラッカーからのレター、最後に、1つのグループで尋ねるだけの手紙がたくさんあります。 原則として、これらすべての場合において、手紙には1つの件名と1つの送信者がいます。 そのため、自動メールをカバーするために、「件名+送信者」の基準に従ってヘッダーのない文字をグループ化することにしました。







1.3「バスケット」を分離する



スレッドを実装するときの別の問題は、メールフォルダ構造によって作成されます。 「送信済みアイテム」を含むさまざまなフォルダからの手紙が1つのチェーンに分類され、到着した手紙とそれらへの回答の両方を1か所で見ることができると判断しました。 そこには、理論上、「バスケット」フォルダからの手紙も含まれているはずです。 最初は、このロジックに導かれましたが、最初のベータテスターは、それが不便であり、受信トレイフォルダー内の文字でグループ化できたとしても、削除された文字を見たくないというフィードバックを私たちに与えました。



1.4メーターの測定値によって決定



既に述べたように、1つのチェーンから文字をグループ化する場合、それらは異なるフォルダーに散らばることができます（最も単純なケースは「Inbox」と「Sent」です）。 これに関して、たとえば次のような多くの質問が発生します。

• 会話が読まれていない場合、すべてのフォルダーで未読のままですか？
• 会話に複数の未読メッセージがある場合、カウンターは何を表示する必要がありますか-未読メッセージの数または1つの未読の会話？

3つのオプションがあります。 それらを見てみましょう。



最初：カウンターは会話で機能し、未読の会話は表示されているすべてのフォルダーでマークされます。 たとえば、「受信トレイ」と「送信済み」の2つのフォルダに、ボックスに届いた未読の手紙が1つあります。 フォルダーのリストでは、これら2つのフォルダーのそれぞれに1つずつ表示されます。 しかし、ボックスの一般的なカウンターに何を表示しますか？ 理論的には、すべてのフォルダーの合計を表示する必要がありますが、この場合は2つです。 しかし、実際には、ボックス内に未読のチェーンが1つあります！



2番目のオプション：フォルダー内のスレッドは、フォルダー内のこのスレッドからの未読メッセージがある場合にのみ、未読と見なされます。 しかし、スレッドに未読の手紙が2つあるとします。 フォルダカウンタには1つが表示されます。1つのスレッドが読み取られていません。 ユーザーはスレッドを開き、先頭の文字を読み、その後、文字のリストに戻ります。 1つの文字が読み取られましたが、カウンターにはまだ1つが表示されています。結局、スレッドには別の未読の文字があります。つまり、スレッド全体が読み取られていないことを意味します。 ユーザーがアクションを実行し、カウンターの読み取り値は変更されていません。



選択した3番目のオプション：カウンターでは、スレッドではなく文字を考慮します。 この場合、レターを複数のフォルダーに入れることはできないため、各フォルダーのカウンターには正しいデータが表示されます。 また、合計カウンターには常に正しい数が表示されます。 この場合のインターフェースは、カウンターを変更することにより、文字の読み取りに応答します。







要約すると：

• ヘッダーと件名、または送信者と件名でスレッドを接着します
• 転送された手紙は新しいスレッドを開始します
• スレッドには、「ごみ箱」を除くすべてのフォルダからの手紙が含まれます
• フォルダカウンタには、スレッドではなく、未読の文字の数が表示されます

2.スレッドの外観とそれに伴うアクション

2.1 3つのレベルまたは2つ？



基本的に市場には2種類の表示スレッドがあります。



まず、スレッドリストでスレッドをクリックすると、別のリストが開きます。今回は特定の文字を読むために、もう一度クリックする必要があります。 便宜上、「3レベル」と呼びました。 ところで、Outlookの一部のバージョンから多数のモバイルメールクライアントまで、多くの場所で使用されています。



2番目（別名「2レベル」）-ユーザーがスレッドのリストからクリックすると、ユーザーはすぐに文字の「本文」に到達します。 通信の実際の内容に素早く到達する能力を持っています。



ユーザーのコンテンツに邪魔されず、新しく届いた手紙を読みたいときに毎回2回クリックすることを強制しないことにしました。 ご想像のとおり、「2層」オプションが選択されました。 彼は技術的およびイデオロギー的にはるかに多くの問題を予兆していましたが、それらについてはもう少し先を行きました。



2.2スレッド内の既読および未読の手紙



ここで、私たちはな哲学をしないことを決めました-ユーザーがまず、まだ見たことがない文字の内容に慣れることに興味があることは明らかです。 その結果、彼らは彼らに強調される必要があります。 したがって、スレッド内で、すべての未読文字を展開し、すべての既読文字を折りたたんだままにすることにしました。



スレッドに未読の文字がない場合、最新の文字を展開したままにします（理由-後で詳しく説明します）。







2.3スレッドリスト内の読み取りスレッドと未読スレッド



最初に解決すべき問題は、少なくとも1つの未読文字がある場合、文字のリスト（現在はスレッドのリスト）でスレッドを未読にするかどうかでした。 スレッドを未読としてマークするとします。 ただし、同じスレッドの文字が異なるフォルダーにある場合（たとえば、一部が受信トレイにあり、一部が重要にある場合）、2つの問題が同時に発生します。 1つ目-スレッドを1つのフォルダーで既読にマークし、2つのフォルダーの未読メッセージのカウンターを一度に変更します。 第二-未読手紙の一般的なカウンターで何をすべきかは明確ではありません。 結局のところ、ユーザーがメールボックスに入ったときに、未読の手紙が一度に2つあることに気付き、最初のフォルダーでスレッドを開いて読み取り、両方のカウンターがゼロにリセットされると、2番目の未読の手紙が単に失われたと考えるでしょう。



このオプションを失敗として却下し、別の方法で試してみることにしました。ユーザーが未読メッセージを持っているフォルダーでのみスレッドを未読にします。 たとえば、スレッドの文字は受信トレイと重要の間で分散され、未読の文字のみが重要になります。 つまり、ユーザーが受信トレイ（未読の電子メールがない場所）にいる場合、すべてのスレッドが既読としてマークされます。



ただし、ここで別の小さな問題が発生しました-ユーザーがInboxからスレッドを開くと、すでに内部に詳細な未読の手紙（「重要」にあるもの）があることがわかります。 少し非論理的です。



この問題を次のように修正することにしました。スレッド内の他のフォルダーの文字も、読み取られていなくてもヘッダーの状態に折りたたまれます。 そのため、スレッドに入ると、ユーザーにはこのフォルダから展開された未読メッセージのみが表示されます。 したがって、不必要な情報はなく、自分自身を思い出させるはずの「偶発的な」測定値もありません（別のフォルダーへの並べ替えが設定されたことは何もありませんでした）。



ただし、公平を期すために、同じスレッドからの文字が別のフォルダーにある場合（当然、送信済みのフォルダーはカウントしません）は非常にまれです。 そしてこれはいいです！



2.4スレッドの削除



同時に、もう1つの質問に対する答えを見つける必要がありました。 状況を想像してください。Inboxフォルダーにいて、1つの文字がInboxフォルダーから、2番目がSent Itemsフォルダーからのスレッドを開きます。 [スレッドの削除]をクリックすると、[送信済み]からの手紙はどうなりますか？ ユーザーへのインタビューの結果、メッセージは送信済みアイテムフォルダーに残ることを期待しています。 したがって、スレッドに関するすべてのアクション（削除、移動など）があります。 -ユーザーが開いたフォルダからの手紙にのみ適用されます。



2.5スレッド内の新しい文字の位置



解決する必要がある別の重要な質問：チェーンの上部または下部に最新の文字を表示しますか？ 従来のメールが機能する原則、つまりスレッドの上部に最新の文字を表示するという原則を維持することにしました（たとえば、Gmailの場合、スレッドの下部に新しい文字が表示されます）。



さらに、私たちの調査では、スレッド内の残りの文字を読むかどうかを理解するために、多くのユーザーが最後の文字からスレッドを読み始めることが示されています。 これは、新しい文字を上に表示することを支持する別の議論でした。



2.6ツールバーの機能



また、スレッド全体に関連して、「返信」ボタンのあるツールバーの動作を決定する必要がありました。 2つのオプションから選択しました。答えを切り、スレッドの最後の文字、またはユーザーの画面に現在表示されている文字に関連して転送します。 その結果、最初のオプションに決着しました。現在画面に表示されている文字のオプションが不確実性を過剰に導入したためです。たとえば、画面に2文字または3文字の短い文字が同時にある場合の対処方法 または、どの文字に今答えるかを直感的にユーザーに伝える方法は？



ところで、それが、スレッドの最後の文字が読み取られているかどうかに関係なく、常に展開される理由です。 ユーザーが他の文字に返信したい場合は、スレッド内に小さな追加のツールバーを作成し、これを可能にしました。







要約すると：

• 現在のフォルダーからの最新の文字は常に展開されます
• 他のフォルダからの文字はステータスに関係なく最小化されます
• 現在のフォルダーの文字は、読み取られた場合にのみ最小化されます
• スレッドを削除するとき、現在のフォルダーから文字のみを削除します
• 最新の文字を上に表示します
• スレッドの上部の表のボタンは、上部の文字で機能します

***



メールでのスレッドの実装はかなり難しいタスクであり、その解決のために多くの時間と労力を費やしました。 これで、すべてのMail.Ruメールボックスでスレッドを有効にできます。



コメントで、更新されたインターフェイスを使用するのがいかに便利であるか、また、選択した決定が論理的と思われるかどうかを教えていただければ幸いです。