@scblr For the updated diff view user buttons (and generally all UI elements we display) we need the semantic color name to use to color the elements.

A little recap on iOS's theming – we define 4 main themes in app: light, sepia, dark, and black. Each of these themes then have lots of semantic color property names (baseBackground, paperBackground, link, etc.). Each of those semantic names then maps to specific colors from the style guide (like gray800 aka #F8F9FA). The reason we structure it this way is because it allows really easily re-theming the app when the user changes their theme. We don't need to maintain multiple lists of colors to use per UI element per theme, but instead define it all in one place and rely on a semantic name that will then appropriately color the element based on the user's theme.

So our ideal case design need for each element we display is that we need to know the semantic color name(s) to use to style it (e.g. this button's text uses the semantic color name link, its background is the semantic name midBackground).

On the code side, we currently define app used colors here. Here's an example from that file:

@objc public var baseBackground: UIColor {
    switch identifier {
    case .light, .widgetLight:
        return .gray200
    case .sepia:
        return .beige400
    case .dark, .black, .widgetDark:
        return .gray800
    }
}

To break apart this example code snippet above:

1. The semantic property name here is baseBackground
2. For the light theme, we map to the style guide color value for .gray200 (which itself maps to #EAECF0)
3. For sepia, we use color .beige400
4. For dark and black, we use .gray800

I'm not sure where the definitive guide for the theme/semantic name/color mapping exists on the design side, Carolyn and Olga might have more info.

@Deepak thx for the context. Can you reuse the color definitions from the compare revision screen for the new buttons? (without the border)

In addition, I added a new color annotations section to the task based on @cmadeo’s color master table (Figma)

Color annotations

I also added these to the other Watchlist tasks (T335816, T335606). Hope that helps. I’ll be OOO starting tomorrow for a week. Please ping Carolyn if you have more color usage questions.

PS: In an ideal, component-based future world, all these designs would have been created with components that are already defined. This is an attempt from my end to not block you on work next week (when I’m OOO), and Olga and I get to sync.

@scblr @OTichonova Want to confirm some behavioral things:

1. I'm unclear about the line "The new diff design will replace the existing edit detail that’s used within the revision history" – is this updated diff view intended to replace not only the current Compare Revisions view but also the Single "Diff" view? For shared vocabulary, we have:
   • Revision History view - primary list of all available revisions/changes
   • Single "Diff" view - view the information related to a single revision/change
   • Compare Revisions view - view the changes between two revisions/diffs

2. Another line I'm hoping for clarity on "Next/previous: Navigating through edits works as currently implemented in the revision history" - as currently implemented, navigation through revisions/changes in the Single Diff view via the next/previous buttons takes you to the next or previous revision/change in the Single Diff view. Is this the expected behavior?

Thanks @Deepak for digging into this 👷‍♂️ 🚧 – these are great questions, and here are some answers:

1)

is this updated diff view intended to replace not only the current Compare Revisions view but also the Single "Diff" view?

Yes, to this! When working on the Android version, @Dbrant and I realized there is nothing like a "single diff view," as users always compare an edit with the latest revision. This has the added user benefit of always knowing what they’re comparing it to and the design/engineering benefit of consolidating.

2)

Another line I'm hoping for clarity on "Next/previous: Navigating through edits works as currently implemented in the revision history" - as currently implemented, navigation through revisions/changes in the Single Diff view via the next/previous buttons takes you to the next or previous revision/change in the Single Diff view. Is this the expected behavior?

Yes, but with the answer from 1) in mind, I’d formulate it as follows:

“(...) takes you to the next or previous revision/change in the compare revisions view (...)”

In T335579#8887964, @scblr wrote:

is this updated diff view intended to replace not only the current Compare Revisions view but also the Single "Diff" view?

Yes, to this! When working on the Android version, @Dbrant and I realized there is nothing like a "single diff view," as users always compare an edit with the latest revision. This has the added user benefit of always knowing what they’re comparing it to and the design/engineering benefit of consolidating.

Just to clarify a bit further: by definition, any kind of "diff" view requires two revisions to compare. I think what we mean here by "single diff" view is when we're given a single revision, with no other reference point. In that kind of case, we show a diff of that revision with the previous revision of that article (not the latest revision).

