Update mocks to show that the user will need to route through Settings after push permissions.

Hey @cmadeo! We engineering synced on this and have a change (which is slightly different from what I mentioned in planning):

1. Tapping "Turn on push notifications" from the Explore feed card will take the user to the Notifications Settings screen, where they can turn on the parent toggle and go through the normal flow.
2. Tapping "Turn on push notifications" from the Notifications Center prompt will ask the user for OS permissions right there, just like you have it now in the mocks on this task's description. As an FYI, we will also have to subscribe their device token behind the scenes after they enable push permissions here. That will probably succeed in most cases, but if that happens to fail, it will fail silently. The worst case to come out of that is the user will notice that they don't seem to be getting pushes, so then we hope they will visit their Notifications Settings screen, where they will see the toggle in the OFF state and they'll have an opportunity to retry their device token subscription.

Let me know if number 2 sounds good. Originally in today's planning I thought we would push them to Notifications Settings from that prompt on Notifications Center, but now we think that getting kicked out of Notifications Center the first time they visit might be pretty annoying.

Hi @Tsevener thanks for the update! This sounds good to me (1 and 2)!

Hi @cmadeo,

Just one tweak needed on the flow as far as I can tell - because of my comment above, I was thinking your last yellow box in the flow would only be the OS permissions prompt, not the push to app Settings > Notifications. If they allow here, we'll do some under the hood subscription attempt (and silently fail if this doesn't work), if they deny, the OS prompt dismisses. Either way they get to remain in Notifications Center without being navigated away immediately to Notifications Settings.

From the Explore feed card however, we'll take them to Notifications Settings, though I don't see that part in the flow currently.

Hi @Tsevener unfortunately I've lost access to edit this file, so it's going to take me a little while to update.

Currently blocked by FAQ to link to: https://phabricator.wikimedia.org/T302634

Hi all! Thanks are looking and working really well! Thank you!

A few small tweaks:
Would it be possible to remove the outline on the button in this screen?

Could we make some typography tweaks on the modal?

Design	Screenshot

• Title (Editing Notifications): Could we use 28pt instead of the current 32 pt?
• Body text (each of the bullets): Could we use 13pt instead of the current 15 pt? I understand that this is smaller than our normal body text.
• Spacing between bullets should be 32 pt
• For the CTA button: Could we use a button that is 335pt wide and 46 pts hight?
• For the link text below the CTA: Could we use 'medium' font weight instead of 'bold'?

Thank you!

Hi all! Thanks are looking and working really well! Thank you!

@cmadeo Glad to hear it!

A few small tweaks:
Would it be possible to remove the outline on the button in this screen?

Currently, this Notifications Center push panel is using the same internal Panel library previously built and used everywhere else we use panels. Removing the border here would potentially be visually inconsistent with other panel presentations in the app. Here's an example of the current reading list sync panel.

We can:

• conditionally change just this Notifications Center panel to have no button border
• change all panels to no longer have the button border
• leave as-is (current panel style here and across app doesn't change)

Which would you prefer?

Could we make some typography tweaks on the modal?

As I was implementing this, I referenced Apple's implementations of this style of modal across some of their first party apps and my own previous work implementing a modal in this style. In general, I then snapped our values towards Apple's values to provide a more expected-on-the-platform visual presentation.

I'm happy to make these changes if you feel strongly about them, but before I do I just want to check to confirm you're ok with the visual and legibility platform inconsistencies we'd be potentially introducing. Lemme know!

Thanks for the helpful notes @Dmantena!

change all panels to no longer have the button border

How much work would it be to do this? We'll also be wanting to make some changes to button styles in the near future (across the whole app) so generally a bit curious about how much work it would be to make tweaks to a button component across the app. If it's a lot, we can keep the border for now with the expectation that we'll change the component later. If it's easy though, it'd be great to lose that border everywhere.

As I was implementing this, I referenced Apple's implementations of this style of modal across some of their first party apps and my own previous work implementing a modal in this style. In general, I then snapped our values towards Apple's values to provide a more expected-on-the-platform visual presentation.

I'm happy to make these changes if you feel strongly about them, but before I do I just want to check to confirm you're ok with the visual and legibility platform inconsistencies we'd be potentially introducing. Lemme know!

Thanks, @Dmantena, @OTichonova and I are working on a new typography sizing system for us that borrows from Apple standards but makes some small changes due to the text heavy nature of our app and the Wikimedia styleguide. I hear you that the sizing for some of the type on this screen is smaller than we'd normally ideally go, but I'd like to move forward with what was proposed in Figma.

https://www.figma.com/file/cedgOU5CyOR0UVqtjDOvzE/iOS-Notifications?node-id=2036%3A17088

Please note: Playing around with it mirrored on device I've updated the subheadings (bolded elements of the bullets) to our proposed 'default' size of 15pt.

How much work would it be to do this? [...] If it's easy though, it'd be great to lose that border everywhere.

Was fairly straightforward to remove all borders - updated in https://github.com/wikimedia/wikipedia-ios/pull/4181

Thanks, @Dmantena, @OTichonova and I are working on a new typography sizing system for us that borrows from Apple standards but makes some small changes due to the text heavy nature of our app and the Wikimedia styleguide. I hear you that the sizing for some of the type on this screen is smaller than we'd normally ideally go, but I'd like to move forward with what was proposed in Figma.

Updated! https://github.com/wikimedia/wikipedia-ios/pull/4182

Thank you so much @Dmantena!

@cmadeo There's a pending design Q from Toni here regarding the push opt-in when in the Sepia theme: https://github.com/wikimedia/wikipedia-ios/pull/4181#pullrequestreview-936702827

@cmadeo these tweaks should be in the next TestFlight nightly build (1913).

Awesome, thanks @Tsevener !

Looks great! Thanks for the updates @Dmantena + @Tsevener!!!

Looks good on phone and tablet on 6.9.0 (1920)