UX - Thread page improvements
Thread page objectives
- To discuss about anything related that community (included collections and resources)
- To take decisions that affect the community (and the related collections and resources involved)
- To let users read the whole history of comments as reference
- To be used in other contexts for referencing agreements/past issues
Questions based on objectives
- Do users want to tag a discussion as close to deal with solved / unsolved discussion ?
- Do users want to have a preview of all the collections and resources that was cited in the discussion?
- Do users want to quote specific comments or the whole thread in other threads ?
Nested replies vs Flat thread + Forking comments
Nested replies is a solution more suitable when the goal of the thread is to pose a question and find the best answer (and often reward in some way the related author) . Examples of well-used nested replies are:
In this kind of apps, nested replies are useful to question the answer, get more details out of it, or to highlight it - but in any case, the goal is to come out with one answer that solve the question, that's why nested replies UX is often combined with upvote and with the possibility to visualise most recent or most upvoted comments on top.
On the other hand, for more open discussions or for discussions that imply to collectively find a conclusion, highlighting the single comment is controversial and misleading. ( For "highlighting the single comment" i mean give the possibility to create a subcomment inline, that shift the focus on the page from the main thread discussion to the discussion upon a specific comment, upvote a comment, and change the visualisation of the thread, from chronological order to most upvoted ones.)
Flat thread + forking comments works better instead for such UX where users build collectively an agreement out of a linear discussion.
Examples of well-used flat thread + forking comments are:
- github issues
- ssb Patchwork
In this apps, the chronological order of comments is often crucial to understand the final agreement and it is easy to read the whole discussion and get a sense out of it. When a user needs to reply to a specific comment, usually has 2 options:
- if the reply fits the main thread, the user can quote a specific part of the reply
- if the reply does not fit the mean thread, the user can fork the comment and create a new thread upon it, starting a new discussion
Regarding Moodlenet, I highly encourage the flat thread + forking comments approach for the following reasons:
- As Moodlenet is trying not to be an ego-pumping network, (eg we're not showing how many followers a user has on her/his profile), we should not encourage the upvoting system on thread comments (listing the most starred comments on top of the thread), but rather encouraging the creation and management of a thread as a work of the common.
Starring a comment === bookmarking it, not upvoting it ...
As often happens on github the user can get a feeling of the the most appreciated answers by looking at emoji reaction.
- We should not encourage the right single answer, but the best common agreement
- We should facilitate the understanding and the interaction with a thread, and flat thread are by far easier to read and work with
Notable technical needs
- Add a title to a thread
- Add a tag to thread: Open / Close
- Add emoji reaction to comments
- Add Last activity (we have it already)
- Add list of thread participants
- Add list of resources / collections mentioned on the thread
- Show the last 5 comments
- Show all the comments (without pagination)
- Use a reference of a thread (that is smaller than actual ids) to be able to mention threads on other threads (like #12 (closed))
- Mention user / collections / resource on comment