Page MenuHomePhabricator

As a user I want to see article loading progress while I wait for an article to load
Closed, ResolvedPublic1 Story Points


For now, please just re-enable the standard progress indicator in the nav bar we had before. It should use the same tint color as other app elements.

We may replace with something new down the road, but this gets us something for beta.

Event Timeline

JMinor created this task.Nov 19 2015, 8:09 PM
JMinor raised the priority of this task from to Normal.
JMinor updated the task description. (Show Details)
JMinor added subscribers: JMinor, Fjalapeno, Nirzar.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 19 2015, 8:09 PM
JMinor set Security to None.


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
Fjalapeno edited a custom field.

Checked with 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 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.

JMinor closed this task as Resolved.Dec 15 2015, 11:09 PM

Thats too bad about not tracking progress of gzips. Hopefully they'll re-fluke it in a future revision...