@Pginer-WMF can you link to the indeterminate loaders that are being used in flow/CX please?

Here are some details:

• Live example
• Patchset from the Language team implementing it in Content Translation
• More details in this Trello card

This doesn't make much sense as a task for mobile apps. For system controls like loading indicators, it's much important to use the platform's built-in controls rather than making our own arbitrary ones, because our app should be consistent with other apps in the platform.

For example, the Android platform has the Toolbar class (which we use for our toolbar) which has a built in progress bar; that's the standard paradigm on the platform, and we'd need a really good reason to intentionally make our apps incompatible with material design.

@Deskana, There are other other in-page loaders that you see occasionally, are these all inherited from mobile web? As far as inconsistency with Material Design or iOS guidelines, I feel we've already settled on a look and feel that is wikimedia, rather than being platform specific. I know that we've made subtle platform adjustments, but overall we've diverged pretty far from each platform's design in order to have something that is unique to the application.

In T75972#848540, @Jaredzimmerman-WMF wrote:

@Deskana, There are other other in-page loaders that you see occasionally, are these all inherited from mobile web?

From the engineering perspective, we don't inherit anything about our UI from mobile web or desktop. It's nontrivial to inherit UI elements from mobile web for a variety of technological reasons. It's possible that they were designed the same way and therefore look very similar, however. You'd have to ask your designers about that. :-)

As far as inconsistency with Material Design or iOS guidelines, I feel we've already settled on a look and feel that is wikimedia, rather than being platform specific. I know that we've made subtle platform adjustments, but overall we've diverged pretty far from each platform's design in order to have something that is unique to the application.

Yes and no. We use material design icons in the Android app almost everywhere for things like search, table of contents, hamburger menu, etc. We also use an Android-spec progress bar for page load indication. For pretty routine operations like this, it means if someone's used another app on their phone then they reasonably know what to expect from ours. As mentioned, I would be reluctant to break that pattern.

In other places, we don't pay much attention to their guidelines (e.g. progressive action buttons in the editing workflow are not in line with Android). For editing I think that makes sense, because the editing workflow is so unique to our application.

But anyway, this is a pretty high level discussion. To figure out our next steps, could you say specifically what you're proposing we do in the iOS app and the Android app? Thanks!

sure, @Pginer-WMF has designs for an in-page indeterminate loading indicator, I'd like for us to consistently use this when we have in-page indeterminate loaders. On the app this could be… loading search results, long articles, large images, nearby lists, etc.

@Nirzar, didn't you at some point make prototypes of this indicator along with buttons? Is this same/related? Could you please add a link to that task?

@Prtksxna yes, here's my first cut http://nirzar.github.io/prototypes/ui/primary-button-loading.html

Over on T61699 I've got a hi-dpi update to jquery.spinner in MW core that doesn't change its design -- should I go ahead and try to land that as-is for now or wait on this design to replace it?

I changed from indeterminate to just a discussion of loading indicators so we can look at loading indicators as a whole. Documented here on MW: https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Use_cases/Loading_Indicators

From a conversation in Contributors Design meeting this week, let's declare the 3 dots animation our in-view loading animation.
One small amendment that we should be making is increasing the contrast slightly, from @colorGray12 (#c8ccd1) currently to #54595d in order to ensure visibility.
We can still revisit this later for improvements or alternative animation proposals.

In T75972#4417813, @Volker_E wrote:

From a conversation in Contributors Design meeting this week, let's declare the 3 dots animation our in-view loading animation.
One small amendment that we should be making is increasing the contrast slightly, from @colorGray12 (#c8ccd1) currently to #54595d in order to ensure visibility.
We can still revisit this later for improvements or alternative animation proposals.

I'm ok in increasing the contrast, but using Base20 (#54595d) seems a bit too dark for a non-interactive element that we want to communicate background activity. I made examples for Base20, Base30 and Base50. I think that Base30 (#72777d) could be a good option if we want good-enough contrast without attracting too much attention.

Ok, I think Base30 is a good compromise as long as designers are aware of the context and consider upping contrast if indicator is used on a dark(er) background in order to stay well recognizable for affected users.

A follow-up note on mobile app discussion at T75972#845549
Apps should make use of the OS specific loading indicators if any possible.

CodePen now also includes small variant and variant with inverted colors for dark background usage.

hi @Volker_E - here's an example on Growth of how we are using skeleton shimmer instead of the loading indicators due to the large area of content elements all being loaded at different times (Image, article title, extract, page views):