Deltachat-android: Read receipts and Social pressure

Created on 6 Jul 2017  Â·  20Comments  Â·  Source: deltachat/deltachat-android

The upcoming version of Delta Chat adds an option that will inform the _sender_ of a message that the message is displayed on the _recipient's_ device(s).

These so called "Read receipts" or "Return receipts" are available in many other messengers and are often shown by an additional checkmark.

While we believe that these Read receipts are an useful addition, we also know that there are good reasons for users to disable them.

Why a simple disabling does not work

If we would provide a simple option to disable the Read receipts, in normal 1:1 chats, this should not make a problem. The receiver would simply not expect Read receipts from some senders. Fine. Done.

But in group chats, things become more complicated. Usually Read receipts are shown when _all_ recipients have read the message.

However, with this approach, a single group member who has disabled Read receipts would break the Read receipt functionality for all other users. Bad.

Even more bad is the social pressure that the person(s) who has disabled the read receipts will get -
imagine a group of 20 people with 1 person who has disabled the Read receipts; this single person is the reason that all others cannot use Read receipts.

WhatsApp solves this dilemma by not allowing to disable Read receipts for groups. Others show the second checkmark if they receive a single Read receipt - which makes the function almost superfluous - or do not offer Read receipts for groups at all. Another idea may be to allow different settings for different chats, but, however, this would not solve the problem, maybe it can reduce it.

So, as a conclusion, these optional Read receipts are _not really optional_ and do not work.

Our solution: True optional Read receipts

But how can we gain a true option for the user without exposing him to social pressure? We do this by a slight redefinition of the additional checkmark:

  • We show the second checkmark if a message is read by the majority of group members
  • Only if the majority has disabled Read receipts, the second checkmark won't appear at all

It's a sort of a democratic vote. Advantages:

  • The sender has an idea about that his message is read by the majority
  • No social pressure - only if the majority decides against Read receipts, they do not appear
  • Technically, in _large_ groups, we can reduce the overall number of read receipts by forcing only some samples (eg. by letting only about every 4th member send Read receipts; the sender simply multiplies the result by 4 then)

What do you think about this approach? As always, discussions are very welcome.

Most helpful comment

Ok, my thoughts were just that "5 Views" (or "5 and an eye icon") does look quite understandable, it provides adequate information without implying any interpretation on the user (like worse messengers do).

Even a "4/5 Views" scheme should be commonly understandable these days. No need to imitate the limiting of down of users, when one can do better easily.

All 20 comments

The idea is very good! That is better than the option to force somebody in group chats to enable the read signs.
I love the idea and think that is a perfect solution!

Dear Björn, IMHO there is no need to send read receipts at all. All you
need to know is if the message was delivered to destination mail server.
A Delivery receipt is enough to guaranty the sender that there was no
fault on his side for the communication to proceed. And let the receiver
free to do his part.

Off course, soliciting read receipts can be an option for those who want
to require it, and those who want to send them. But that that is the
delicate matter which has to be preserved and never forced.

In that sense, there's no difference beetween peer and group chats, if
you need privacy and time to read and answer (or not) the messages, the
software should never force that.

My 2 cents.

Best regards

On 06/07/17 11:08, Björn Petersen wrote:
>

The upcoming version of Delta Chat adds an option that will inform the
/sender/ of a message that the message is displayed on the
/recipient's/ device(s).

These so called "Read receipts" or "Return receipts" are available in
many other messengers and are often shown by an additional checkmark.

While we believe that these Read receipts are a useful addition, we
also know that there are good reasons for users to disable them.

Why a simple disabling does not work

If we would provide a simple option to disable the Read receipts, in
normal 1:1 chats, this should not make a problem. The receiver would
simply not expect Return receipts from some senders. Fine. Done.

But in group chats, things become more complicated. Usually Read
receipts are shown when /all/ recipients have read the message.

However, with this approach, a single group member who has disabled
Read receipts would break the Read receipt functionality for all other
users. Bad.

Even more bad is the social pressure that the person(s) who has
disabled the read receipts will get -
imagine a group of 20 people with 1 person who has disabled the Read
receipts; this single person is the reason that all others cannot use
Read receipts.

WhatsApp solves this dilemma by not allowing to disable Read receipts
for groups. Others show the second checkmark if they receive a single
Read receipt - which makes the function almost superfluous - or do not
offer Read receipts for groups at all. Another idea may be to allow
different settings for different chats, but, however, this would not
solve the problem, maybe it can reduce it.

So, as a conclusion, these optional return receipts are /not really
optional/ and do not work.

Our solution: True optional Return receipts

But how can we gain a true option for the user without exposing him to
social pressure? We do this by a slight redefinition of the additional
checkmark:

  • We show the second checkmark if a message is read by the
    majority
    of group members
  • Only if the majority has disabled Read receipts, the second
    checkmark won't appear at all

It's a sort of a democratic vote. Advantages:

  • The sender has an idea about that his message is read by the majority
  • No social pressure - only if the majority decides against Read
    receipts, they do not appear
  • Technically, in /large/ groups, we can reduce the overall number
    of read receipts forcing only some samples (eg. by letting only
    every 4th member send Read receipts, the sender simply multiplies
    the result by4)

What do you think about this approach? As always, discussions are very
welcome.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/deltachat/deltachat-android/issues/113, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMqPe7R9QKJpmUG9jIOlUPrXcyxJxRyyks5sLOpBgaJpZM4OPr9I.

Giving that delta chat is based on the email protocol, the OPs proposition is the best solution.

