Change Details

###Background Reading history was recently moved from its previous location into the Search tab. Since the move, users have struggled to find their reading history — many still navigate to the Activity tab expecting to find it there, as that was the prior pattern. Additionally, users who enter Search via the article view or the Explore feed do not see their reading history, since the history list currently only surfaces when Search is opened from the bottom navigation bar. This creates an inconsistent and confusing experience depending on how a user enters Search. A secondary discovery gap exists for logged-out users, who may not realize that reading history is stored locally and accessible without an account. When Search is opened from the bottom nav, reading history is visible by default. When Search is activated (e.g. the search bar is tapped and the keyboard is raised), reading history is suppressed and replaced by recent search suggestions or results. When a user opens Search from within an article, the keyboard is not automatically activated — the user sees the Search screen but must tap the search bar again to activate it. This means reading history should technically be visible in this state, but currently is not. The fix for entry point parity is therefore a UI-level change, not a data layer change. ###Requirements [] Reading history visible across all Search entry points. Do not activate keyboard when entering search, unless search is clicked from the search screen. Reading history should be displayed whenever a user opens Search in an inactive state (keyboard not raised), regardless of how they got there. Specifically: - When Search is opened from the article view, reading history should be visible immediately, consistent with the bottom nav experience - When Search is opened from the Explore feed, reading history should be visible immediately - Reading history should only be suppressed once the user actively taps the search bar and raises the keyboard — this behavior should be consistent across all entry points [] Persistent informational callout on the Activity tab Display a persistent, dismissible callout banner (instead of tooltip) at the top of the Activity tab, below the page header and above any user content (username/reading header for logged-in users, login prompt or empty state for logged-out users). The callout should: - Appear for both logged-in and logged-out users - Include "Search tab" as a hyperlink that navigates directly to Search - Tapping the "Search tab" link does not dismiss the callout — the user must tap ✕ explicitly to dismiss - Be manually dismissible only via the ✕ button - Auto-hide after 30 days from the app version production release date using a hardcoded release date string in the app or remote config is permissible and left to the discretion of the engineer - Notice should not reappear after manual dismissal **Notice Copy** Logged-in users //Reading history is now in Search Browse or clear your reading history in the Search tab.// Logged-out users //Reading history is now in Search Find and clear your reading history in the Search tab. No account needed.// ### Design Do not use custom components. Mockup screens should cover: Logged-in: callout visible state Logged-in: callout dismissed state Logged-out: full empty state with callout Logged-out: compact inline login prompt with callout

###Background Reading history was recently moved from its previous location into the Search tab. Since the move, users have struggled to find their reading history — many still navigate to the Activity tab expecting to find it there, as that was the prior pattern. Additionally, users who enter Search via the article view or the Explore feed do not see their reading history, since the history list currently only surfaces when Search is opened from the tab bar. This creates an inconsistent and confusing experience depending on how a user enters Search. A secondary discovery gap exists for logged-out users, who may not realize that reading history is stored locally and accessible without an account. ###Requirements [] Remove search bar on Explore. Users on Explore will already have the search icon to tap from the tab bar, where they can switch to the unfocused- Search state with History. [] Remove search bar on Article, and instead add a magnifying glass icon to the left of the tabs icon. This brings back an earlier pattern where users have to visit a different search screen before they can search from Article (see screenshot from version 7.6.4). Upon user tap of the magnifying glass icon, we should push on a new unfocused Search view controller. History will be displayed, as well as a back button that can take them back to the article. Search experience acts the same as it does on Search tab: 1. When a user focuses the search bar, the keyboard displays and content is replaced with recent search terms. 2. When a user types in the search bar, the app fetches their search results and replaces recent search terms with search results. 3. When a user taps cancel while the search bar is focused, the keyboard disappears and content is replaced with History. 7.6.4 screenshot example: {F72796787} [] Persistent informational callout on the Activity tab Display a persistent, dismissible callout banner (instead of tooltip) at the top of the Activity tab, below the page header and above any user content (username/reading header for logged-in users, login prompt or empty state for logged-out users). The callout should: - Appear for both logged-in and logged-out users - Include "Search tab" as a hyperlink that navigates directly to Search - Tapping the "Search tab" link does not dismiss the callout — the user must tap ✕ explicitly to dismiss - Be manually dismissible only via the ✕ button - Auto-hide after 30 days from the app version production release date using a hardcoded release date string in the app or remote config is permissible and left to the discretion of the engineer - Notice should not reappear after manual dismissal **Notice Copy** Logged-in users //Reading history is now in Search Browse or clear your reading history in the Search tab.// Logged-out users //Reading history is now in Search Find and clear your reading history in the Search tab. No account needed.// ### Design Do not use custom components. Mockup screens should cover: Logged-in: callout visible state Logged-in: callout dismissed state Logged-out: full empty state with callout Logged-out: compact inline login prompt with callout

