Ability to mark any post as unread


(FichteFoll) #1

Continuing the discussion from How Coinbase Uses Discourse to Educate Customers and Improve SEO:

The interviewee of the referenced blog article states the following dislike:

If a post on a topic can be “unread”, why can’t I mark it unread again after reading it?

and I’d like to talk a bit about that and the workflow that is not possible at the moment.


Concept

In email clients, you can mark any email as “unread”, even in a longer discussion or thread, and return to it later. Most clients allow you to filter or navigate unread emails only, so this workflow is a breeze for when you decide you need to work on something again later, such as prepare a reply.

The same holds true for RSS readers, where you find a post that deserves more attention than what you give currently and you want to save it for later.

In Discourse, however, the concept of marking specific posts as unread is not a thing and unread posts can only occur at the end of a thread that you didn’t scroll into the view yet. Additionally, the algorithm that chooses to automatically mark posts as read can be inaccurate depending on your reading habits (i.e. whether you use mouse scrolling or j/k keys).

Why Not Bookmarks?

I understand that bookmarks are a possible workaround for this situation. But “bookmarks” semantically mean something different in most situations because I only intend to (re-)read the “unread” posts once and not save it for recurring occasions. Thus, one-time bookmarks and long-term bookmarks would get mixed and you’ll have to remember to unbookmark each “unread” post when you access it. They would also not get displayed in the “Unread” front page tab.


Required Changes for Discourse

  • The unread indicator (currently blue dot next to relative post timestamp) needs to be toggleable, which likely requires repositioning and redesign. Also with a keyboard shortcut, suggesting m (already used for topic track state).
  • There needs to be a way to traverse between unread posts within a thread, up and down.

It’s not high priority for me, but it deserves to be discussed imo.


Keep posts unread
Possible "take me back to where I was" button on progress bar
(Sam Saffron) #2

A much higher priority for us is to have a cleaner way of dealing with “reading holes” eg: topics where you read post 1-10, 50 but did not read 11-49. If what you are describing would likely create reading holes and not behave in a very intuitive way cause you could only do it effectively for the last post in a topic.


Possible "take me back to where I was" button on progress bar
(FichteFoll) #3

Yes, it would (or rather should) be possible to create these “reading holes” that way.

My second suggested change is supposed to hint at the reading holes issue. I suppose there are generally two ways to solve this:

  1. Hide read posts.
  2. Do not hide read posts and instead provide buttons/key binds to traverse to next or previous unread post.

I can not evaluate how gray and blue unread counters are relevant here, because I don’t clearly understand how they work at this moment, however.


(Alessio Fattorini) #4

I like it and asked before


(Krister Viirsaar) #5

yeah I use Discourse as a teacher and there are topics I need to come back to in like 4 months (Bookmark) and there are topics I need to remember to answer in a few days (mark as undread).


(Olivier Lambert) #6

Agreed! I need a feature like this. Any workaround with a plug-in?


(Olivier Lambert) #7

Any progress on this? Is it on the roadmap?


(Jeff Atwood) #8

It is not on any roadmap I am aware of. Use bookmarks.


(Christoph) #9

Assuming that the Discourse Calendar plugin will also work in PMs, perhaps you can work around it by creating a calendar PM to yourself and adding replies with links to posts you want to come back to at a certain point in time?


(Stephen) #10

That sounds awfully complex when we already have several means to track notable threads.


(Christoph) #11

Absolutely. It was just an idea for those who are not happy with existing functionality.