Comment cards are too wide

[laurentlb]

When I use vscode fullscreen, with a single editor, the comment cards can be too long and get awkward:

Also, when a comment is long, it can be difficult to read a very long line.
Both problems could be fixed by using a maximum width for comment cards.

cc @albertelo

[albertelo]

cc @misolori & @daviddossett

[daviddossett]

Is the mouse movement the issue? Or is it that you're having difficulty noticing the actions in the first place? It's worth thinking about how often comments are really edited and deleted in this context.

It could also be worth exploring bringing those right-aligned actions closer to the main content. E.g. next to the timestamp. However I'd be somewhat wary of moving them there given the added noise.

[laurentlb]

One issue is that we have other actions in the top-right corner. We are putting them there because it's the only place to have actions that affect the comment thread.
I think the situations would be better if the actions were moved to the left. Multiple users didn't see the icons on the right.

[miguelsolorio]

It's worth noting that this applies to all of our peek views as well since they are using the same widget/style. We'd want to have our header actions consistent but the individual comments can be responsive and align closer to the text and then stick to the right when the text is wider and the view is shorter.

[albertelo]

One issue with responsive behaviours and big screens is that a comment that is long will be rendered in a way that makes it hard to read. For example, a card with a 1200px width would fit 25 words (169 characters) in a single row, which makes it harder to read:

Reducing the width would improve readability

[daviddossett]

Ok, seems like there are a couple of related issues here. As @misolori pointed out, the parent widget (incl. header actions location) itself should likely remain as is given that it's shared across a bunch of components and scenarios.

Do you have anything specific in mind for improving the comment actions and line lengths? Open to ideas here 👍

[miguelsolorio]

A short term solution would be to place a max-width on the comment section, cc @alexr00 for thoughts on this:

but ideally a shorter container would look better:

[albertelo]

I'm guessing this breaks the parent component, but you could also add the icons to the right of the time stamp

@daviddossett: besides placing a max-width to the comments or the container, if there's a chance to edit the component like Miguel proposed then that's a reasonable solution IMO

Is it possible to treat the comment card as a different component than peek views?

[daviddossett]

I'm guessing this breaks the parent component, but you could also add the icons to the right of the time stamp

Another potential drawback: it also means the actions are jumping around depending on the username/timestamp.

but ideally a shorter container would look better

I think it looks slightly strange to limit the size of the container all-up given the precedent set by other peek view-style experiences:

Limiting the size of the comment body itself seems visually a little bit cleaner:

Actions would render as such:

[laurentlb]

Limiting the size of the comment body itself seems visually a little bit cleaner:

Note that there are actions on the top-right corner:

If we limit the comment body and keep those icons on the far-right, they'll be easy to miss.

[daviddossett]

That's the tradeoff here. Moving the header actions is a larger change that affects all Peek views.

Are there other actions exposed here beyond collapse all comments/collapse?

[laurentlb]

Yes. It's the main extensibility point for custom actions (provided by extensions).

If we find a way to provide actions somewhere else (could be next to "Reply"), that would work very well, IMO.

[alexr00]

#150824 (comment) would break the consistency of comments with peek views so I would prefer to explore other options first.

Since the issue we have is discoverability of the comment thread actions are there any treatments we can give to the actions that will draw more attention to them rather than changing the width of the peek view? Maybe a border or a background color?

We could also add better styling here for actions that don't have an icon. Using icons for actions generally can impact discoverability, so offering a well styled way to use the title of the command will certainly help.

Finally, for comments it might be nice to have all these actions in a context menu on the whole comment peek view. I don't think I'm the only one who will right click on things to see if there are some actions I don't know about.

If we have this problem with comment thread actions, we might also have this problem with other peek view actions. Solving this for comment threads could be beneficial for other peek views.

[hermannloose]

Side note: since @daviddossett asked about mouse travel as an issue in #150824 (comment), I wanted to give some context that we currently have a "quick reply" action / command there in our extension, to easily mark a thread as resolved while not having to manually type out a reply. As @laurentlb pointed out, it's the only contribution point for actions relating to the thread (vs an individual reply / comment).

