What to do about threads with missing top-level annotations in the client

[lyzadanger]

Goal

We want to show all relevant conversation threads in the Notebook, even if the top-most, root annotation for a thread has been deleted, and we want these threads to be useful and intuitive.

Current situation

Right now, threads whose root-level annotation has been deleted by the author, but still have one or more extant replies, “show up”, but are unusable:

(Don’t panic at how bad this is; this is all behind a feature flag and in prototype stage).

All threads like this—missing their top-level annotations—will show up at the top of the list and will be useless, at present. You can’t get at the replies in the thread at all.

We “handle” this in the sidebar by entirely hiding annotation threads that have a missing top-level annotation. This has long been a source of confusion. See: hypothesis/product-backlog#1106 This confusion is exacerbated because nested replies can handle missing parents just fine.

How we got here

I don’t have all of the history, but I have a sense that the challenge of sorting may have been a primary catalyst.

Think about it a little…How do you sort a set of threads by newest or oldest top-level annotations when some of them are missing top-level annotations?

And how on earth would you sort when in context (by location/selector in the sidebar, that is, by order on the page)? The target information needed for anchoring was lost when the top-level annotation was deleted. The replies are associated with the document (page) but the specific selectors were only within the now-deleted annotation. In short: what remains can never be anchored with the information we have. The remaining replies are doomed to be orphans or page notes at best (at least, in our current way of grouping things).

What defines a thread?

This leads me to the thinking: If there is no top-level annotation, maybe that’s not the top level of this thread anymore. Maybe one or more of its replies deserve a promotion.

Right now, given this (much more complex-than-average) thread structure:

* [Deleted annotation]
  * Reply A
  * Reply B
    * Reply C
    * [Deleted Reply 1]
      * Reply D
    * Reply E
  * [Deleted reply 2]
    * Reply F

We’d thread as a single thread with “Deleted Annotation” as the top-level annotation. It would not show up in the sidebar at all (unless search filters are applied and one of the replies is a match). In the current Notebook view, it would show up, but always at the top of the list, and unusable in its current structure.

Instead, what if we ended up with three threads in this case:

Thread Card 1
* Reply A

Thread Card 2
* Reply B
  * Reply C
  * [Deleted Reply 1]
    * Reply D
  * Reply E

Thread Card 3
* Reply F

When doing this re-threading on the client, we could still retain the metadata that Reply A, Reply B and Reply E have missing parents so that we could render them with helpful affordances (e.g. “This is in reply to an annotation that is no longer available” or similar). And as shown by the second thread, nested threads with missing annotations are fine—what I’m suggesting here is that top-level threads always have an annotation.

I believe that the design problems of how these types of thread cards should look can be tackled as a separate task.

Re-threading this way would allow us to sort chronologically, and could help us out in the Notebook view immediately (Notebook is always chronologically sorted, at least for now).

However, it does not solve the sorting-by-location/-selector challenge. As far as I can think of, we are out of luck on that without back-end changes that can never be retroactive. The data needed to anchor is just gone. We can discuss possibly showing these threads in the Orphans tab? I mean, technically, they are orphaned.

Summary

We could opt to leave the Sidebar as-is and do this re-threading in the Notebook only. We could put any or all of this behind a feature flag as we explore. The world’s our oyster.

I recommend that we explore options of rethreading to promote reply threads such that every top-level thread has an annotation, at least in some of the client’s interfaces.

...Discuss!

[klemay]

I think this sounds reasonable, and you have addressed my one area of concern:

When doing this re-threading on the client, we could still retain the metadata that Reply A, Reply B and Reply E have missing parents so that we could render them with helpful affordances (e.g. “This is in reply to an annotation that is no longer available” or similar).

+1 to explaining in the UI what's going on.

This is a really interesting possibility, IMO:

However, it does not solve the sorting-by-location/-selector challenge. As far as I can think of, we are out of luck on that without back-end changes that can never be retroactive. The data needed to anchor is just gone. We can discuss possibly showing these threads in the Orphans tab? I mean, technically, they are orphaned.

[dwhly]

Thanks for these various proposals. Agree that we can and should do better!

If there is no top-level annotation, maybe that’s not the top level of this thread anymore. Maybe one or more of its replies deserve a promotion.

My vote is "no" for the following reasons:

• It's semantically inaccurate. The replies are not top level annotations and shouldn't be promoted to be.
• It destroys information, namely that the replies were together, and all in response to the same thing. If there were two or more deleted top-level threads each w/ replies, then the promoted, disconnected replies would all intermixed, with no way to (easily, visually) determine which belonged to which original thread.
• The replies to a deleted comment provide important clues about the comment, and by reading a couple of them (conveniently grouped together) you can often guess about the original comment. Break them up and separate them and that becomes much harder.
• Even if they were marked in some way, I think the casual glance (from afar) might suggest that the promoted replies were somehow on the same level as other actual top-level annotations, and thus serve to confuse their actual place / status.
• It takes one single compact entity and fragments it into 2, 5, 10 or more individual pieces and then distributes them amongst other top level annotations like shrapnel.

We can discuss possibly showing these threads in the Orphans tab? I mean, technically, they are orphaned.

I think this is a fabulous idea (in the client)!

Which leaves us back at the question of: What should we do with them in notebooks and other forms of cross-document discovery and display.

Some options:
1- Leave them where they are at the top.
2- Force them to the bottom.
3- Remove them altogether.
4- Hide them behind a filter or a checkbox or a tab of some kind (similar to the concept above w/ the orphans tab)

Personally, I favor 4. I think generally that we should probably not clutter the screen w/ them, but we should make it clear that there are some deleted annotations, so that people can see them and their replies if they like.

My reasoning is severalfold:

• Since the top level is deleted, there is no info there, and there's no reason to clutter the display w/ a bunch of identical elements that all say "This message deleted".
• Since they are discoverable, people can see them if they want to.

[lyzadanger]

@dwhly

My vote is "no" for the following reasons:

Thank you! These are compelling, and I see your viewpoint.

Let's move forward assuming we aren't going to break threads up, then.

I want to muse some more on where these headless threads (I need a shorter term! Is this too morbid?) appear in sort order in different interfaces. My initial gut feeling is that I'd like these to show up "in flow" where possible, and not either all grouped together or obscured behind a filter.

We know we can't sort these into a list of threads sorted by Location. The only place right now that is sort-able by Location is the Annotations tab in the sidebar. In the sidebar, we're considering putting these threads into the Orphans tab, which is only sortable by Newest and Oldest—that gets around the Location-sorting conundrum. Same with the Notebook: only chronologically sortable (for now, at the least).

It think it would be keen if we could chronologically-sort these in flow. We could ostensibly do this by looking for the reply in the thread with the oldest or newest updated date. Does this sound plausible?

The visual design of what these look like certainly needs work. I'll explore that more once we work through where we'd like these threads to show up. Sound OK?

[lyzadanger]

I should mention that there are some long-term backend changes we could consider making that would aid us in this. When deleting annotations, instead of wholesale deleting the record, for those with replies, we could retain the minimal metadata required to reconstruct the original context: selectors and date, e.g. This would be somewhat in line with what happens if you delete a tweet, but could optionally not retain authorial information.

[robertknight]

We could ostensibly do this by looking for the reply in the thread with the oldest or newest updated date. Does this sound plausible?

Using the oldest created date is I think the closest proxy we have to the original annotation's creation/updated date.

we could retain the minimal metadata required to reconstruct the original context: selectors and date,

Also authorship information would be useful.