For reference: Termbox has something that is at least similar to what we want: https://tools-static.wmflabs.org/wikibase-termbox-storybook/?path=/story/indeterminateprogressbar--default

From the description:

@Charlie_WMDE also mentioned the idea to approach this in a more general fashion, e.g. always showing the loading indicator if a transaction which is known to by asynchronous (e.g. the "saving") takes longer than 1 second.

I'm not sure about the "takes longer than 1 second" part of this. Most often we don't know how long the request will take and if it takes only 1.1 seconds, this would result in the loading screen being visible for 0.1 seconds. Maybe there should also be a rule of "If we show the loading bar, then we show it for at least 0.75 seconds"?

@Michael you have a very good point, thank you for voicing it. After talking to the UX-colleagues I think it's the best idea to stick to the 1second rule, but make sure that we always show the loading indicator for at least 0.5 seconds.

the idea is to always add 0.2 seconds fade in and fade out at the beginning and end of the animation, which would ensure we always get 0.5 seconds in the worst case (worst case being the 0.1 seconds).

Is that technically possible?

In T232468#5575133, @Charlie_WMDE wrote:

@Michael you have a very good point, thank you for voicing it. After talking to the UX-colleagues I think it's the best idea to stick to the 1second rule, but make sure that we always show the loading indicator for at least 0.5 seconds.

the idea is to always add 0.2 seconds fade in and fade out at the beginning and end of the animation, which would ensure we always get 0.5 seconds in the worst case (worst case being the 0.1 seconds).

Is that technically possible?

Sure ⏱

During the task break down we discussed that there seems to be an interesting ratio between the effort it takes to use/show the progress bar and the animations mentioned.
This is particularly alienating as it was mentioned that it is hard to imagine how these animations/transitions look/feel like.
The more agile approach might have been to add the loading bar and then have dedicated feature requests to modify its animations/transitions if we realize that the look and feel leaves something to be desired.

@Pablo-WMDE that is what we agreed from from my side. We leave the animations out, see how it is, and only if neccessary add the fade-in and out. or are you referring to smth else?

There was some deployment lag due to technical problems, but this can now be witnessed on beta.

As mentioned in the daily, the drop shadow seems too large compared to OOUI. I didn'T manage to get the exact pixel sizes of both of them but hopefully you know where to find it.

Moving the ticket back to TODO so you can adapt the size of the box shadow to how it is on OOUI

In T232468#5705004, @Charlie_WMDE wrote:

As mentioned in the daily, the drop shadow seems too large compared to OOUI. I didn'T manage to get the exact pixel sizes of both of them but hopefully you know where to find it.

Moving the ticket back to TODO so you can adapt the size of the box shadow to how it is on OOUI

I just looked at OOUI's progressBarWidget code and there's no box shadow defined there. Termbox's IndeterminateProgressBar component has a box shadow defined as

/* offset-x | offset-y | blur-radius | color */
box-shadow: 0 3px 3px rgba( 0, 0, 0, 0.1 ), 0 3px 3px rgba( 0, 0, 0, 0.1 )`.

Do we remove the box shadow to match OOUI's style (and upstream that in Termbox) or do we keep it as it is in Termbox?

Hi @Charlie_WMDE,

thanks for catching this.
Am I right in assuming that we'll apply the change to both bridge and termbox?

Some archeology in termbox history reveals the drop-shadow was an explicit - last minute - requirement (an intentional discrepancy to OOUI) back in termbox. /cc @Hanna_Petruschat_WMDE @Tarrow

Thanks

I just talked to Charlie and Sarai, but give a quick insight on the reasoning of the box shadow for termbox. There indeed is no box shadow in the OOUI doc, but if you look at the progressbar in use, then you'll notice one. From a design perspective that makes sense as otherwise the grey outline of the progress bar could be confusedwith something from under the white overlay. If you figured 3px in Termbox and maybe 2px in OOUI I wont discuss on the pixel. I think it's important to have it aligned in production. If that means taing away a pixel from termbox. Do it.

So it looks like in production there's a shadow of 2px whereas termbox has 3px. After talking to @Hanna_Petruschat_WMDE we agreed to change the entire component to have a shadow of 2px for bridge and termbox. Thank y'all for your help!

Visual Editor was identified as the reference implementation.
Defined in https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/90bbfb56837a3b01b1238ec191af827dd0e0dde2/modules/ve-mw/preinit/styles/ve.init.mw.ProgressBarWidget-wikimediatheme.css#13

.ve-init-mw-progressBarWidget {
    ...
    box-shadow: 0 0.1em 0 0 rgba(0,0,0,0.15);
}

In T232468#5705662, @Charlie_WMDE wrote:

So it looks like in production there's a shadow of 2px whereas termbox has 3px. After talking to @Hanna_Petruschat_WMDE we agreed to change the entire component to have a shadow of 2px for bridge and termbox. Thank y'all for your help!

To sum up: we need to make the progress bar in Data Bridge and Termbox have the same shadow as the one in VisualEditor, right?

Change 554328 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: fine tune IndeterminateProgressBar shadow

https://gerrit.wikimedia.org/r/554328

Change 554331 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[wikibase/termbox@master] IndeterminateProgressBar: fine tune shadow

https://gerrit.wikimedia.org/r/554331

Change 554331 merged by jenkins-bot:
[wikibase/termbox@master] IndeterminateProgressBar: fine tune shadow

https://gerrit.wikimedia.org/r/554331

Change 554328 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: fine tune IndeterminateProgressBar shadow

https://gerrit.wikimedia.org/r/554328

This can now, again, be witnessed on beta.