###Background Reading history was recently moved from its previous location into the Search tab. Since the move, users have struggled to find their reading history — many still navigate to the Activity tab expecting to find it there, as that was the prior pattern. Additionally, users who enter Search via the article view or the Explore feed do not see their reading history, since the history list currently only surfaces when Search is opened from the bottom navigationtab bar. This creates an inconsistent and confusing experience depending on how a user enters Search. A secondary discovery gap exists for logged-out users, who may not realize that reading history is stored locally and accessible without an account. When Search is opened from the bottom nav, reading history is visible by default. When Search is activated (e.g. the search bar is tapped and the keyboard is raised), reading history is suppressed and replaced by recent search suggestions or results. When a user opens Search from within an article, the keyboard is not automatically activated — the user sees the Search screen but must tap the search bar again to activate it. This means reading history should technically be visible in this state, but currently is not. The fix for entry point parity is therefore a UI-level change, not a data layer change. ###Requirements [] Reading history visible across all Search entry pointsRemove search bar on Explore. Do not activate keyboard when entering searchUsers on Explore will already have the search icon to tap from the tab bar, unless search is clicked from the swhere they can switch to the unfocused- Search screentate with History. Reading history should be displayed whenever a user opens Search in an inactive state (keyboard not raised)[] Remove search bar on Article, and instead add a magnifying glass icon to the left of the tabs icon. This brings back an earlier pattern where users have to visit a different search screen before they can search from Article (see screenshot from version 7.6.4). Upon user tap of the magnifying glass icon, we should push on a new unfocused Search view controller. History will be displayed, regardless of howas well as a back button that can take they gotm back to there. Specifically: article. Search experience acts the same as it does on Search tab: - When Search is opened from the article view, 1. reading history should be visible immediatelyWhen a user focuses the search bar, consistent with the bottom nav experiencethe keyboard displays and content is replaced with recent search terms. - When Search is opened from the Explore fe 2. When a user types in the search bar, the app fetches their search results and replaces recent search terms with search results. 3. When a user taps cancel while the search bar is focused, reading history should be visible immediatelythe keyboard disappears and content is replaced with History. 7.6.4 screenshot example: - Reading history should only be suppressed once the user actively taps the search bar and raises the keyboard — this behavior should be consistent across all entry points{F72796787} [] Persistent informational callout on the Activity tab Display a persistent, dismissible callout banner (instead of tooltip) at the top of the Activity tab, below the page header and above any user content (username/reading header for logged-in users, login prompt or empty state for logged-out users). The callout should: - Appear for both logged-in and logged-out users - Include "Search tab" as a hyperlink that navigates directly to Search - Tapping the "Search tab" link does not dismiss the callout — the user must tap ✕ explicitly to dismiss - Be manually dismissible only via the ✕ button - Auto-hide after 30 days from the app version production release date using a hardcoded release date string in the app or remote config is permissible and left to the discretion of the engineer - Notice should not reappear after manual dismissal **Notice Copy** Logged-in users //Reading history is now in Search Browse or clear your reading history in the Search tab.// Logged-out users //Reading history is now in Search Find and clear your reading history in the Search tab. No account needed.// ### Design Do not use custom components. Mockup screens should cover: Logged-in: callout visible state Logged-in: callout dismissed state Logged-out: full empty state with callout Logged-out: compact inline login prompt with callout