@scblr @OTichonova Hey y'all, some design questions and needs that have come out of updated diffs work:

• Need the filled state icon for the new thanks icon - apologies, I couldn't immediately find this in Figma
• Which revision (from or to) is expected to be undoed when the user taps undo?
• Which revision (from or to) is expected to be thanked when the user taps thank?
• Which revision (from or to) is expected to be rolled back when the user taps roll back?
• What is expected to be shared when the user taps share in the more menu?
• What is expected to happen when the user taps "Article Edit History" in the more menu?
• Are we sure we want to replace the bottom next/previous icons with the left-right pair icons instead of up-down? Currently, the up-down pair makes more sense both spatially (with the vertically scrollable list that you usually get to this diff view from) and the current animation.

Hey @Dmantena - I’m excited you are working on this task! I have answers for you! 👇

• Need the filled state icon for the new thanks icon - apologies, I couldn't immediately find this in Figma

Here you go:

https://www.figma.com/file/bgDCK2F4Km6nJvgKzDyl5J/iOS-Components?type=design&node-id=1043-27871&mode=design&t=7gtZDOtbtM2SxBDI-4

• Which revision (from or to) is expected to be undoed when the user taps undo?
• Which revision (from or to) is expected to be thanked when the user taps thank?
• Which revision (from or to) is expected to be rolled back when the user taps roll back?

For all cases: the revision in the TO section.

• What is expected to be shared when the user taps share in the more menu?

When comparing two revisions on Desktop Wikipedia, users can share what they’re looking at as parameters are added to the URL. We want the same behavior in the app. This example from Android:

...writes this URL:

https://en.wikipedia.org/w/index.php?title=Polar_bear&diff=1143967550&oldid=1143965570&variant=en

Hope that helps.

• What is expected to happen when the user taps "Article Edit History" in the more menu?

The user is taken to the page's revision history, e.g., to the polar bear article revision history in the example from the task’s description.

• Are we sure we want to replace the bottom next/previous icons with the left-right pair icons instead of up-down? Currently, the up-down pair makes more sense both spatially (with the vertically scrollable list you usually get to this diff view from) and the current animation.

Good point, we can keep the up and down arrows for now and see how it’s understood in the usability tests.

Partial diffs PR merged: https://github.com/wikimedia/wikipedia-ios/pull/4552

Remaining work (copied from PR description):

• Continuing design tweaks
• Showing article image if available in header
• Improving next/previous revisions handling around boundaries of first revisions
• Updating header itself and header button design to not be full width
• Update Components framework menu button to support post initialization configuration (to handle our client pattern of lazy view configuration)
• Accessibility pass of the new work
• Hook up functionality of new menu buttons and header user buttons

Part 2 PR: https://github.com/wikimedia/wikipedia-ios/pull/4556

@Mazevedo Feel free to work off this ticket for the lead image in header task. The objective here is to present the article's lead image (if available) within the header of diff view. Toni's already done the work to grab the lead article image if available in this PR: https://github.com/wikimedia/wikipedia-ios/pull/4556

My recommendation for approaching this:

• DiffHeaderTitleView and the XIB house the UI for what we're interested in updating
• Currently, all the header labels in it live in a vertical UIStackView
• If there's no article lead image, leave it as is no change needed
• If there is an article lead image, the expected design behavior is that the image is 80x80, aspect filled, does not increase or reduce in width or height, and stays pinned to the top of the "Compare Revisions" label if the text in the labels grows in length/height.
• Behaviorally, TalkPageHeaderView may be something worth looking (and inserting long bits of text into the description label) to see how the image should react as the text in the labels grows. Notice that the image is to the side of the entire block of text, not just one particular label.
• A way to accomplish this while preserving easy LTR/RTL support is by nesting UIStackViews. Again, see TalkPageHeaderView if you're curious about this approach.

PR for diff header image https://github.com/wikimedia/wikipedia-ios/pull/4576

Done in TestFlight 7.4.0 (2459).

PR for updating from/to strings per design user testing: https://github.com/wikimedia/wikipedia-ios/pull/4586

Looks good to me on 7.4.0 (2473)

Found one small quirk but will file a separate ticket for it.