Page MenuHomePhabricator

Improve discovery of reading history across Activity and Search entry points
Closed, ResolvedPublic0 Estimated Story Points

Description

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 view with History.
  • Remove search bar on iPad article view. Users on iPad will already have the tab bar search/search icon where they can switch to the unfocused Search view 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 view 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 functions 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.

image.png (2×1 px, 1 MB)

  • When triggered from article view, the top navigation of Search should be slightly different from the Search tab
    • Include a back button to the article, Search Title, and "Clear" option for history. Tabs and Profile do not need to be present.
  • 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

Event Timeline

@JTannerWMF

Currently, users see their reading history in the Search tab when the search field is not active. When the search field becomes active, the view switches to recently searched terms.

This behavior is consistent across the app:

  • Article view:

Search not active → the article remains visible.

Search active → the recent searches view appears.

  • Explore feed:

Search not active → the explore feed remains visible.

Search active → the recent searches view appears.

  • Search tab:

Search not active → the reading history remains visible.

Search active → the recent searches view appears.

Because of this, the experience is consistent: activating the search field always shows recent searches.

Could you clarify this scenario a bit more?

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.

In both the article view, the explore feed and the search tab, the user must tap the search bar to activate search. Once the search field becomes active (keyboard visible), the UI switches to the recent searches view.

So effectively, search is considered “active” only when the search field is focused and the keyboard is shown, which is when the recent searches UI appears.

Do not activate keyboard when entering search, unless search is clicked from the search screen.

Does it mean two taps to type a search term?

Maybe a low-fidelity wireframe mock of the desired flow could helps us understand better.

Seddon set the point value for this task to 5.Mar 10 2026, 6:05 PM

@JTannerWMF and @SChekfa-WMF

Do you mind taking a look at this build, just to be sure we're headed in the right direction? Thanks

Wikipedia Experimental 7.9.3 (312)

ABorbaWMF subscribed.

Looks good on 7.9.3 (5993)
Tested on:
iPhone 16 on iOS 26.3.1
iPhone SE on iOS 26.3.1
iPhone 11 on iOS 26.2.1
iPad Air 11inch on iPadOS 26.3.1

Seddon changed the point value for this task from 5 to 0.Wed, Mar 25, 5:57 PM
Seddon set Final Story Points to 5.