Make adding/editing/deleting comments as if they were instant

Resources

PM @victorwu | UX @dimitrieh | FE @kushalpandya

Description

• Make adding comments on issues and merge requests appear as if they were added instantly.
• Same for editing comments.
• Same for deleting comments.

Design

• Per https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_22751335.
• When you submit a comment, it appears automatically on the page, to the user.
• There may or may not be any spinner/loading UI. But the comment itself appears instantly, i.e.: https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_23034345.
• In the background, the comment is persisted to the system.
• If there is an error, there is essentially a callback, and an error message on the FE. If there is no error, nothing happens.
• If certain parts to the text need the server response, they are just updated afterward, i.e. https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_22719632.
• There should be a fade in for the comment, similar to: https://docs.gitlab.com/ee/development/ux_guide/animation.html#quick-update.

Original description

GL is slower than GH and BB at the moment. We are working on it. But in the mean time there are a few things we could do to make ourselves appear faster.

The main idea is to just do things as if they worked right away and show the status after.

For example. Take the comment as a first example.

This is the current way it works.

That slight delay is the difference between ok and awesome.

What if we just show the comment right away. Put up some sort of small status to show it is loading. Add the tiniest little animation to show it going into place.

The idea that it already went through I think is more satisfying then waiting for it to go through.

We would need to render markdown in JS to do it.

It's the difference between stopping someone from doing something and allowing them to do something.

Start with comments.

cc @awhildy @tauriedavis @iamphill @fatihacet

There are many things in GitLab UI that can be improved to get GitLab UI works faster.
This proposal is one of them.

Some thoughts can be found in #27549 (closed).
Related issue: #22921 (closed) Show current user immediately in filters

Thanks for creating this! According to what I see it seems GH dropdowns are prebuilt before send it to the user. That's why they work instantly because it doesn't need to fetch any nada. Not sure if Droplab can actually support dropdowns like that.

If we are going to built the dropdown on the server we need to figure out a way to cache the dropdown HTML or at least the data it needs so the page response doesn't get compromised by this.

-- edit:

Actually GH fetchs the dropdown HTML when placing the cursor over the dropdown (very clever)

Rendering the markdown will be easy to do, but how do we render the references? ie. the backend knows that !1239871247 isn't a merge request, but how does the frontend? Or do we just render it as best as possible without any reference links & then replace with what the backend sends us?

In terms of showing status, part of me would rather just assume it works in the UI, and only show something the moment there is an error. It feels more confident to the user to say We know something is wrong vs. We are still working on it. I feel like at the timescale we are talking about, showing status may be a little bit if a distraction.

However, I'm not sure about this perspective. Thoughts @tauriedavis?

(Also, I this issue, @jschatz1!!!!)

I'm not sure I understand @awhildy. Are you talking about showing a loading indicator before the comment fully loads? I assumed this issue was to make the UI feel faster, even though it's not. Rather than to let the user know that it is working. Its all an illusion But let me know if I'm missing something

I was responding to this detail in the description:

What if we just show the comment right away. Put up some sort of small status to show it is loading. Add the tiniest little animation to show it going into place.

I don't think we should show a loading indicator before a comment fully loads. Just have the illusion, and show something only if there is any sort of error. I think we might be on the same page?

Sorry, I'm still slightly confused. What would the illusion be that youre thinking?

No problem. Sorry I'm not being clear. My understanding from this issue is that we would instantly show the comment on the page the instant you say 'submit'. This comment we are showing is kind of 'faking' it, as we haven't actually sent it to the BE yet. So, at the same time as instantly showing the comment, we initiate the round trip with the BE to actually submit the comment. Once we hear back from the BE, the comment is no longer fake, but real. Or at least that is how I'm understanding it.

From the above description, I thought the proposal was that while we are showing the fake comment, we could show some progress indicator to show that we are still actually submitting the comment to the BE. My thoughts were that instead, we show the fake comment just like it worked, and only show an error if we hear an error back from the BE.

The benefit with this is it feels really fast in the majority of the time that it works, without any distraction of quickly popping something to show status. The potential concern here is if the user navigates away and doesn't see the error, and thinks they successfully submitted the comment. I think we are talking about half a second here, which is partly why I don't want to flash a progress indicator. But there are really subtle ways we could explore (like how the Facebook apps will use a slight gradient animating on the header). So I'm on the fence with this one.

