@JMinor

We can use the loading progress bar for article loading.

is the skeleton required?

The spec for loading bar is

• height: 3px
• color: wmf_blueTintColor

Checked with 5.0.0.519 on iPad mini iOS 8.2

Comparing with 4.1.7(171) - two things are different in alpha:

1. loading progress bar color is green in 4.1.7(171)
2. when a search is submitted, the previously displayed page slides left and a blank page with the progress bar appears - this is a more logical behavior(arguably) than in 4.1.7(171)

@Fjalapeno the article progress is still not painted for 0% to 70%

I think you are aware of this fix. putting it back into dev.

Checked with 5.0.0.534 on iPad iOS 9.1. The loading progress bar is blue. It displays the progress smoothly enough (check on large articles). For small articles, it may look as the bar jumps immediately to about 70% of length, but load times for such articles normally correlate well enough with the time when the progress bar reaches the end.

@Nirzar the loading indicator is actually just moving very fast. Because the article is downloading quickly.

In fact, for small articles, rendering time is usually longer than the download time (on fast connections). Also cached articles will be mostly rendering.

Right now the progress bar is set up to allow 80% for download and 20% rendering. We can play with those numbers. But unfortunately we don't know which articles will render fast / slow. (some people will have slow connections, some will have slow devices, some be memory constrained, some may be on wifi, etc…)

So for instance we could change the bar to be 50%/50% but we can't be "smart" about the progress bar (meaning give a proportional amount for download and rendering depending on the context).

One other thing we can do is increment the progress bar during the render process (even though we don't know the real progress) so at least the progress bar won't look "stuck".

So at this point it becomes a design / UX pick your poison thing.

Came up during talking to @Nirzar, but not mentioned previously:

@Nirzar noted that progress appears to be better on the old app.

@BGerstle-WMF and I looked into this and it appears that the progress being reported form the Apple Networking code is not very accurate progress anymore. This seems to be an iOS 9 change (meaning if you build the app for iOS 9).

This may seem odd that it would be broken now, but in reality apple never officially supported reporting progress for gzipped data (which is how our servers deliver the content). So really it is more of a fluke it was working in iOS 8..

Anyways - the solution seems to be now that we need to do a lot more "faking" of the progress rather than relying on actual progress.