Note to myself:
This is where the iOS app handles the revision and different types of edit counts
https://github.com/wikimedia/wikipedia-ios/blob/32ca59d18352c20419605c6b469cc530f304948d/Wikipedia/Code/PageHistoryFetcher.swift

Looks like there's a REST API can be used on the page:
https://github.com/wikimedia/wikipedia-ios/blob/32ca59d18352c20419605c6b469cc530f304948d/Wikipedia/Code/PageHistoryFetcher.swift#L127-L144

Will ping iOS engineers for more information on that.

The API calls have been added to the project: https://github.com/wikimedia/apps-android-wikipedia/pull/3095

Hi @schoenbaechler
Could you please provide the information that how should we draw the graph? what's the x and y?

Hi @Tsevener
Could you please share us some information about showing the graph for the edit history page? What kind of data that the graph needs and what's the x and y? Thank you!

@cooltey Looks like we pull the monthly counts from this API call:

https://wikimedia.org/api/rest_v1/metrics/edits/per-page/en.wikipedia.org/Apollo_5/all-editor-types/monthly/20210209/20220209

We construct the graph only with the ordered array of the edit counts from this call. We ignore the date. We extract the minimum and maximum number of edits in this array, and those are considered the very top of the graph and very bottom of the graph points, as minY and maxY. Then we loop through all the editCounts and any Y position is calculated relative to these minY and maxY data representations.

All these points are spread out evenly horizontally, so the X value is calculated that way, i.e. (graph overall width / editCounts.length) * editCountIndex if we were looping through them.

Let me know if you have any other questions!

Thank you so much @Tsevener! We'll follow the same implementation in the Android app as well 🙂

@schoenbaechler
Give you a glance at the current status of implementation 😉

Have a question:
Do you think putting a static grid SVG on the back of the graph instead of drawing the grid programmatically is a good idea? It would save some time of investigating how to draw it dynamically and not affect the performance that much.

The cons will be the x and y lines may not be in the correct position of each data point.

@cooltey — we could try out an SVG and see how it works / feels like in action. what are the image dimensions that you need for it? an image ratio or dpi values would be appreciated. will create the file next week (I’ll be OOO on Monday and Tuesday). how does that sound?

Hi @schoenbaechler

Thanks, the dimension is: 128dpx128dp, and it sounds good to me :)

Please note that the data set will have 11 items, which will have 11 points in the graph, hope this information helps you.

Thanks @cooltey — I’ve added this to my todo list for this upcoming week — sorry for the delay

@cooltey — can you try these two? one uses a bit of a lighter grey (base90) and one a darker grey (base80). the grid’s using 11 columns.

Thanks @schoenbaechler 😄

Base 90

Base 80

Looks like the base80 is better and the grid looks nice! Now the APK is ready for review, please download the APK from the link in ticket description.

@cooltey — this looks amazing already!!

01) can you try this one just to see how it feels? it uses a little less lines?

02) also, can we make the graph slightly bigger? not too much — maybe ~ 10 to 15%?

03) and last thing — the title of the article should be bold

thanks

Hi @scblr, I have increased the size from 128dp to 140dp, which is the maximum size of the graph, otherwise, the "Revision history" title will become multiple lines.

@cooltey this is perfect — just checked out the apk! 👏

One question — is the article title using faux bold? It looks a bit odd compared to the 'Revision history' style above it? It might use some kind of unwanted letter-spacing as well? Thanks for checking!

Hi @scblr, you are correct, it is using faux bold. Now it has been fixed. Please check the latest APK.

@cooltey this looks great — here are a few (minor) improvement suggestions:

01) Can we use this space a bit more efficiently in landscape mode / on tablets?

Ideas:

• Stretching the graph horizontally to around 50% and adding more detail to the graph, e.g. by providing a separate grid svg for larger sizes?
• Scaling the graph (lock aspect ratio) responsively, e.g. 50% of the horizontal screen estate

02) The blue text should be clickable (a link to the Ukraine article in the corresponding language).

03) Can we add the article title to the app bar as well if there’s enough space? It’ll provide more context when users have further scrolled down.

Example: Revision history: Ukraine

Probably easier to implement: always show the article title in the app bar after 'Revision history' and truncate it with an ellipsis if there’s not enough space.

04) Are we using Roboto Medium, font-size: 16sp + line-height: 24sp for this? Seems like the line-height is different. Also, can the green label be on 1 line if there’s enough space?

