Background
Recent changes to the Search in Article view necessitated 2 changes https://phabricator.wikimedia.org/T419478
- Moving search back to a small icon at the top
- Requiring an extra tap to activate the keyboard for search
After some beta user feedback, we are concerned this extra friction of placement and two taps to activate search may cause issues with users. We see an opportunity to make search more accessible from article view while further aligning the Article search experience with other liquid glass patterns on iOS apps.
We're seeing a pattern in Apple Liquid glass apps, that article views (Podcast and News) display search at the bottom. Tapping into search does not activate the keyboard, but show the search tab. Then tapping into search is easy, given search is now at the bottom of the screen.
| Everpresent Search tab at bottom | After tapping on Search icon | Activating bottom Search bar |
 |  |  |
Reference Designs
A) Secondary toolbar moves above main tabbar when expanded
B) Secondary toolbar moves between main tab bar (collapsed) and Search on Scroll
Task
@Design
- Create prototype of iOS app with current navigational behavior
- Create prototype of the iOS App with the following variant navigation behavior:
- Display primary tabbar on Article view (Explore, Places, Saved, Activity, Search)
- Article toolbar (Languages, Saved, Search in article, Theme, Overflow) displays in a secondary toolbar. Find in Page and Theme may be moved into the Overflow menu if necessary
- Primary tabbar should collapse into small Explore icon upon scroll (Similar to how it does on the Search tab), on the Left Search should appear on the right (Opposite for RTL languages)
- Secondary toolbar should nest between the Explore icon and Search icon on scroll (see example B)
- Tapping search from the article should launch the Search tab
- TBD By designer: Should it require a second tap to activate search, or integrate History & Recently searched together into the initial view, with keyboard activated
- After searching and opening an article from the Search tab bar, if a user navigates "Back", they should land on Search
- Remove Search icon from top navigation of article view
- Remove "W" icon from top navigation
- Create script and run it by PM and Design Research
- Make sure the protocol has at least one task that requires a round-trip: find an article → read it → search for something new → return to original article
- Run usability testing in Userlytics to test core workflows in the app with our current navigation , and the variant navigation
- Process feedback from conducting testing on userlytics
- Share outcomes and recommendations with the team
Research questions
- Discoverability of Search
- When users want to search Wikipedia from within an article, can they locate and activate search quickly and without guidance?
- Does moving search to the bottom tab bar reduce the friction observed with the current top-icon placement? Does the 2-tap to activate the keyboard still cause complaints?
- Navigation recovery after search
- After a user taps into Search from an article, searches for something, and wants to return to what they were reading, can they successfully navigate back?
- Do users understand that there is no "back" button on the Search tab, and does this cause confusion or dead ends? Is anyone missing the "Swipe" to navigate back?
- If a user opened an article from "Saved" or a different tab other than Search, and do they understand that they have to go back to teh "Saved" tab to see that article and it's corresponding rabbit hole?
- Tab bar comprehension on article view
- When the primary tab bar is visible within an article view (a new behavior), do users understand what it does and how it differs from the secondary article toolbar? Can they use it successfully to navigate back to "Explore"?
- Is there confusion about which bar controls article-level actions versus app-level navigation?
- Collapsed nav bar legibility on scroll
- When the tab bar collapses into the small Explore icon + Search icon on scroll (per the variant), do users understand these controls are still available?
- Can they easily expand or interact with them, particularly when switching between article toolbar actions and tab-level navigation?
Target Audience
- New, casual, and active readers on the iOS Wikipedia App
- Nice to have: RTL Language users (can be testing RTL prototype within English)
Link to protocol
TBA
Link to analysis
TBA
Recommendations
TBA