(That is if I'm understanding it at all correctly. )

We can't show correct comment link in commented xxx minutes ago title because comment id is global around the whole Gitlab instance. So, that link is not really usable until backend sent the actual comment id.

My vision about how to solve this problem:

Add internal comment id for each issue (#18264 (closed)) and check the last comment id in the background while an user types his comment. The chance there are two or more people are typing comments to the same issue is much lower than two or more users are typing comments to some issues in the whole gitlab instance. Especially on gitlab.com

or

Render that commented xxx minutes ago title but without any URL link. And when backend sends the real comment id, JS will add <a href=... tag to the title.

Ahh, yes, I understand! I think we are on the same page. Thanks for clearly writing that out for me @awhildy :) I'm curious about the fb's gradient you mention. I see this loading indicator from Jacobs example which is what we may be trying to avoid. Do you have gif of the gradient method?

@blackst0ne I would just leave the commented text without a link until the backend sends the real comment. It is a lower likelihood that two people type comments on the same issue than of the whole gitlab instance but it does happen.

@tauriedavis - Might have been thinking of Facebook's Paper app. Two examples:

Glossy titles

When the new section is loading, the title text has this gradient effect while it is loading

Loading placeholder

Maybe less applicable, but just putting it out there. Loading an update from a placeholder

These indicate something is happening without having to add another element. Just wondering if there is a way for us to do that.

(Also, just to share, an interesting article I just found about handling time perception in UX: https://medium.com/swlh/the-illusion-of-time-8f321fa2f191#.s5m7vs726)

@awhildy What do you mean is there a way for us to do that?

@jschatz1 - Nevermind. I tried animating the shine effect, and didn't like it in this context. I think you were right initially with showing a little spinner until it is submitted. Sorry about sidetracking the conversation!

Here is a rough version with the spinner to illustrate it quickly. Thanks!

mentioned in issue #29666 (moved)

changed title from Make feedback instant. to Make adding/editing/deleting comments as if they were instant

added ~874211 ~897282 to schedule labels

changed milestone to %Backlog

@tauriedavis @jschatz1 : Let's consider this for 9.2. I updated the description to limit to just comments.

@tauriedavis : Can you verify the fade in is consistent with what we want for GitLab as a whole. I see "quick updates" here: https://docs.gitlab.com/ee/development/ux_guide/animation.html#quick-update. But is there anything for things just appearing?

added ~19492 label

removed milestone

changed milestone to %Backlog

This can apply to other parts of gitlab too, like changing sidebar fields. But let's start with comments.

changed milestone to %9.2

removed ~897282 to schedule labels

Yes, I don't think the guide has more complex transitions like seen here https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_23034345

The reason is because the content is added, rather than updated and the guide only mentions transitions for updated content.

@dimitrieh Do you want to work on the transitions for added content with frontend?

@tauriedavis @victorwu sure! What exactly needs to be done here still. https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_23034345 seems great to me!

Or is this about updating the ux guide to have animation specifics on content being added/removed in a more general sense?

The best resources on this currently are:

• https://www.youtube.com/watch?v=6p3i6H2oGa0
• https://material.io/guidelines/motion/material-motion.html

especially choreography comes into play here:

• https://material.io/guidelines/motion/choreography.html#

With addition for this example we need to think of it like this:

1. fade content out
2. load content into new correct element while the original content is fading out, but do so fully hidden
3. fade content in (in new correct html element)
4. While the content is being faded in, it needs to be moved up to the correct place. 5 .the last 2 steps end near at the same time.

With deleting we need to think of it

1. fade content out
2. put overlaying gradient on the content, while the content is being faded out, with the opaque color in the direction the content will flow into its place once deleted. This will have a fade-in and move gradient animation of it own
3. While the gradient is being faded in, the other content will begin to move up
4. all steps conclude in rapid fashion at the same time.

These are just some steps to describe it, if we are really going at it. We have to see to which degree we can make this work.

Who can i work with this on front-end?

added Deliverable label

Thanks @dimitrieh for the references.

This is scheduled for 9.2. @jschatz1 will be likely be assigning FE resources closer to 9.2.

We are looking for a final UX design as we start development. If you think https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_23034345 is that final design spec, that's great. Can you comment on the spinner and that interaction in that case.

assigned to @kushalpandya

@kushalpandya will work on this. He can start early if he has time.

@dimitrieh : Regarding the UX guide, I'll let you and @tauriedavis discuss that separately. Thanks.

Thanks @dimitrieh for the detailed comment! I agree that we will have to see which degree to make work and that the bulk idea is ready for frontend. Once you and @kushalpandya fine tune the animations, we can add the finished product to the ux guidelines for reference in the future :)

With addition for this example we need to think of it like this:

1. fade content out

2. load content into new correct element while the original content is fading out, but do so fully hidden

3. fade content in (in new correct html element)

4. While the content is being faded in, it needs to be moved up to the correct place. 5 .the last 2 steps end near at the same time.

With deleting we need to think of it

1. fade content out

2. put overlaying gradient on the content, while the content is being faded out, with the opaque color in the direction the content will flow into its place once deleted. This will have a fade-in and move gradient animation of it own

3. While the gradient is being faded in, the other content will begin to move up

4. all steps conclude in rapid fashion at the same time.

@kushalpandya what do you think of the feasibility of https://gitlab.com/gitlab-org/gitlab-ce/issues/27614#note_23034345

Will it even need the loading spinner animation?

@dimitrieh Are you referring to the way all comments slide up when new commend is posted? I doubt if it is feasible from performance point of view, since currently we append a new comment to the list and comment box moves a step bottom (which isn't resource intensive for browser to render).

I was thinking if we reduce entire comment block opacity to 80% until it is actually posted and then set it complete opaque, this is already done in Facebook comments and within messenger, and this way we can avoid spinner completely. I'll any way have something put together for you to see in next week once we're past %9.1 timeline.

@kushalpandya seems great to me! let's do that and see how it feels

mentioned in merge request !10760 (merged)

just a small heads up: I will be off and on next week.. (See availability calendar) if so please ask someone from the UX team for any additional details might be needed

@kushalpandya removing UX for now

add it back when you need help as well ;)

mentioned in issue #31374 (moved)

closed via merge request !10760 (merged)

mentioned in issue #3710 (closed)

mentioned in merge request !11134 (merged)

mentioned in merge request !11240 (closed)

mentioned in merge request !11612 (merged)

mentioned in issue gitlab#9441