05) Might be related to @Sharvaniharan’s work in T299178 — but it seems like when turning the phone to landscape mode the byte numbers disappear/reappear (flash) for a second. Can we optimize the behavior to always show the byte numbers? Here’s a video

https://www.dropbox.com/s/61iyn2rxypg6jch/screen-20220302-150255.mp4?dl=0

Thanks for the hard work! 🙌

Hi @scblr, I am still working on tweaking the title height while scrolling the list, please check the latest APK in the description.

In T299181#7747416, @scblr wrote:

@cooltey this looks great — here are a few (minor) improvement suggestions:

01) Can we use this space a bit more efficiently in landscape mode / on tablets?

Done, now it is 6:4.

02) The blue text should be clickable (a link to the Ukraine article in the corresponding language).

Done.

03) Can we add the article title to the app bar as well if there’s enough space? It’ll provide more context when users have further scrolled down.

Example: Revision history: Ukraine

Probably easier to implement: always show the article title in the app bar after 'Revision history' and truncate it with an ellipsis if there’s not enough space.

Partially done. Still optimizing it.

04) Are we using Roboto Medium, font-size: 16sp + line-height: 24sp for this? Seems like the line-height is different. Also, can the green label be on 1 line if there’s enough space?

Done.

05) Might be related to @Sharvaniharan’s work in T299178 — but it seems like when turning the phone to landscape mode the byte numbers disappear/reappear (flash) for a second. Can we optimize the behavior to always show the byte numbers? Here’s a video

https://www.dropbox.com/s/61iyn2rxypg6jch/screen-20220302-150255.mp4?dl=0

Done.

Ok wow @cooltey — these are amazing tweaks — the level of attention to detail in your implementation can be felt when using it 👏 😍 👏

Two questions:

01) I was just checking the implementation with the system language set to German. The German translation for revision history is 'Versionsgeschichte':

I was wondering, would it be possible to add logic that removes the line break (br />) revision history if we detect that both words use more than three lines together? In this case — we would make sure that space is used most efficiently in all languages. Let me know what you think?

02)

In regards to this 👇

Can we add the article title to the app bar as well if there’s enough space? It’ll provide more context when users have further scrolled down.

Example: Revision history: Ukraine

Probably easier to implement: always show the article title in the app bar after 'Revision history' and truncate it with an ellipsis if there’s not enough space.

Partially done. Still optimizing it.

You mentioned you’re still optimizing it — so maybe you have fixed these things already. This is what I currently see:

• I noticed that the label 'Revision history' is not using the correct language variable (e.g. it should be replaced with 'Versiongeschichte' when set to German)
• I think we should keep 1 line in the app bar (truncate with ellipsis) in order to not cover too much content vertically

I was wondering, would it be possible to add logic that removes the line break (br />) revision history if we detect that both words use more than three lines together? In this case — we would make sure that space is used most efficiently in all languages. Let me know what you think?

@scblr It would be extremely difficult and tedious to adjust widths/spacings/margins/etc based on word lengths. However, we do have a simple solution provided by automatic hyphenation. How would this look:

In T299181#7756138, @scblr wrote:

Ok wow @cooltey — these are amazing tweaks — the level of attention to detail in your implementation can be felt when using it 👏 😍 👏

Two questions:

01) I was just checking the implementation with the system language set to German. The German translation for revision history is 'Versionsgeschichte':

I was wondering, would it be possible to add logic that removes the line break (br />) revision history if we detect that both words use more than three lines together? In this case — we would make sure that space is used most efficiently in all languages. Let me know what you think?

---

It would be a great solution from what @Dbrant mentioned, which is to let the system add a hyphen to the long string if necessary.

02)

You mentioned you’re still optimizing it — so maybe you have fixed these things already. This is what I currently see:

• I noticed that the label 'Revision history' is not using the correct language variable (e.g. it should be replaced with 'Versiongeschichte' when set to German)
• I think we should keep 1 line in the app bar (truncate with ellipsis) in order to not cover too much content vertically

As we discussed in Slack and after I checked out two possible solutions, I would prefer to set the entire title to black color (without blue links), since the system cannot truncate the title if it contains blue links in it.

Please check the latest APK and let me know if you have any questions 👍

Hi @scblr, here are the design changes per our discussion, please let me know if you have any questions.

This looks good @cooltey, thanks for the hard work on this 👏

Looks good to me on 2.7.50400-alpha-2022-05-05