Page MenuHomePhabricator

Implement Loading State Support for Revision Details Pop-up in WWT [small]
Open, Needs TriagePublic

Description

As a WWT user, I want to see a visual indicator if the revision details pop-up is still loading data, so that I can understand that the data will appear soon.

Background: There may be times when the edit summary is still loading, since this is a separate data request. This ticket is meant to handle this behavior in a more graceful and responsive way. For the first iteration, we'll simply implement the loading animation in all cases (i.e. it will always appear before the edit summary). However, if this behavior is found to be awkward, jarring, or undesirable via testing, we will attach some more logic behind the display of loading animation (some of which is outlined in the comments below).

Acceptance Criteria:

  • If the the revision details pop-up opens, and if the revision has an associated edit summary, the pop-up should first display the loading animation (https://codepen.io/prtksxna/pen/OJLmVXZ) before the edit summary is displayed
  • Once the data has fully loaded, the content animation should disappear and only the data should be displayed

Visual Examples:

Note: This visual example is a screenshot that does not have the animation. View the requirements above for the link to the animation code (HTML, CSS, and JS) and example.

When loading occurring:

When loading complete (i.e. edit summary data displayed):

Event Timeline

ifried created this task.Fri, Aug 23, 7:44 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFri, Aug 23, 7:44 PM
ifried renamed this task from Placeholder: Implement Loading State Support for Revision Details Pop-up to Placeholder: Implement Loading State Support for Revision Details Pop-up in WWT.Fri, Aug 23, 7:44 PM
ifried renamed this task from Placeholder: Implement Loading State Support for Revision Details Pop-up in WWT to Implement Loading State Support for Revision Details Pop-up in WWT.Tue, Aug 27, 3:58 PM
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)Wed, Aug 28, 4:09 PM
MusikAnimal updated the task description. (Show Details)Thu, Aug 29, 6:19 PM
Prtksxna added subscribers: MusikAnimal, Prtksxna.EditedMon, Sep 9, 3:04 PM

Given that the edit summary could in some cases could load very fast (less than 100ms) we don't want a case where we flash the animation for a very small amount of time. I am taking some inspiration from the font-display browser behavior here.

  1. Don't show any animation for 100ms and if we have the edit summary till then fade it in.
  2. If don't have anything in 100ms, fade in the animation.
  3. Once we receive the data check if the animation has been playing for at least 500ms

    A. If it has (been playing for 500ms), fade it out and switch it with the edit summary (like in the codepen)

    B. If not, wait so that the animation has played for at least 500ms (since the animation started, not since we got the data), and then switch it with the edit summary.

If we do this we are giving the user the data a bit late in one case, but by doing that we are avoiding visually jarring jumps.

When was the data receivedWhen was the data displayed
In less than 100msAs soon as it arrives
More than 100ms less than 600msAfter 600ms of the popup opening (100ms empty + 500ms animation)
More than 600msAs soon as it arrives

Does this make sense for this case? What do you think @ifried @MusikAnimal?

In my opinion it's probably not worth adding all that specialized, potentially fragile logic for something as simple as a loading indicator. I think regardless you're going to get some jarring jumps, because we don't know how long the edit summary is, or if there is one at all. In all likelihood once it is displayed the size of the popup will change and appear to jump.

I would either always show a loading indicator, or none at all. I think no loading indicator may be acceptable; Loading indicators are of course great practice, but in general I don't think the user would get confused or upset if the edit summary suddenly appeared given they already have the important information they wanted, which is the author/timestamp and link to the diff.

aezell added a subscriber: aezell.Mon, Sep 9, 6:55 PM

I would agree with Leon here. Simplicity seems a smart tactic. Personally, I'd always show the loading indicator even if it disappears as soon as it's there. In my opinion, that's bomb-proof for those requests that might take a long time and much simpler than trying to guess how long something is going to take.

ifried added a comment.EditedTue, Sep 10, 1:02 AM

I agree that it's better to show the loading animation (rather than no animation at all). We anticipate times when the edit summary may take extra time to load. In such cases, it may be helpful to know that more data is coming, from a user perspective.

However, I think Leon made a great point about opting for simplicity. The option presented by @aezell ("always show the loading indicator even if it disappears as soon as it's there") may be easier to implement, although it's less responsive to changes. From a design perspective, what do you think, @Prtksxna?

I would agree with Leon here. Simplicity seems a smart tactic. Personally, I'd always show the loading indicator even if it disappears as soon as it's there. In my opinion, that's bomb-proof for those requests that might take a long time and much simpler than trying to guess how long something is going to take.

That was the original idea for the task (and codepen). During the estimation of the task I got the impression that this isn't ideal, maybe I misunderstood 🤔 As long as we know what the concerns were and and make sure that they're addressed I am happy to go back to the original 😊

ifried moved this task from Backlog to In progress on the Who-Wrote-That board.Tue, Sep 10, 8:36 PM

Background: We originally discussed adding loading animation when the edit summary is present in the revision details pop-up. This is because the edit summary may sometimes take a bit of extra time to load. Then, in a meeting with the team, we discussed the fact that: a) sometimes the edit summary will load slowly (so loading animation is desirable), and b) sometimes the edit summary will load quickly (so loading animation may be unnecessary or jarring). At that time, we thought we could think of a way to accommodate both scenarios.

Now, there is the open question of whether we should use the loading animation --and, if so, when? Do we always show it? Do we show it under certain circumstances?

My thoughts: We should use the loading animation, so that users remain informed regarding additional data. I also understand that the animation may be jarring in certain circumstances. However, we simply do not know until we test out the loading behavior. For this reason, I propose that we first implement the basic version of the loading animation (i.e. loading animation as default step in the process, regardless of loading speed). However, if we do find that such behavior is jarring or awkward to users in certain scenarios, we can pursue the plan outlined by Prateek (which is sensical to me).

ifried updated the task description. (Show Details)Thu, Sep 12, 4:29 PM
ifried renamed this task from Implement Loading State Support for Revision Details Pop-up in WWT to Implement Loading State Support for Revision Details Pop-up in WWT [small].Thu, Sep 12, 5:44 PM
ifried moved this task from To be estimated/discussed to Estimated on the Community-Tech board.