That means even when users know where the actions are found and the comment contents happen to be short and don't run into readability problems through long lines, usability will suffer on large screens because this combines a large amount of mouse travel with a small click target that requires precision (i.e. in direct conflict with Fitts's law, so likely independent of the user's concrete input method, physical mouse vs trackpad, or pointer speed / acceleration settings).

[stariolo]

I'm Mariana, UX designer from Critique team (Google).
Thanks for all the context provided on this thread.
The proposal from misolori about having a "shorter container" looks very good.

1. What is the downside if this affect other peek views?
2. Can we adjust this weight to the length of the code and make it optional to make it full-width? My guess is that "Comments" feature is not the only "peek view" that has this issue. So why not make it optional?
3. Keeping buttons in the right side in large screen affect productivity and focus time because of the mouse travel time necessary to reach an action. Moving them next to "time stamp" might solve the issue but how this will affect other "peak views"? We will also need to solve the issue of one long line of text that are hard to read.
4. @alexr00, About placing the actions in a "context menu". Do you mean placing them behind a 3 dots menu? Because that will add an extra click for common actions and will add discoverability issues.

Thanks!

[miguelsolorio]

It's worth noting that having the window maximized on a large monitor does make the entire experience harder to use, not just for comments, for example in the panel:

I actually don't know how many people keep their windows at this size so let's take a look at the telemetry first to see how many users it's impacting and then we can go from there. We're all so focused on the comments/peek widget but there are so many other similar issues that I would be afraid to create a solution that only solves for a single area while making others inconsistent.

[daviddossett]

I did some digging into our telemetry to get a rough sense of window sizes across our active users:

Percentile	Width
Average	~1403px
50th	1366px
75th	1,713px
90th	1,920px
95th	2,133px

Seeing that data, my sense is that while this is indeed a challenge on really large screens, it isn't something that the vast majority of users are likely struggling with. Panels toolbars, Editor toolbars, and other areas all have a similar challenge on very large screens.

That's not to say I would dismiss this is as an issue. @misolori: thoughts on adding an exploration item to our UX backlog to explore how we might adapt this sort of challenge (i.e. right-aligned actions) to much larger screens?

[stariolo]

It's worth noting that having the window maximized on a large monitor does make the entire experience harder to use, not just for comments, for example in the panel:

I actually don't know how many people keep their windows at this size so let's take a look at the telemetry first to see how many users it's impacting and then we can go from there. We're all so focused on the comments/peek widget but there are so many other similar issues that I would be afraid to create a solution that only solves for a single area while making others inconsistent.

I agree, even that screen is displayed is inconsistent with the rest of the interface. I guess they decided to center the context and place a fixed width to avoid the current problem we have with comments.
Should we find a solution for components/features that have actions in the right side? This will be beneficial for the whole Design System.
@daviddossett about your data, that means that around 10% of users are having this issue, right? The average can be bigger because some user might decide to reduce the size of the window in order to avoid this kind of issues and inconsistencies across the UI.

[daviddossett]

I agree, even that screen is displayed is inconsistent with the rest of the interface

That UI belongs to an extension FYI. I think that screenshot is better used as an example for the panel and editor actions being far away in the top right and bottom right, respectively.

They might be reducing the size, but I'd venture a guess that it would be a minority statistically. We've added this effort to the UX backlog so we can do some explorations to solve for this beyond just the Peek view. We would love any ideas in the meantime!

I wonder what other apps have solved for problems like this? Here's a great example from Slack where they keep common actions right aligned despite the large screen width. It would be great to learn how and why different products solved for this—or why they let it be.

[Aryan-Koul29]

I am new to open source contribution field and I think this is a good issue that I can start with. So can you please assign me this issue?

[alexr00]

@Aryan-Koul29 thank you for your interest but this is not a good issue to start with as we do not want to make a one-off change for comments and instead would try to solve this for all editor zone widgets. Please see https://github.com/microsoft/vscode/wiki/How-to-Contribute#where-to-contribute for guidance on where you could start.

[Aryan-Koul29]

Okay! Thank you mam for the help.

[JonasMa]

I had another look at this and wouldn't consider this a problem of the top 10% of screen widths. This comment on an average width editor is quite wide and already.

Our users tell us on a regular basis that they are having problems with this, seemingly independent of screen size.

Are there any plans to move forward with this?

[alexr00]

Closing as no changes are currently planned.