Estimate assuming this is in a different task (T383839):

Scroll-down: Toolbar is sticky, Navigation and search bar disappears

@Tsevener ok, does it work to do it on this task? T383470

@HNordeenWMF

I assumed by the Scroll-down: Toolbar is sticky, Navigation and search bar disappears requirement, you meant that the iPad navigation bar buttons should remain on screen as you scroll? If so, that work is covered here as design review task: T383839.

Just want to make sure whoever picks this up isn't duplicating work.

@SNowick_WMF @HNordeenWMF Will y'all need new donate metrics for these new profile placements? Will that be handled in a separate task?

Right now we log from Explore and Article, and Settings (if Explore is disabled). The profile view donate button taps log an active_interface corresponding to where the Profile button lived (like explore_profile or article_profile, for example). Do we need to add these same events for Saved (and Places, History, Search)? See T374169 for what we log.

@Tsevener this came up in Data Sync - Yes, I would like donate metrics to be logged from these new profile placements in the same way it's done for Explore and Article if possible, otherwise we may get confused later on. This ccan be done on these invidual tasks, or all at once on the instrumentation task: T383827 - whichever you prefer.

mazevedofs closed https://github.com/wikimedia/wikipedia-ios/pull/5163

@HNordeenWMF ok sounds good, no problem, I'm good with doing it separate in T383827. Thanks!

Since we'll be doing instrumentation in another ticket, I'll move this on the board.

@scblr Wasn't sure if you signed off on this one as well in https://phabricator.wikimedia.org/T383828#10488456. Moving this task to your column so it's official. This is in build 7.7.0 (217).

@Tsevener I combined the instrumentation for new Profile entries with iOS Search so all on same doc, lmk if here would be a good place to link it or ok to keep with iOS Search.

Will let @Mazevedo decide that one, thanks!

@SNowick_WMF @Tsevener I'm good with that, thanks!

Can be tested on 7.7.1 (4905)

Looks good on 7.7.1 (4912)

Functions well, but sizing of overflow menu / profile is not matching designs I think - sending back for Design review

1) Good catch @HNordeenWMF 👀

@Mazevedo are you using SF Symbols? If yes, what are the current font settings for the symbol? It seems like the account icon has a different size than the more button:

Implementation	vs	Design
Figma

My Figma settings (not sure if they match the code) for the two symbols (ellipsis.circle, person.crop.circle/person.crop.circle.badge) are:

font-family: SF Pro Text;
font-weight: Medium;
line-height: 24sp; (not sure if relevant)
letter-spacing: 0; (not sure if relevant)

2) Scroll behavior: I noticed that on accelerated (fast) scroll down, the scroll momentum can’t be stopped anymore. Is this related to the disappearing header? It feels different/unnatural compared with other apps. I recorded both of our app and Safari for reference in this video:

https://share.icloud.com/photos/0a4_RClHHe2XsWtlDbCfH6wNA

Notice how the scroll momentum can be stopped in Safari but not in the Wikipedia app.

I will let @Mazevedo look into #1.

For #2:

@scblr

Scroll behavior: I noticed that on accelerated (fast) scroll down, the scroll momentum can’t be stopped anymore. Is this related to the disappearing header?

Can you provide a video of the regression against 7.7.0? The scroll behavior should have been unchanged since that release. Or was it not working as you expected in 7.7.0? If the latter, we should track it in T383897, in my opinion.

@HNordeenWMF
Also a note on the requirements here for iPad:

Scroll-down: Toolbar is sticky, Navigation and search bar disappears

I worked a bit on this, and after some back & forth it was determined we do not want the toolbar to be sticky, that is, the navigation bar buttons hide upon scroll (see https://phabricator.wikimedia.org/T383839#10521615). So I think this requirement should be removed from all these Nav V2 tasks, if you all agree.

In T383822#10536659, @Tsevener wrote:

I will let @Mazevedo look into #1.

For #2:

@scblr

Scroll behavior: I noticed that on accelerated (fast) scroll down, the scroll momentum can’t be stopped anymore. Is this related to the disappearing header?

Can you provide a video of the regression against 7.7.0? The scroll behavior should have been unchanged since that release. Or was it not working as you expected in 7.7.0? If the latter, we should track it in T383897, in my opinion.

Yeah, I think it was like that already in 7.7.0 — I haven’t noticed it until recently – my bad!

@HNordeenWMF
Also a note on the requirements here for iPad:

Scroll-down: Toolbar is sticky, Navigation and search bar disappears

I worked a bit on this, and after some back & forth it was determined we do not want the toolbar to be sticky, that is, the navigation bar buttons hide upon scroll (see https://phabricator.wikimedia.org/T383839#10521615). So I think this requirement should be removed from all these Nav V2 tasks, if you all agree.

I trust your judgment on this. If you think that solution works technically better, that’s fine with me.

tonisevener closed https://github.com/wikimedia/wikipedia-ios/pull/5195

@scblr

Yeah, I think it was like that already in 7.7.0 — I haven’t noticed it until recently – my bad!

Also sorry, I misinterpreted your "anymore" as "this used to work, now it doesn't".

I dug into this a bit and spun up a sample project, to ensure nothing else in the app was affecting it. It does look like the navigation bar hiding prevents the scroll view from intercepting (I'm guessing it waits till the navigation bar hide animation has completed).

Not sure if these gifs illustrate it very well:

Hiding (intercept lags):

Not hiding (intercept happens much more quickly):

So I think we'll be stuck with this behavior unless we move towards keeping the navigation bar on screen at all times.

@Mazevedo did fix item #1, that is in Wikipedia (white icon) build #4944.

Yep @Tsevener! Good catch:

Scroll-down: Toolbar is sticky, Navigation and search bar disappears

is no longer a requirement since we are doing T383759

In T383822#10536903, @Tsevener wrote:

@scblr

Yeah, I think it was like that already in 7.7.0 — I haven’t noticed it until recently – my bad!

Also sorry, I misinterpreted your "anymore" as "this used to work, now it doesn't".

I dug into this a bit and spun up a sample project, to ensure nothing else in the app was affecting it. It does look like the navigation bar hiding prevents the scroll view from intercepting (I'm guessing it waits till the navigation bar hide animation has completed).

Not sure if these gifs illustrate it very well:

Hiding (intercept lags):

Not hiding (intercept happens much more quickly):

So I think we'll be stuck with this behavior unless we move towards keeping the navigation bar on screen at all times.

Ok gotcha. I think it’s not ideal but not a blocker – I hope we can investigate more alternatives in the future @HNordeenWMF ?

@Mazevedo did fix item #1, that is in Wikipedia (white icon) build #4944.

Looks good to me, thanks @Tsevener!

Looks great on 7.7.1 (4944), but not fixed on the most recent test flight build.
Here is what I'm seeing on 7.7.1 (4945)

@HNordeenWMF 7.7.1 (4944) is what will be released to users, sorry about the branch mixup.

7.7.1 (4944) is off of our main branch, which doesn't have the most recent tweaks to 7.7.1 merged yet. main should have been renamed to 7.7.2 by now, will do that now.

got it, thanks @Tsevener ! My test flight is still doing that weird thing where I can't see all the builds in "Versions" sometimes, but I can install the most recent one from the overview screen, so I was in a situation of only being able to see 4945 for a while.