Explicitly mark items to do something with

[keyserj]

Describe your issue

When working with a topic, frequently there becomes a list of items (nodes/edges, future: comments) that I want to do something with, but it's easy to forget these because addressing each one can take a while. Some cases where I might want to mark an item:

• mark contested scores, so that each can be discussed (related Highlight disagreed-upon claims from topic diagram #64 )
• mark action items, so that I can take away follow-ups (e.g. question to investigate, fact to get source for, problem to brainstorm solutions for)
• mark needs research, so that I can indicate something to investigate (overlap with action item, but maybe worth being specific)
• mark needs reference, so that I can indicate a fact that seems uncertain (overlap with action item, but maybe worth being specific)
• mark request clarification, so that I can indicate that I'd appreciate more explanation about something (related Request Clarification #324 )

Solution you'd like

Allow user to mark these things on any node/edge/comment. Would be nice if:

• marked items have a UX that can be turned on/off (e.g. "show unread" vs "show contested" vs "show needs research")
• should be able to filter to only marked items (maybe this should be "show [mark type]" and the above should be "highlight [mark type]"
  • this would be particularly useful with Text tree view of nodes #383

Questions:

• should some of these marks be always-visible indicators? or maybe the "show" options could turn specific indicators on/off, rather than one ambiguous "mark" UX
  • are indicators visible enough if the main goal of a use case is to see all of this thing? a mark could be colored/sized to stand out
• should items be resolved with a button or when an item is selected?
• how to manually mark items? context menu? buttons?

Alternatives you've considered

No response

Additional context

It's likely that some of these use cases should be addressed in slightly different ways, but they're all in this ticket because they're related, and their solutions should take each other into consideration.

Related issue that will likely share UX ideas #544

Technical ideas and questions

No response

[prototyperspective]

I don't see how this would be the issue for unseen changes (such as addition of new items) as in (a) feed(s) of nodes with unseen changes to go through one after another. You wrote "mark all unread items" but I think unchecked items should rather be marked as not-yet-seen by default for problem maps one is following/watching/subscribedto. I think maps to which one has contributed to would be good to set as watched by default (this is useful to increase engagement and content and is likely what users want). Somewhere there could be a page of watched maps. It's also less about learning than about contributing...if people have gone through an entire map and added everything they can think of, they would need to wait until somebody adds something after which they have something to add to it. In short items would need to marked implicitly and I think it probably needs a new issue for that doesn't it?

[keyserj]

I think unchecked items should rather be marked as not-yet-seen by default

This is what I meant, but I realize the wording doesn't convey that, especially because some of the other items to mark would be manual. I originally put "unread items" in this ticket because I feel that the UX will likely be similar for conveying which items are marked (like a blue dot that pulses or something). But there are a lot of ideas being included in this issue, and I agree that it'd probably be good to have a separate issue for the Unread feature. Created #544 as a separate ticket and just referenced this issue for consideration of related UX ideas.

marked as not-yet-seen by default for problem maps one is following/watching/subscribedto

For users coming back to a topic, I think we'd have to always be tracking what has been seen, in case they start following/watching/subscribing.

It does seem to me though that it could still be nice for a user that's new to a map, especially if it's a big map that's hard to remember what you've looked at already.

maps to which one has contributed to would be good to set as watched by default

This seems like a good idea. Created #545 for getting notifications of changes and included this in that ticket

Somewhere there could be a page of watched maps

Also a good idea, added this to the above ticket

It's also less about learning than about contributing

One thing I'm wondering - for the use case of a contributor keeping up with a topic, wouldn't a topic's history be better for this? Like if we know when you visited the topic last, we could highlight the range of changes of the history that are new to you. I think a big benefit of this is that you can see deletions too. Not to mention, history might have more context involved, like comments explaining a change or even just a bunch of similar changes being made, so you can see a pattern or get a higher-level understanding of groups of changes.

A question that'd have to be answered with this solution is how to know when changes have been seen? I think the easiest thing to do would be something like a button to view a diff of the topic from when you last saw it to now, then after using that, the app would know that you've seen all the changes. Potentially a change could also be marked as "seen" if all of the nodes in it have been seen as well, but then "seen" nodes would have to know that they were seen after the change (i.e. if the node isn't new, just something changed with it like its text).

[prototyperspective]

Thanks for making a separate issue for this.

I think we'd have to always be tracking what has been seen

Another approach would be to just consider everything seen and only notify of changes after subscribing. I think that would be preferable. Users could still see items they haven't seen if they rate the nodes and then use a feature to see or step through all the unrated nodes.

if we know when you visited the topic last, we could highlight the range of changes of the history that are new to you

I don't see much of a difference. It's simply converting that history to a list of items to click on so you can go through the added or changed nodes one by one. The second slight difference is that you can also visit a map in between without marking all of the nodes as seen – they are only marked as seen if you jumped to them, with the (full) map view (there's another discussion about mobile and alternative views where one can only see a small number of nodes at a time) one could mark nodes as seen by clicking on them. Clicking on 'deletion' items in the unseen changes feed would also show the deleted node (e.g. greyed out on the map until the next feed item is clicked). If there's something like edit summaries (another reason why making each node essentially a wiki page would imo be a good idea) these could be shown somewhere in the UI for the item similar to changelogs (however I think only the final item should be shown by default so one doesn't go through every text change one by one but sees the final result and all the edit summaries of the changes that lead to that which can be looked at via the node History page when needed).

A question that'd have to be answered with this solution is how to know when changes have been seen?

It's seen if the unseen changes feed item has been clicked. Alternatively, if in the full map view one has clicked on the node item (which could be highlighted somehow for having unseen changes).

[keyserj]

just consider everything seen and only notify of changes after subscribing

Yeah for someone trying to stay up-to-date with a Topic, this seems good.

Users could still see items they haven't seen if they rate the nodes and then use a feature to see or step through all the unrated nodes

Yeah this could work too. Added this idea to #544

It's simply converting that history to a list of items to click on so you can go through the added or changed nodes one by one

seen if the unseen changes feed item has been clicked. Alternatively, if in the full map view one has clicked on the node item (which could be highlighted somehow for having unseen changes).

This strategy makes sense to me. Noted these in #544

however I think only the final item should be shown by default

It'd probably be ideal for this to be able to just diff the last state of the node that you've seen + the current state