I also use Telegram. In group chats the second check mark is set, as soon as the first person has read the new message. In combination with the information, when a group member was last seen online, you can assume who has read the message.
I assume this functionality can't be implemented in delta chat.

So I vote for the OPs solution.

How is this working with mail? Can't i just go to the mail folder for the chat and check who sent a receipt?

In your "normal" email program, you normally see the read rceipts as "normal" mails with a text describing for what original mail the read receipt references to.

But you want to avoid the social pressure by not showing the checkmark when there is no majority. On the technical level everybody can see the receipts or somebody may build a patched client showing the mark or even a precise list who read it. Isn't this a bit security by obscurity?
Or am I mistaken in which direction the concept should work?

We do not want to make a secret about who has send an read receipt and who not. This is not possible.

But the core functionality, the "second checkmark", does not break if up to the half people in a group have disabled the read receipts. A minority won't break the "second checkmark" functionality of the majority, so there is no social pressure to them to leave the read receipts enabled.

All this does not affect normal MUAs as they normally do not show a second checkmark and do not collect group read receipts. In normal MUAs one just get the read receipts of the single recipients and it's up to ther user to interpret things.

Instinctively I would have said: _All_ or nothing. For example you want to cancel an appointment with a message to a group and want to know that everybody is aware. Then it would not be good if the status looks like "read by all", but in fact it is only the majority.
Also I would not feel or give any social pressure - it is everbodys decision to disable read receipts.

On the other hand, I can imagine a user setting, like read-threshold-for-group-msg in percent (the checkmark is set when the rate is equal or above). Initial value should be 100%, but every user has the freedom to set another value. If he is satisfied with a lower read-rate then it's his own decision.

Hello,
I think your solution might be confusing to some people. It's different than all the other services do it and a lot of people will probably think if a read receipt is shown it means everyone has read the message.

How about little avatars instead of double checkmarks after the newest message that users have read up to? Hangouts does it like that and I think other apps do that too. Here is a sample screenshot (however only for a 1:1 conversation, but it works the same for groups) (credit androidpolice.com):

Another thing: I always found it strange that read receipts were sent automatically. You could escape that by reading a notification without swiping it away or you could miss a message that you just received when you turned off your phone but the phone still thinks you read it or you may just not have paid attention, e.g. because when you unlocked your device this conversation was shown but you didn't read it because you were in a hurry to do something else. So I'd actually like a button, maybe an eye or checkmark, that let's you send a read receipt. I think every messenger should have it instead of letting the device decide. However I also get that it's more convenient to not press a button, but the advantages are bigger for me and I don't think it's a lot of work and then you could finally really trust a read receipt. You'd also get rid of the problems like people trying to avoid sending read receipts or sending them by accident when you wanted to disregard a message but still switched to it accidentally. This would in my opinion also get rid off the peer pressure problem, because you wouldn't need to turn the "automatic read receipt" feature on. You'd just need to press the "send read receipt" button and everyone would be happy. Furthermore, you can only escape peer pressure so much -- if they really insist they'll send a message like "everyone please reply to this so we know you read this" and then the pressure is back.

Another method to escape this pressure would be to turn automatic read receipts on per conversation (group). What do you think?

Threema has an option to mark a message with a checkmark or cross to mark it as read, understood and accepted or declined. This is a nice (additional) feature to the usual sent/delivered/read status.

Hello, I'm curious, so what was the chosen solution?

Hello, I'm curious, so what was the chosen solution?

The _True optional Read receipts_ - read receipts are send if the majority has enabled them and read a message.

The reading person needs to decide whether to send receipts (with a default and a per message option).
For example: Show a line / or darker background up to all already dealt with messages.
New messages are (say) yellow until you tab? them for your own housekeeping (and default action), optionally allow long-tab? ->confirm "read" receipt to sender to post "read" to group?.

The Chat-App needs to show the information available.
For example, only show an eye icon with a checkmark, if a message was really read by all recepients. But just show "5 reads" or "5 in front of the eye icon" otherwise. Long-tab? ->show list of receipts.

Personally, I think using statistics here is misleading (n too small, wrong on level of individuals).

Thank you for your ideas, we appreciate all input and suggestions.

Some spontaneous notes:

  • For the GUI, we just do not want to make things more complicated as in other Messengers
  • regarding statistics, well I think it's more than this, its more like a real vote

Ok, my thoughts were just that "5 Views" (or "5 and an eye icon") does look quite understandable, it provides adequate information without implying any interpretation on the user (like worse messengers do).

Even a "4/5 Views" scheme should be commonly understandable these days. No need to imitate the limiting of down of users, when one can do better easily.

I would like that.
Good Idea :)

+1 nice
2 de octubre del 2017 19:44, "testbird" escribió:
Ok, my thoughts were just that "5 Views" (or "5 and an eye icon") does look quite understandable, it provides adequate information without implying any interpretation on the user (like worse messengers do).

—

You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/deltachat/deltachat-android/issues/113#issuecomment-333686347), or mute the thread (https://github.com/notifications/unsubscribe-auth/AMqPeykfackOcvn75mw9NzvxK06MWRqzks5soWdWgaJpZM4OPr9I).

More precise: I would think about a "4/5 Views" scheme :)

Ok, my thoughts were just that "5 Views" (or "5 and an eye icon") does look quite understandable,

I really like this idea much more than a confusing double mark, +1

Was this page helpful?
0 / 5 - 0 ratings

Related issues

angelo-fuchs picture angelo-fuchs  Â·  4Comments

escoand picture escoand  Â·  4Comments

adbenitez picture adbenitez  Â·  4Comments

gerroon picture gerroon  Â·  3Comments

r10s picture r10s  Â·  4Comments