Page MenuHomePhabricator

Illustrate loading
Closed, ResolvedPublic5 Estimate Story Points

Description

While the entity gets loaded, we show a very rudimentary "Loading..." text so signal to the user that bridge is still trying to gather all data needed to operate.

We probably want to make this more appealing than it currently is.

MOCKS

specs can be found here

mobile


mobile specs can be found here
Acceptance criteria

  • the loading indicator always has a minimum screentime of 0.5 seconds
  • The fade in starts after 1 second
  • look and feel of OOUI Progress bar (indeterminate)
  • add a semitransparent overlay (same as in termbox) immediately after the user hits save until the save is successful or results in an error message

notes:

  • might add a fade in and out later

Details

Related Gerrit Patches:
mediawiki/extensions/Wikibase : masterbridge: fine tune IndeterminateProgressBar shadow
wikibase/termbox : masterIndeterminateProgressBar: fine tune shadow

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 10 2019, 12:22 PM
Charlie_WMDE updated the task description. (Show Details)Sep 18 2019, 3:21 PM
Pablo-WMDE updated the task description. (Show Details)Oct 8 2019, 11:40 AM
Restricted Application added a project: Wikidata. · View Herald TranscriptOct 8 2019, 11:40 AM
Charlie_WMDE updated the task description. (Show Details)Oct 8 2019, 11:42 AM

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?

@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 ⏱

Charlie_WMDE updated the task description. (Show Details)Oct 16 2019, 3:37 PM
Charlie_WMDE updated the task description. (Show Details)
Lydia_Pintscher triaged this task as Medium priority.Nov 4 2019, 10:02 PM
Charlie_WMDE updated the task description. (Show Details)Nov 5 2019, 9:46 AM
darthmon_wmde updated the task description. (Show Details)
darthmon_wmde set the point value for this task to 5.

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?

Michael moved this task from To do to Doing on the Wikidata-Bridge-Sprint-9 board.Nov 13 2019, 2:55 PM

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

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?

Pablo-WMDE added a comment.EditedDec 2 2019, 2:22 PM

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);
}

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?

Charlie_WMDE updated the task description. (Show Details)Dec 3 2019, 2:08 PM
Charlie_WMDE updated the task description. (Show Details)Dec 3 2019, 2:59 PM
Pablo-WMDE moved this task from To do to Doing on the Wikidata-Bridge-Sprint-10 board.

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

Charlie_WMDE closed this task as Resolved.Dec 5 2019, 11:23 AM
Charlie_WMDE moved this task from To do to Done on the Wikidata-Bridge-Sprint-9 board.

looks good.