How we taught Mail.Ru how to glue letters into threads
Threads, or chains of letters, have always been one of the most desirable features in Mail.Ru Mail, provided that the survey “What functionality are you missing?” Was conducted among an advanced audience (for example, among programmers or habrayusers). The second most popular feature among geeks is, perhaps, two-factor authentication, but about it in a separate post .
However, all our usability testing showed that for a less advanced audience, threads are a fairly complex feature and not always convenient. Many were horrified by “losing” their letters in the Inbox, they could not figure out how to respond to a specific message in the thread, and much more.
Nevertheless, by ourselves (Mail.Ru team of the Mail), as people belonging to the first group (geeks, production lovers and programmers), the idea of threads was close and clear. Therefore, we decided to meet the wishes of the advanced community and implement threads in an optional mode (you can turn them on in the “View” menu in the upper right corner above the list of letters).
')
However, it is easy to solve, but not so easy to do. At the stage of thinking through logic, a lot of nuances were discovered. Although the threads were already implemented in other postal services, we still had to develop our own algorithm. Firstly, some other people's decisions seemed to be erroneous, and we decided to correct them, and secondly, the logic of some basic functionality of our mail is different from the work of similar functionality in others, so it’s impossible to “learn from experience” as is.
In this post we want to talk about the difficulties that awaited us and how we managed to overcome them.
1.1 Understanding In-Reply-To
Each letter has meta-information (service headers). The In-Reply-To header indicates the answer to which letter the message you opened (In-Reply-To) is answered, and the References contains, among other things, information about the letter that was the first to correspond. It is logical that if there are such service headers, then it makes sense to group the letters by these headers. However, there are two nuances that we had to take into account.
First: how to deal with redirected letters? In the case when the incoming letter is redirected, in fact there is another letter with the service header In-Reply-To. This header indicates a redirected letter. At the same time in the subject appears prefix FW or FWD. That is, in fact, the forward is another answer. Guided by this logic, Gmail, for example, “sticks” redirected letters to the same thread.
We interviewed users inside Mail.Ru and outside and found out that, as a rule, they send a letter not in order to connect the person to the correspondence, but to discuss the topic of correspondence with him separately. So - they want to start a new "conversation", and not stay in the old. Therefore, we decided that in such cases we will start a new chain.
Second, sometimes people can reply to a letter by changing its subject manually. Then the In-Reply-To tag will formally remain in the service header of the letter, but the subject of the letter will change. Focusing on the results of our research, we realized that if people consciously change the subject of the letter, it means that this is a new chain for them, and decided that in such cases we will also create a separate thread, even though there is an In-Reply-To in the service header .
Based on these two nuances, the grouping algorithm should be as follows:
1.2 We consider grouping for automatic mailings.
If there are no headers, it does not mean that there is nothing to group. There are many letters that are asked in one group: notifications from social networks, promotional letters from online stores, letters from task tracker, finally. As a rule, in all these cases, the letters have one subject and one sender. Therefore, we decided to group letters with no headers by the “subject + sender” criterion in order to cover automatic mailings.
1.3 Separate the "basket"
A separate problem in the implementation of threads creates the folder structure of the Post. We decided that letters from different folders, including those from the “Sent One,” could be put in the same thread, so that you could see the received letters and the answers to them in one place. There, in theory, the letters from the “Trash” folder should have been included. Initially, we were guided by this logic, but the first beta testers gave us feedback that it was inconvenient and that they did not want to see deleted letters, even if they could be grouped by headings with a letter in the Inbox.
1.4 Determine meter readings
As we have already said, when grouping letters from one chain, they can be scattered in different folders (the simplest case is Inbox and Sent Mail). In this regard, a lot of questions arise, for example:
We have three options. Let's consider them.
The first: the counter works with chains, and the unread chain is marked in all the folders in which it is displayed. For example, in two folders - "Inbox" and "Sent" - there is one unread letter that has just arrived in the box. In the list of folders, we will see one in each of these two folders. But what to show in the general counter at the box? In theory, there it is necessary to display the amount for all folders, but in our case it is two. But after all actually one unread chain is in the box!
The second option: a thread in a folder is considered unread only if there are unread letters from this thread in the folder. But suppose there are two unread letters in the thread. Folder counter displays unit: one thread is not read. The user opens a thread and reads the top letter, after which he returns to the list of letters. One letter is read, but the counter still shows the unit: there is another unread letter in the thread, which means that the whole thread is not read. It turns out that the user performed the action, and the meter readings have not changed.
The third option, which we have chosen: in the meters we take into account letters, and not threads. In this case, the counter of each folder displays the correct data, because the letter can not be in several folders. The total counter also always displays the correct number. The interface in this case reacts to the reading of any letter by changing the meter readings.
We summarize:
2.1 Three levels or two?
There are two basic types of display threads on the market:
The first is when clicking on a thread in the list of threads, another list opens, this time already letters, where you have to click again to get to read a particular letter. For convenience, we called it "three-level." It is used, by the way, in many places - from some versions of Outlook to a large number of mobile email clients.
The second one (it’s also “two-level”) —when clicking from the list of threads, the user goes directly to the “bodies” of the letters, i.e. has the ability to quickly get to the actual content of the correspondence.
We decided not to stand in the way of the user to his content and not to force him to make two clicks every time he wants to read the newly received letter. As you already guessed, the “two-level” option was chosen. Although he technically and ideologically foreshadowed many more problems, but about them a little further.
2.2 Read and unread letters inside the thread
Here we decided not to philosophize slyly - it is obvious that the user is interested first of all to get acquainted with the content of those letters that he has not yet seen. And consequently, on them and need to focus his attention. Therefore, inside the thread, we decided to deploy all the unread letters, and leave all the reads folded.
If there are no unread letters in the thread, we leave the last one unrolled (why - more on that a little further).
2.3 Read and unread threads in the thread list
The first question that had to be resolved was: should the thread be marked unread in the list of letters (now in the list of threads), if there is at least one unread letter? Suppose we decide to mark the thread as unread. But if the letters of the same thread are in different folders (for example, a part is in the Inbox and a part in the Important ones), we have two problems at once. The first one - by marking the thread read in one folder, we change the count of unread letters in two folders at once. The second is not clear what to do with the total counter unread letters. After all, if the user enters the box, sees that there are unread letters in two folders at once, opens the thread in the first folder and reads it, and both counters are reset, he will think that the second unread letter is simply lost.
We dismissed this option as unsuccessful and decided to try to do differently: mark the thread unread only in the folder where the user has unread letters. For example, letters of a thread are dispersed between Inbox and Important, while the only unread letter lies in Important. That is, if the user is in the "Inbox" (where there are no unread emails), all threads are marked as read.
However, another small problem arose here - when a user opens a thread from the Inbox, already inside he sees that there is a unrolled unread letter in him (the same one that lies in the “Important”). It turns out a little illogical.
We solved this problem in the following way: letters from other folders in the thread will also be minimized to the status of the header, even if they are not read. So, getting to the thread, the user sees only the unread letters from this folder are expanded. Thus, we have no unnecessary information and no “random” readings of what should have been reminded of ourselves (it was not for nothing that the sorting into a separate folder was set up).
However, in fairness, I must say that the situation when letters from one thread are in different folders (not counting the Sent, of course) is quite rare. And this is good!
2.4 Removing threads
At the same time, we had to find an answer to one more question. Imagine a situation: we are in the Inbox folder and open a thread in which one letter is from the Inbox folder, and the second is from the Sent folder. If you click "Delete thread", what happens to the letter from the "Sent"? Interviewing users, we found out: they expect the letter to remain in the Sent Items folder. Therefore, we have all actions with a thread - removal, movement, etc. - apply only to letters from the folder that the user has opened.
2.5 The position of the new letters in the thread
Another important question that needed to be solved: at the top or bottom of the chain to show the latest letters? We decided to keep the principle on which classic e-mail works, that is, the most recent letters show on top of the thread (unlike, for example, Gmail, where new letters are displayed at the bottom of the thread).
In addition, our research has shown that many users start reading threads from the last letter in order to understand whether it is worth reading the rest of the letters in the thread. This was another argument in favor of displaying new letters from above.
2.6 Functionality of the toolbar
It was also necessary to decide how the toolbar with the "Answer" button relating to the whole thread would work. We chose between two options: hang up on it the answer and forward it in relation to the last letter in the thread, or to the letter that the user currently has on the screen. As a result, we stopped at the first option, because the option with the letter currently on the screen introduced too much uncertainty, for example, what to do if there are two or even three short letters on the screen at once? Or how to intuitively prompt the user to which letter he is now responding?
By the way, this is why the last letter in a thread is always expanded, regardless of whether it is read or not. In case the user has a desire to respond to any other email, we have made a small additional toolbar inside the thread that allows it.
We summarize:
***
Realization of threads in the mail is a rather difficult task, and we spent a lot of time and effort on solving it. Now threads can be enabled in all Mail.Ru Mailboxes.
I would be very grateful if you tell us in the comments how convenient it is for you to use the updated interface and whether the solutions that we have chosen seem logical to you.
However, all our usability testing showed that for a less advanced audience, threads are a fairly complex feature and not always convenient. Many were horrified by “losing” their letters in the Inbox, they could not figure out how to respond to a specific message in the thread, and much more.
Nevertheless, by ourselves (Mail.Ru team of the Mail), as people belonging to the first group (geeks, production lovers and programmers), the idea of threads was close and clear. Therefore, we decided to meet the wishes of the advanced community and implement threads in an optional mode (you can turn them on in the “View” menu in the upper right corner above the list of letters).
')
However, it is easy to solve, but not so easy to do. At the stage of thinking through logic, a lot of nuances were discovered. Although the threads were already implemented in other postal services, we still had to develop our own algorithm. Firstly, some other people's decisions seemed to be erroneous, and we decided to correct them, and secondly, the logic of some basic functionality of our mail is different from the work of similar functionality in others, so it’s impossible to “learn from experience” as is.
In this post we want to talk about the difficulties that awaited us and how we managed to overcome them.
1. How to "glue" threads
1.1 Understanding In-Reply-To
Each letter has meta-information (service headers). The In-Reply-To header indicates the answer to which letter the message you opened (In-Reply-To) is answered, and the References contains, among other things, information about the letter that was the first to correspond. It is logical that if there are such service headers, then it makes sense to group the letters by these headers. However, there are two nuances that we had to take into account.
First: how to deal with redirected letters? In the case when the incoming letter is redirected, in fact there is another letter with the service header In-Reply-To. This header indicates a redirected letter. At the same time in the subject appears prefix FW or FWD. That is, in fact, the forward is another answer. Guided by this logic, Gmail, for example, “sticks” redirected letters to the same thread.
We interviewed users inside Mail.Ru and outside and found out that, as a rule, they send a letter not in order to connect the person to the correspondence, but to discuss the topic of correspondence with him separately. So - they want to start a new "conversation", and not stay in the old. Therefore, we decided that in such cases we will start a new chain.
Second, sometimes people can reply to a letter by changing its subject manually. Then the In-Reply-To tag will formally remain in the service header of the letter, but the subject of the letter will change. Focusing on the results of our research, we realized that if people consciously change the subject of the letter, it means that this is a new chain for them, and decided that in such cases we will also create a separate thread, even though there is an In-Reply-To in the service header .
Based on these two nuances, the grouping algorithm should be as follows:
- we normalize the subject, for example, we throw out all the prefixes “Re”, but we leave “FWD”
- group letters associated with headers and with one normalized topic
1.2 We consider grouping for automatic mailings.
If there are no headers, it does not mean that there is nothing to group. There are many letters that are asked in one group: notifications from social networks, promotional letters from online stores, letters from task tracker, finally. As a rule, in all these cases, the letters have one subject and one sender. Therefore, we decided to group letters with no headers by the “subject + sender” criterion in order to cover automatic mailings.
1.3 Separate the "basket"
A separate problem in the implementation of threads creates the folder structure of the Post. We decided that letters from different folders, including those from the “Sent One,” could be put in the same thread, so that you could see the received letters and the answers to them in one place. There, in theory, the letters from the “Trash” folder should have been included. Initially, we were guided by this logic, but the first beta testers gave us feedback that it was inconvenient and that they did not want to see deleted letters, even if they could be grouped by headings with a letter in the Inbox.
1.4 Determine meter readings
As we have already said, when grouping letters from one chain, they can be scattered in different folders (the simplest case is Inbox and Sent Mail). In this regard, a lot of questions arise, for example:
- If the thread is not read, does it remain unread in all folders?
- If there are several unread letters in the chain, what should the counter show - the number of unread letters or one unread chain?
We have three options. Let's consider them.
The first: the counter works with chains, and the unread chain is marked in all the folders in which it is displayed. For example, in two folders - "Inbox" and "Sent" - there is one unread letter that has just arrived in the box. In the list of folders, we will see one in each of these two folders. But what to show in the general counter at the box? In theory, there it is necessary to display the amount for all folders, but in our case it is two. But after all actually one unread chain is in the box!
The second option: a thread in a folder is considered unread only if there are unread letters from this thread in the folder. But suppose there are two unread letters in the thread. Folder counter displays unit: one thread is not read. The user opens a thread and reads the top letter, after which he returns to the list of letters. One letter is read, but the counter still shows the unit: there is another unread letter in the thread, which means that the whole thread is not read. It turns out that the user performed the action, and the meter readings have not changed.
The third option, which we have chosen: in the meters we take into account letters, and not threads. In this case, the counter of each folder displays the correct data, because the letter can not be in several folders. The total counter also always displays the correct number. The interface in this case reacts to the reading of any letter by changing the meter readings.
We summarize:
- we glue threads by headers and subject or by sender and subject.
- Forward letter starts a new thread
- the thread includes letters from all folders except the "Recycle Bin"
- in the folder counters we display the number of unread letters, but not threads
2. Appearance of the thread and actions with it
2.1 Three levels or two?
There are two basic types of display threads on the market:
The first is when clicking on a thread in the list of threads, another list opens, this time already letters, where you have to click again to get to read a particular letter. For convenience, we called it "three-level." It is used, by the way, in many places - from some versions of Outlook to a large number of mobile email clients.
The second one (it’s also “two-level”) —when clicking from the list of threads, the user goes directly to the “bodies” of the letters, i.e. has the ability to quickly get to the actual content of the correspondence.
We decided not to stand in the way of the user to his content and not to force him to make two clicks every time he wants to read the newly received letter. As you already guessed, the “two-level” option was chosen. Although he technically and ideologically foreshadowed many more problems, but about them a little further.
2.2 Read and unread letters inside the thread
Here we decided not to philosophize slyly - it is obvious that the user is interested first of all to get acquainted with the content of those letters that he has not yet seen. And consequently, on them and need to focus his attention. Therefore, inside the thread, we decided to deploy all the unread letters, and leave all the reads folded.
If there are no unread letters in the thread, we leave the last one unrolled (why - more on that a little further).
2.3 Read and unread threads in the thread list
The first question that had to be resolved was: should the thread be marked unread in the list of letters (now in the list of threads), if there is at least one unread letter? Suppose we decide to mark the thread as unread. But if the letters of the same thread are in different folders (for example, a part is in the Inbox and a part in the Important ones), we have two problems at once. The first one - by marking the thread read in one folder, we change the count of unread letters in two folders at once. The second is not clear what to do with the total counter unread letters. After all, if the user enters the box, sees that there are unread letters in two folders at once, opens the thread in the first folder and reads it, and both counters are reset, he will think that the second unread letter is simply lost.
We dismissed this option as unsuccessful and decided to try to do differently: mark the thread unread only in the folder where the user has unread letters. For example, letters of a thread are dispersed between Inbox and Important, while the only unread letter lies in Important. That is, if the user is in the "Inbox" (where there are no unread emails), all threads are marked as read.
However, another small problem arose here - when a user opens a thread from the Inbox, already inside he sees that there is a unrolled unread letter in him (the same one that lies in the “Important”). It turns out a little illogical.
We solved this problem in the following way: letters from other folders in the thread will also be minimized to the status of the header, even if they are not read. So, getting to the thread, the user sees only the unread letters from this folder are expanded. Thus, we have no unnecessary information and no “random” readings of what should have been reminded of ourselves (it was not for nothing that the sorting into a separate folder was set up).
However, in fairness, I must say that the situation when letters from one thread are in different folders (not counting the Sent, of course) is quite rare. And this is good!
2.4 Removing threads
At the same time, we had to find an answer to one more question. Imagine a situation: we are in the Inbox folder and open a thread in which one letter is from the Inbox folder, and the second is from the Sent folder. If you click "Delete thread", what happens to the letter from the "Sent"? Interviewing users, we found out: they expect the letter to remain in the Sent Items folder. Therefore, we have all actions with a thread - removal, movement, etc. - apply only to letters from the folder that the user has opened.
2.5 The position of the new letters in the thread
Another important question that needed to be solved: at the top or bottom of the chain to show the latest letters? We decided to keep the principle on which classic e-mail works, that is, the most recent letters show on top of the thread (unlike, for example, Gmail, where new letters are displayed at the bottom of the thread).
In addition, our research has shown that many users start reading threads from the last letter in order to understand whether it is worth reading the rest of the letters in the thread. This was another argument in favor of displaying new letters from above.
2.6 Functionality of the toolbar
It was also necessary to decide how the toolbar with the "Answer" button relating to the whole thread would work. We chose between two options: hang up on it the answer and forward it in relation to the last letter in the thread, or to the letter that the user currently has on the screen. As a result, we stopped at the first option, because the option with the letter currently on the screen introduced too much uncertainty, for example, what to do if there are two or even three short letters on the screen at once? Or how to intuitively prompt the user to which letter he is now responding?
By the way, this is why the last letter in a thread is always expanded, regardless of whether it is read or not. In case the user has a desire to respond to any other email, we have made a small additional toolbar inside the thread that allows it.
We summarize:
- the most current letter from the current folder is always expanded
- letters from other folders are minimized regardless of status
- Letters from the current folder are collapsed only if they are read.
- when deleting a thread, only letters from the current folder are deleted
- the most recent letters are displayed on top
- buttons on the top Tublar in the thread work with the top letter
***
Realization of threads in the mail is a rather difficult task, and we spent a lot of time and effort on solving it. Now threads can be enabled in all Mail.Ru Mailboxes.
I would be very grateful if you tell us in the comments how convenient it is for you to use the updated interface and whether the solutions that we have chosen seem logical to you.
Source: https://habr.com/ru/post/247861/
All Articles