# "I read it" button alongside "I like it" button?

**URL:** <https://meta.discourse.org/t/i-read-it-button-alongside-i-like-it-button/52206>\
**Category:** Feature\
**Created:** [29 באוקטובר,‏ 2016,‏ 5:11pm UTC](https://meta.discourse.org/t/i-read-it-button-alongside-i-like-it-button/52206 "2016-10-29T17:11:44Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![mos\_basik](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mos\_basik](https://meta.discourse.org/u/mos_basik)\
**Post date:** [6 בנובמבר,‏ 2016,‏ 4:28am UTC](https://meta.discourse.org/t/i-read-it-button-alongside-i-like-it-button/52206/18 "2016-11-06T04:28:11Z")

</div>

## Caveat

I only heard about Discourse yesterday, and I’m only now exploring the meta forum to see what the interface is like and get an idea of how conversation threads are followed, so forgive me if I ask for or say something blindingly obvious or already implemented.

## Common usage of read receipts

As I recall, read receipts started showing up commonly one to two years ago in messaging apps. And like you say, they caused a splash and users resisted them. But things have changed - almost all popular messaging apps have read receipts as a default:

- Facebook Messenger (#1 most installed messaging app in 2016)
- WhatsApp (#2 as above)
- Line (#4 as above)
- Viber (#5 as above)
- iMessage (iOS devices)
- Google Hangouts
- Kakaotalk (#1 most installed messaging app in South Korea)

(The big exception is WeChat, #3 overall in 2016 and #1 in China. Make of that what you will.)

I’d put forward that people have become used to the concept, as well as the behavior changes necessary in such a system to avoid awkwardness. At least for me, it’s now second nature.

(Incidentally, there is a whole laundry list of browser extensions to provide read receipts to Gmail (with varying effectiveness depending on the recipients’ settings, ofc). Clearly, people find it useful to know if what they’re sending is being read)

All this to say, I don’t think the concept of read receipts in chat apps is as alienating to users now as it was a couple of years ago.

In that vein, I noticed an interesting bit at the very beginning of the [Discourse FAQ page](https://www.discourse.org/faq/), describing Discourse as:

- a mailing list
- a discussion forum
- _a long-form chat room_ [emphasis added]

## Suggestions Already Posted

I think OP [@kuba-orlik] has a good use case, but I don’t think the “I read this” button his title suggests is the way to do it. It smells like the “faster horse” solution instead of the “car” Ford made. The whole point of Discourse is to be the forum of the future.

Your [@codinghorror’s] suggestion is that people use the ❤, and your justifications are:

1. it’s impossible to ❤ the post without having read it, so OP’s need (proof of read) is achieved.
2. given that a likely use case is in an company environment, you should feel more or less positively about all the things your company is doing, and so a semantic conflict should never occur anyway.

I think this misses the point. OP specifically requested a solution that _does not share semantics_ with ❤'ing a post. Even if the semantic overload might not be an issue in a workplace environment (and I think it would), Discourse is flexible software and can be used in a number of environments where that semantic difference is important.

## Example and examination of possibilities

Say you outline some kind of suggestion or spitball an idea in a post. You come back in an hour, or the next day. It’s useful to see who, _specifically_, has read that post. It’s _also_ useful to see who has voluntarily ❤'ed that post. The ratio tells you

- nobody has read it yet (low reads, low ❤s)
- interest is low (high reads, low ❤s)
- interest is high (high reads, high ❤s)

And - very importantly - you can tell if people that are specifically important to that post (say, the people you’ve tagged) have read it yet and whether or not they like it.

This information lets you know whether you should wait longer for more input, mothball the idea for lack of interest, pursue the idea, or call the front-end guy on his cell because everyone loves it but he’s the guy who’ll have to build it and has final say on how realistic the concept is. Or whatever.

You might say this is a poor example because, say, any business where a mission-critical user does not read their notifications daily is doomed and has worse problems to solve than read receipts on forum posts. Fair enough, _if_ Discourse is intended to be business-oriented project first and foremost and all other users are second-class citizens. I don’t get that impression from what I’ve read so far, though. Correct me if I am wrong.

When I set up a Slack server a while back for a community I help organize, I ran into this sort of issue very quickly. For example, Slack has no `/ignore` command to privately mute irritating or harassing members. [Slack’s public response to inquiry about this feature](https://twitter.com/stewart/status/624239660529684481) was (paraphrased) “If you can’t stand someone enough to see their messages, you should probably fire them.” Fair enough; Slack has always been oriented towards the business market. Eventually, for a number of reasons, my community left Slack and went to Discord. Currently, my personal opinion is that Discord could now wipe the floor with Slack, given the features of each, if Discord simply dropped its “gamer” branding and went for a wider audience. But that’s neither here nor there.

## Implementation

You said yourself that the data is already being collected (makes sense given the “view counts” displayed in the list of threads):

> [@codinghorror](#):
>
> Discourse knows exactly what you have read and even how long it was visible on your screen…

I think the elevator pitch of this thread essentially amounts to this:

**Read receipts - _in a forum!_**

and that is something I have _never_ seen before.

It seems like it would be exactly the kind of thing an innovative platform like Discourse would consider including. Surely this could be configurable at the server level by an admin with a toggle, or at the very least made available to the plugin API. But like I said above, I have no idea what is already available or how granular it is.

## Anecdote to wrap up:

Recently I was added to a Facebook chat with over 300 members. This is kind of ludicrous in and of itself - Facebook chat is _not_ the right medium to try and convey information between large groups of people - but I noticed the read receipts were quite useful. They told me which people in that 300 line long member list were actually active and keeping up with the content - _even if they were not actively posting_.

Every time a message was posted, a few profile pictures trickled down to the bottom. Several of those profiles them haven’t made a peep in the channel itself, but I know if I PM one of them, they’ll be able to talk coherently about the discussion. I know they’re _interested_.

* * *

…wew, that was a novel for a first post. I don’t mean to be inflammatory or disrespectful, if that’s how any of this appears.

---

_[View the full topic](https://meta.discourse.org/t/i-read-it-button-alongside-i-like-it-button/52206)._
