@JMinor @cmadeo Just a heads up I've updated this task description with remaining data and display questions I have at the moment. We can go over them today in sync.

@Tsevener sorry for the delay in responses.

We need business logic for when to show the "New changes" badge. How long since the latest revision was made?

Would it be possible to know when the user last loaded the article?
If so, then I think we can use the "New changes" badge whenever there is a change on the article that they haven't seen.

If not, then let's try only showing the badge when the most recent significant change is less than 24 hours old.

Is the expectation that the scroll-to-highlight functionality highlights ALL added text in the article, or just the snippet (which I am banking on being the largest line change detected in the endpoint) that is displayed in the timeline modal view?

If possible it would certainly be cool to highlight all of the text added and scroll to the first change. That sounds pretty expensive though, so let's do what you're suggesting here which is to highlight just the text added in the largest snippet added (eg. what would be shown in the timeline)

Just a note that the tap to highlight is the largest remaining unknown on if we can accurately detect these changes to highlight in the article content. We may need to cut this or save it for last and just focus first on detecting and displaying the types we want in the modal.

Totally understandable, I think that we can fall back on tapping the link leading to the timeline view scrolled to that event.

Would it be possible to know when the user last loaded the article? If so, then I think we can use the "New changes" badge whenever there is a change on the article that they haven't seen.

@cmadeo sorry for the delay - yep this should be possible. I'm basically going to return a SHA from the endpoint representing the latest revision in the timeline which I will persist on device. If that SHA changes on the next fetch, I'll show the new changes badge.

@cmadeo @JMinor Just a heads up, we might need a loading state for this article content insert. For now I'm going to hide all of the web view until the insert properly injects and we can see how slow it feels, but a better option may be to add some sort of placeholder loading insert instead. Here's how it looks now (without any web view hiding).

Ah, yeah we'll definitely need something. Let me work on some ideas today. Also -- curious how this will effect the 'Recently updated' badge at the top, is that by any chance something that could load at the same time as the body text @Tsevener ?

@cmadeo Yeah the recently updated badge will load and pop in at the same time as the card insert. Here's a few videos I took of how it's looking:

Without web view hiding: you see it jump a bit once it comes in. If a user is scrolled down their content will appear to shift.

With web view hiding: short load - this is mostly what it looks like when I test in simulator.

With web view hiding: long load - occasionally I see it take a long time, these are probably situations where it's not cached on the server or there's a lot of revisions for it to go through:

Thanks for these gifs @Tsevener!
I think we'll definitely want to have a tiered loading state where we wait to show the web content until the badge/card are loaded unless it hits an upper time limit, in which case we'll load the web (article) content and then have a loading state for the badge/card.

Before getting started for a design for this longer loading state. Do you think that it will be possible to utilize a skeleton loading state where the badge and card will later be shown? This would hopefully stop the 'jump' that occurs in the current without web hiding approach.

@Tsevener Here's a kinda rough version of what a skeleton could be like. It'd be awesome if we could have a bit of a shimmer effect to show that it is loading.

Before getting started for a design for this longer loading state. Do you think that it will be possible to utilize a skeleton loading state where the badge and card will later be shown? This would hopefully stop the 'jump' that occurs in the current without web hiding approach.

@cmadeo We could, although particularly with the badge, we won't know if it's considered new or not until the response fully comes in - if our device persistence hasn't seen the latest significant revision from the endpoint yet the new changes badge shows. So with the skeleton we will have the opposite problem, it won't jump if ultimately there is a new change, but if there isn't it will go away and jump back to a non-badge state.

That's less of a problem with the insert because all of the logic for whether it'll show can be determined before the response comes through - i.e. if they are on an EN wiki, LTR, and those particular articles we will be running the experiment on. I do have an error case where I don't show any badge or insert if there's been an error fetching the endpoint. If this response takes a while, shows the skeleton, then the endpoint fails, should we also show some sort of error state in place of the insert?

@cmadeo I still need to tweak spacing and font sizes, but here's a look at the colors I chose for theming. Let me know if you'd like to make any changes with these.

@cmadeo One last question I have at this point - these events can happen across multiple days, and if they are further in the past they switch from a relative timestamp to an actual timestamp. I re-used the History cell timestamps for this logic, but I could make them entirely relative if you'd like...i.e. 3 days ago, 2 weeks ago, etc. Would you like me to make them all relative, or would you like to keep the switching to a GMT timestamp? If you want them switching to GMT, we will probably want to add in a day/date too, as it's not apparent that these events are happening across multiple days.

@Tsevener, thanks! Responding inline:

@cmadeo We could, although particularly with the badge, we won't know if it's considered new or not until the response fully comes in - if our device persistence hasn't seen the latest significant revision from the endpoint yet the new changes badge shows. So with the skeleton we will have the opposite problem, it won't jump if ultimately there is a new change, but if there isn't it will go away and jump back to a non-badge state.

Ah, good point. This is making me realize that maybe we want a badge on any of the Living Doc articles (for consistency). If the article hasn't been recently updated we could just have a rough time stamp of when it was last updated.

If this response takes a while, shows the skeleton, then the endpoint fails, should we also show some sort of error state in place of the insert?

In this case could we remove the skeletons and show a toast message?

In T257595#6499001, @Tsevener wrote:

I still need to tweak spacing and font sizes, but here's a look at the colors I chose for theming. Let me know if you'd like to make any changes with these.

These are looking great (color-wise), Toni!

In T257595#6499039, @Tsevener wrote:

@cmadeo One last question I have at this point - these events can happen across multiple days, and if they are further in the past they switch from a relative timestamp to an actual timestamp. I re-used the History cell timestamps for this logic, but I could make them entirely relative if you'd like...i.e. 3 days ago, 2 weeks ago, etc. Would you like me to make them all relative, or would you like to keep the switching to a GMT timestamp? If you want them switching to GMT, we will probably want to add in a day/date too, as it's not apparent that these events are happening across multiple days.

It'd be awesome to make these all relative (3 days, etc). Thanks for checking!

Ah, good point. This is making me realize that maybe we want a badge on any of the Living Doc articles (for consistency). If the article hasn't been recently updated we could just have a rough time stamp of when it was last updated.

In this case could we remove the skeletons and show a toast message?

Yep, I think both of these are doable. Thanks @cmadeo!

https://github.com/wikimedia/wikipedia-ios/pull/3721