I disagree. Liking a post does mean you’ve read it, so the semantics are clear. In nearly four years of using Discourse, I have categeorically never pressed the like button on a post I have not read.
3 Likes
Yeah, but liking a post also means that you like it. So it enables a scenario when someone presses the like button on a post they don’t like (just to show that they do acknowledge it’s content). This is the semantic discrepancy that we’re trying to solve here.
2 Likes
If they are an employee or on the team, why would that be a problem? It seems to me if you work for the company, “liking” stuff that you’re supposed to
e.g. here’s an announcement on an exciting new thing we are working on
12 likes
… is normal and expected.
I don’t get this big descrepancy.
It’s like you work for the company but you don’t approve of the things the company is doing? Why would you work there, again?
2 Likes
What I am not following here is why make people click “I read it” when we already know they read it.
We track read state on all posts.
I can see some value in adding publicity visible read state on private messages, especially when groups are involved. That is where experimentation should start.
Additionally this solves the problem described here without littering public posts with messy metadata. You send a PM to staff when you make an announcement, and can tell when they all read it.
2 Likes
Yes agreed, but
this is a public announcement, not a PM.
PM doesn’t allow simple read acknowledgement, as well. Could you explain in what way are they different in the context of this conversations? It seems there’s something I’m missing
Pretty much ↑ that
2 Likes
We use Discourse to offer technical support to our customers. And we miss the “read ack” button too.
Of course for us the “like” semantic is very different from the “read” one. The usefulness of the “I read it” button is to show the original poster that I’ve read it, without polluting the thread with acknowledge messages, as stated above.
You (@codinghorror and @sam) keep saying Discourse already knows of the read state. But how a user can know of it? I don’t see it anywhere on the GUI. The proposed feature here is about an easy information on who has read the message (in the same manner the like info is currently managed).
1 Like
It is the same social awkwardness with “read receipts”, there is a reason people resist this functionality and it is almost never on by default. Also why it is often more appropriate for private messaging vs. public. You can query the database to get the information, though.
3 Likes
- I have read this.
- I do not read, I just click.
0 voters
Apparently polls need at least two options. Huh.
3 Likes
Just another example/thought:
Users come to our forum to report issues with our Video On Demand channel. I must compile all these issues into a spreadsheet.
These members are unable to tell if I’ve read their posts or not, so I have been “liking” them to show I’ve added them to the report. Answering each individual post is time-consuming and would require a lot of “Thanks for your report” posts and would make each day’s posts go on and on.
These users do not come into the forums for anything else but this one thread, so are not really as forum-savvy as our regular users. They do not always scroll up to their last post to see what has been written in their absence and tend to just scroll to the bottom to add another post.
I do not necessarily “like” everything I read about the problems users are having, but having some indicator that I’ve read their posts and am reporting on them makes them feel like someone cares.
4 Likes
Ah, I believe I can understand why some staff might ask for a “read” function.
It really depends on whether you are running a community with close service-customer relationships or a rather solemn online forum where “likes” are seen as rather Facebookish, in a negative way, by the majority of users.
But then, I would also definitely consider writing a short message in the respective topic instead of leaving a reading receipt. That would also make me less of a shrew if I forget about it later giggle
2 Likes
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, 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:
- it’s impossible to the post without having read it, so OP’s need (proof of read) is achieved.
- 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 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):
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.
4 Likes
If we had a lot of paying customers telling us they needed it, with reasonable real world examples of why they needed it, that would change.
This is currently not the case, nor has it been in the last two years.
2 Likes
Fair enough.
I saw this earlier. Is this you saying “it’s possible for you to write this functionality yourself with a plugin”? Because honestly, even that would tickle me.
3 Likes
Make Poll with showing results
Make checkboxes whit Checklist Plugin - Interactive Checkboxes made Simple
There is now a discourse-policy plugin that we use for this purpose internally, when there is a “must have acknowledged official SOC2 security policy” topic posted.
5 Likes
Indeed.
I’m not a heavy user of multiple chat applications, but I like how Riot.im shows the little avatars of users in the last comment they read. This gives every member of a room a good idea of who has read what, without requiring anyone to do anything other than reading.
This is an overkill for an entire Discourse forum, but for the use case of groups (and especially those providing support / relying on quick coordinated actions) it would be a very nice touch. But yeah, not trivial to implement, I guess.
(The “Seen by anmol” tooltip appears when you place the mouse pointer on top of an avatar.)
1 Like
To pay the bills.
You’re lucky happy few if you never had to be in that position. 