Background
Enhanced browsing and discovery features within the iOS app are the most requested with 150+ specific requests to introduce tabs similar to the Safari web browser, and Android app. Data from the Android app shows that Tabs are the most frequently engaged with feature after Search and Explore feed (shown on app open). Current Android users use Tabs to browse Wikipedia, and enjoy sharing their Wikipedia App tabs as a unique display of their reading habits and rabbit holes. With upcoming work on the iOS app navigation, we have the opportunity to add Tabbed browsing functionality to the App.
This aligns with 3.1’s Reader and Donor Experiences objective to build on-platform browsing experiences that make content easier to discover, reduce reliance on search platforms, and retain new consumers.
Our hypotheses are:
- If we develop and test design prototypes for tabbed browsing in the Wikipedia iOS app, we will gain and incorporate actionable insights on usability, while also enabling engineers to assess technical feasibility of different approaches, building a solid foundation for adding Tabs to the app in Q4.
- If we introduce Tabs into the iOS app to improve the browsing experience, users will engage with the feature over multiple days, and we’ll see a comparable or higher 2-day feature retention rate to the Android Tabs feature
How will we know we were successful
7-day indicators
- [Hypothesis indicator] KR 1.2 At least 30% of users who engage with Tabs return to use the feature on more than one day
- [Discovery] KR 1.3 At least 20% of active users with access to tabs, engage with the feature
- CR 3.3 How does iOS's usage and adoption of Tabs compare with Android?
- What was the equivalent Android result for KR 1.1 and KR 1.2?
Engage with the feature = opened "Tabs" overview
30-day analysis
Validation
- [Primary metric] KR 1.1 Logged-out users who have access to Tabs have a 1% higher cumulative app retention rate for compared to users who did have access to Tabs
Guardrails
- GR 2.1 60% of users rate the feature as neutral or satisfactory (as measured by in-app survey)
- GR 2.2 No more than 5 user complaints about performance declines or increase in cellular data to support Tabs (as measured by user feedback)
Curiosities
- CR 3.1 Did we have a higher % of internal referral clicks from the variant group compared to control?
- CR 3.2 Were there any differences in logged-in vs logged-out users for KR 1.1, 1.2, and 1.3?
- CR 3.3 How does iOS's usage and adoption of Tabs compare with Android?
- What was the equivalent Android result for KR 1.1 and KR 1.2?
- CR 3.4 Did we see any decrease in uninstalls for target audiences?
- CR 3.5 What other functionality are users looking for from Tabs? (survey responses)
- CR 3.6 What % of new tabs were opened from the overview, vs longpress open in new tab, vs long press open in background tab?
Must Haves
- Users can navigate back to the main views (Explore) from Tabs
- Access to tabs from all main views (consistent header as part of Navigation refresh)
- Most recent tabs are visible on screen when opening Tabs
- Show preview of content for each tab (Article title, first few lines of article, image if available)
- Indicate open tabs in global search and allow users to switch to already open tabs
- Tab should remember a user’s last position in the page and display it again on subsequent views of the tab
- Allow opening an article in a new tab after long-press on any article link (in article view, explore, saved, history, search)
- “New tab” option
- Show number of open tabs
- Users can close individual tabs
- Users should be able to have up to 100 tabs (nice-to-have: no upper bound)
- Allow users to have Tabs open in multiple languages
- Filter out non-article detours (talk pages, article history, files)
- In-app survey to measure satisfaction and receive feedback
- New feature announcement or tooltip (iOS + iPadOS)
- Onboarding to Tabs - highlight the “long press”
- Using tabs should not significantly increase the local storage or cellular data used by the App, or slow down the performance of the app
Nice to Haves
- Allow User, Draft, and Wikipedia/Project namespace pages to be included in the tab stack
- Show non-mainspace pages in modified version of article view
- Close all tabs, after a user has closed a tab or all tabs, allow them to undo
- Save all open tabs to new reading list
- Tabs sync across devices for logged-in users
- Collapse or close inactive tabs after a certain amount of time
- Allow rearranging tabs
- Share-able “Rabbit hole” visualization for Tabs
- Show open tabs in Search - if I have the same article open in multiple tabs, but each in a different language. The search shows me the open tab relevant to the language I'm searching in.
Open questions
- Link previews for article links on short tap: which gives them the option to read article in same tab, or open in new tab
- Should link previews be default for articles accessed from article view?
- Should articles from browser / external links open automatically in a new tab?
- When opening an article that is already open in a tab, should users be prompted to switch to the open tab?
- Should we allow duplicate tabs of the same article? (Android does)
- Do users expect any part of their tabs to be saved offline?
Out of scope, but consider for follow-up work
User Stories
- While reading an article on Apple, I want to open links Steve Jobs, Cupertino, and iPhone into separate tabs in the background, so I can read them later on after finishing the Apple article. T374334
- As a reader, I want the Wikipedia App to have tabs like Safari or Chrome, so that I can keep all of my Wikipedia tabs in one place, and browse Wikipedia without being tracked.
- As a student, I want to be able to keep my place in multiple articles and switch between, so that I can gather notes and sources for research.
Target Quant Regions and Languages
- Japanese and English readers in the ESEAP region.
- Arabic and English readers in Middle East and North Africa
Target Qualitative Audience
Diversity in:
- Age
- Education
- Gender Identities
- Impact on folks that use Screen Readers
- Orientation for RtL vs LtR readers
Designs
TBA
References
- Past phab tasks: T157364: [FEATURE REQUEST] Tabbed Browsing, T221471: Feature Request - tabs