How should Compare View work?

[iHiD]

Hello 👋

We're adding a "Compare view" to mentoring mode, and we want to understand how it's most useful to people.

Our working thinking is to be able to compare the currently selected iteration, with some previous iteration to see what's changed. However, there are a few things we need to know to work out how best to present this.

Which of these are important and which are most important:

• Seeing the comments you made on the "currently selected" iteration.
• Seeing the current conversation on the "latest iteration"
• Not seeing comments and thus having more space for comparison
• Being able to author comments while looking at the diff.
• Having side-by-side diffs
• Having intertwined diffs

Please list out the points from the list above that are important or preferable to you, and order them in terms of priority. You can also add other things that are important if not covered above. We can then ask questions about your thoughts in the nested replies.

As an example, here is one version with one set of tradeoffs:you are locked into a specific "currently selected" Iteration 3 (using the nav at the top). The comments on the RHS are for Iteration 3. You can then switch which iteration it is compared to using the dropdown on the LHS (set to Iteration 2). The diffs are intertwined. The new comment box is in the context of the Iteration 3.

(I'm not really after this design being critiqued at this stage - it's more for inspiration about how this might work if people felt the above things were the right tradeoffs)

Thanks 🙂

[BethanyG]

• Seeing the current conversation on the "latest iteration"
• Being able to author comments while looking at the diff.
• Seeing the comments you made on the "currently selected" iteration.
• Not seeing comments and thus having more space for comparison
• Having side-by-side diffs
• Having intertwined diffs

1. I tend to focus most on the latest iteration, unless I need to go to other previous ones because the current code has substantially changed and I need to remember the context. This happens a lot with something like markdown where code is being refactored. Sometimes, a student will upload several iterations before I get to them - so that would be a scenario where I might visit and comment on several iterations. But I think for me the "happy path" is the current covo in the "latest" iteration.

2. I'd want to see code while writing my comments - it doesn't have to be the diff, but looking at a diff would be nice.

3. Having a way of getting comments out of my way until I needed to make/amend them would be cool - a show/hide, so I could really focus on the code. But if it was a strict trade-off, I'd want to be able to comment and see the code at the same time.

4. Agnostic about side-by-side vs intertwined. Either would take some getting used to as opposed to the plain code. I'd work around UI choices here - I don't have a really strong opinion.

One thing that I've found I really like in GitHub is the ability to attache a comment directly to a line or block of code during a PR review. A similar functionality - where I tag a line/block, and it puts a copy of that in the comments for me, or a note directly below the line of code might be nice -- but not really necessary.

[iHiD]

One thing that I've found I really like in GitHub is the ability to attache a comment directly to a line or block of code during a PR review. A similar functionality - where I tag a line/block, and it puts a copy of that in the comments for me, or a note directly below the line of code might be nice -- but not really necessary.

We have this 🙂 It won't be physically attached, but you will be able to reference the code through a click and have it nicely displayed. We want a single conversation flow centered on the messages two people are conveying, rather than mutliple conversation threads on different LOCs, which is why we've decided not to visually inline the comments to the code.

(If you want to dig into this more, could you open a new discussion for it pls? Happy to bounce it further (!!) but I don't want to detract from all the other useful points on the "diff" stuff of this discussion :))

[wneumann]

Seeing the comments you made on the "currently selected" iteration.

This would be the most important thing for me, so I can refresh my memory of where the conversation was leading up to the current iteration, and to see if those comments have actually been addressed. Comments on the latest iteration might be nice for some, but I rarely see a lot of discussion on any single iteration.

Having side-by-side diffs

I prefer side by side diffs, but then the comments really need to go either above or below the diffs, and I'm not sure how well that would function. I'm sure I can work with either.

I also strongly concur with Bethany on the ability to directly link a comment with a chunk of code. It would save a lot of typing in some of my comments.

[bitfield]

This looks nice! Here's my priority order:

1. Seeing the current conversation on the "latest iteration"
2. Seeing the comments you made on the "currently selected" iteration.
3. Having intertwined diffs
4. Being able to author comments while looking at the diff.

Not important to me:

Not seeing comments and thus having more space for comparison
Having side-by-side diffs

[bitfield]

Essentially, this is what I look for, in order:

1. Did they make the changes I asked for in the previous iteration(s)?
2. What changes do I need to suggest for the current version?

[iHiD]

@taiyab These two points ^^ are probably a great two things to sanity-check everything we do in this UI against.