Tabbed Browsing introduces multi-article navigation to the Wikipedia iOS app, enabling readers to open and switch between several pages seamlessly, enhancing discoverability, supporting deeper exploration, and aligning with the Foundation’s goal of improving on-platform reading experiences.

تُعد ميزات التصفح والاكتشاف المحسّنة في تطبيق آي أو إس iOS من التحسينات الأكثر طلباً، إذ بلغ عدد طلبات المستخدمين الذين طلبوا توفير التصفّح المبوّب (أي من خلال التبويبات) على غرار متصفح الويب سفاري وتطبيق ويكيبيديا أندرويد أكثر من 150 طلباً. تشير بيانات تطبيق أندرويد Android إلى أن علامات التبويب هي الميزة الأكثر استخداماً وتفاعلاً بعد ميزة البحث وميزة موجز الاستكشاف (التي تظهر عند تشغيل التطبيق).Data from the Android app indicates that tabs are the most frequently engaged-with feature after Search and the Explore feed (which appears upon app launch).

حالياً، يستفيد مستخدمو أندرويد من علامات التبويب لتصفح ويكيبيديا بكفاءة، وغالباً ما يشاركون التبويبات في التطبيق للدلالة على عاداتهم وممارساتهم في القراءة والاستكشاف. مع العمل المخطط له لتطوير ميزة التصفّح في تطبيق آي أو إس iOS، لدينا الفرصة لتقديم ميزة التصفح المبوّب (أي باستخدام التبويبات).With the upcoming work on iOS app navigation, we can introduce tabs here as well.

تتوافق هذه المبادرة مع الهدف 3.1 من خطة مؤسسة ويكيميديا السنوية لتجارب القراء والمانحين، والذي يركز على تطوير تجارب التصفح على المنصة لجعل اكتشاف المحتوى أسهل، وتقليل الاعتماد على منصات البحث الخارجية، وتعزز الاحتفاظ بالقراء.

تتماشى إضافة ميزة التصفح المبوب مع الهدف 3.1 الذي يهدف لجعل ويكيبيديا الوجهة المفضلة للتفاعل مع المحتوى الموسوعي، وتطوير تجارب التصفح على المنصة التي تعزز اكتشاف المحتوى، وتقلل الاعتماد على منصات البحث الخارجية، وتحافظ على المستخدمين الجدد.

الهدف WE 3: جذب جيل جديد من المستخدمين إلى ويكيبيديا باعتبارها وجهة مفضلة للتفاعل مع المحتوى الموسوعي.

النتيجة الرئيسية WE 3.1: إطلاق تجربتي تصفح وتعلم مُعدّتين، وسهلتي الوصول، تعتمدان على مدخلات المجتمع في مجموعة ممثِّلة من الويكيبيديات، بهدف زيادة نسبة الاحتفاظ بالقراء الذين لا يسجلون الدخول للمنصة بنسبة 5%.

1.إذا طوّرنا واختبرنا نماذج أولية لتصميم التصفح باستخدام التبويبات في تطبيق ويكيبيديا لنظام آي أو إس iOS، سنحصل على رؤى عملية قابلة للتنفيذ من حيث قابلية الاستخدام، ما سيتيح للمهندسين تقييم الجدوى التقنية للخيارات المختلفة ووضع حجر الأساس لتنفيذ ميزة علامات التبويب في الربع الرابع من السنة.

التحقّق

• [المقياس الأساسي] KR 1.1: معدل الاحتفاظ بالتطبيق لدى مستخدمي التبويبات أعلى بنسبة 1%.
• [التبنّي] KR 1.2: 5% من المستخدمين الفريدين الذين تتوفر لهم التبويبات فتحوا مقالة من لمحة علامة التبويب، أو فتحوا علامة التبويب تلك.

ضوابط الحماية

• يصنّف 60% من المستخدمين الميزة على أنها محايدة أو مُرضية (وفقًا لاستبيان نفّذ داخل التطبيق).
• لا تزيد شكاوى المستخدمين بخصوص انخفاض الأداء أو زيادة استهلاك بيانات الجهاز النقال بسبب علامات التبويب (وفقًا لقياسات فريق الهندسة وملاحظات المستخدمين) عن 5 شكاوى.

الفضول

• ما مدى ارتفاع عدد مرات مشاهدة الصفحة/المستخدمين الفريدين بالنسبة للمستخدمين الفريدين الذين تفاعلوا مع علامات التبويب مقارنة بالمستخدمين الذين لم يستخدموها من الجماهير المستهدفة؟
• هل لاحظنا أي انخفاض في عمليات إلغاء التثبيت لدى الفئات المستهدفة؟
• كيف يُقارن معدل اعتماد/تفاعل مستخدمي آي أو إس iOS مع علامات التبويب بمستخدمي نظام تشغيل أندرويد؟
• ما هي الوظائف الإضافية الأخرى التي يبحث عنها المستخدمون من علامات التبويب؟ (من خلال ردود الاستبيان).

• يمكن للمستخدمين العودة مرة أخرى إلى واجهات العرض الرئيسية (واجهة الاستكشاف) من علامات التبويب.
• إمكانية الوصول إلى علامات التبويب من جميع واجهات العرض الرئيسية (شريط عناوين ثابت وهو جزء من إعادة تنشيط التصفح)
• عند فتح علامات التبوين، تظهر آخر علامات تبويب مستخدمة على الشاشة.
• عرض معاينة للمحتوى لكل علامة تبويب (عنوان المقالة، الأسطر القليلة الأولى من المقالة، صورة إن وجدت)
• الإشارة إلى علامات التبويب المفتوحة في البحث العام والسماح للمستخدمين بالتبديل بين علامات التبويب المفتوحة بالفعل.
• يجب أن تحفظ علامة التبويب آخر موضع توقف عنده المستخدم في الصفحة وتعرضه مرة أخرى عند زيارته لها لاحقاً.
• السماح بفتح المقالات في علامة تبويب جديدة بالضغط المطوّل على أي رابط مقالة (في واجهة المقالة، والاستكشاف، والمحفوظات، والسجل، والبحث).
• إضافة خيار "علامة تبويب جديدة".
• عرض عدد علامات التبويب المفتوحة.
• تمكين المستخدمين من إغلاق علامات التبويب الفردية.
• بإمكان المستخدمين فتح حتى 100 علامة تبويب (ويفضل ألا يكون هناك حد أقصى).
• السماح للمستخدمين بفتح علامات تبويب بلغات متعددة.
• تصفية التحويلات غير المتعلقة بالمقالات (صفحات النقاش، وسجل المقالات، والملفات).
• إدراج استطلاع رأي داخل التطبيق لقياس مستوى الرضا وتلقي الملاحظات.
• الإعلان عن المزايا الجديدة أو إظهار تلميحات عنها (لأنظمة iOS و iPadOS).
• شرح إرشادي لكيفية استخدام علامات التبويب – وتسليط الضوء على "الضغط المطول".
• لا ينبغي أن يؤدي استخدام علامات التبويب إلى زيادة كبيرة في مساحة التخزين المحلي أو استهلاك بيانات الجهاز النقال، أو إبطاء أداء التطبيق.

T229502 - iPadOS - التعامل مع النوافذ المتعددة.

• أثناء قراءة مقال عن أبل، أريد فتح روابط لستيف جوبز وكوبرتينو وآيفون في علامات تبويب منفصلة حتى أتمكن من قراءتها لاحقاً.
• بصفتي قارئ، أريد أن يحتوي تطبيق ويكيبيديا على علامات تبويب مثل سفاري أو كروم، حتى أتمكن من تنظيم قراءاتي في ويكيبيديا والحفاظ على الخصوصية.
• بصفتي طالب، أريد التنقّل بين مقالات متعددة مع الحفاظ على موقعي، كي أتمكن من جمع الملاحظات والمصادر لإجراء بحث.

• القرّاء اليابانيون والإنجليز في منطقة شرق وجنوب شرق آسيا والمحيط الهادئ (ESEAP).
• القرّاء العرب والإنجليز في منطقة الشرق الأوسط وشمال إفريقيا.
• German readers in Germany

• التنوّع في:
  • العمر
  • التعليم
  • الهوية الجنسية
  • احتياجات الوصول (مثلاً مستخدمي قارئ الشاشات).
  • الاتجاه اللغوي (مستخدمو اللغات من اليمين لليسار مقابل مستخدمي اليسار إلى اليمين).

For further details and to follow the work, see the related Phabricator Epic Ticket:T384758.

• KR 1.1 Logged-out users who have access to Tabs have a 1% higher cumulative app retention rate compared to users who did not have access to Tabs (control)
  • Actual: We saw an increase of 0.14% for test group users app retention rate compared to control, this difference was not statistically significant
• KR 1.2 At least 30% of users who engage with Tabs return to use the feature on more than one day
  • Actual: We saw 24% of Tab Overview Uniques feature return rate overall. Logged-in users had a higher return rate of 32%, comprared to logged-out users who had a 24% feature return rate
• KR 1.3 1 At least 20% of active/exposed users with access to tabs, engage with the feature
  • Actual: 9.6% of test group users saw the Tabs Tooltips engaged with Tabbed Browsing features. Logged-in users had a higher engagement rate of 23%, compared to logged-out users at 9%.

• 60% of users rate the feature as neutral or satisfactory (as measured by in-app survey)
  • Actual: The satisfaction rate was 93%.
• No more than 5 user complaints about performance declines or increase in cellular data to support Tabs (as measured by user feedback)
  • Actual: We had no user complaints about performance declines or increase in cellular data

• Did we have a higher % of internal referral clicks from the variant group compared to control?
  • Yes, the group with access to tabs had a 1.3% higher average Internal Referral clicks per unique user compared to Control
• Were there any differences in logged-in vs logged-out users?
  • In both control and variant groups, logged-in users have a higher return rate compared to logged-out users. Logged-in users had a much higher engagement rate with tabs (23%) compared to logged-out users (9%).
• How does iOS's usage and adoption of Tabs compare with Android?
  • Tabs is a mature feature that has been availalbe for more than 5 years on the Android App, so we can expect rates to be higher. Adoption of Tabs on iOS is lower than on Android. iOS Tab Engagement Rate is 10% compared to Android Engagement Rate of 19%. The Android Tabs feature also has a higher return rate, at 56% for logged-out users, compared to iOS's 23%.
• Did we see any decrease in uninstalls for target audiences?
  • According to AppStore Data, we did see a 12% decrease in uninstalls during the experiment duration for users in the same experiment target countries.
• What other functionality are users looking for from Tabs? (survey responses)
  • User feedback included requests to
    • Make it more simlar to Chrome tabs
    • Anchor open tabs to the topic from which they were opened
    • Allow users to toggle the Tabs feature on and off
    • Let users set up reminders, and receive prompts to read open tabs they haven't gotten to yet

• After hearing user feedback about difficulty closing tabs, we increased the touch target to close tabsT404102
• We also solved these tabs-related bugs:
  • Tabs were not all the same size on iPad miniT396644
  • Tabs tooltip was causing issues after initial scrollT403998

• We began working on improvements to the Tabbed browsing feature, our work is coordinated on this Epic:T396055

• Tabbed browsing was released into production as an A/B test. We’re monitoring the test, and will share results soon.T384758
• We began working on iterative improvements to Tabs on this Epic:T396055
• We finalized designs for our new tab improvements, we will test two versions against control.

• We explored the usage the Android tabs feature to check our scoping decisionsT396052
  • We decided to focus on improving that experience, and this still feels like the right choice after seeing that:
    • 38.4% of Android Tab users use "new tab" option in the tabs overview
    • 8.9% of all tab overview events (impressions) to open the tab overview had "new tab" events
  • We decided not to invest time into the “Save all tabs” to a reading list feature, and data from the Android feature validated that decision:
    • Only 0.4% of all tab users have used "Save all tabs" on Android

• We solved the following bugs:
  • Can't open other tabs or new tab after closing the current tab.T396160
  • Crash after deleting a tab.T394682
• Our designer completed usability testing on the updated “new tab” experience options.
  • We found that:
    • Users generally open new tabs several times a day
    • Many users sometimes engage with suggested articles if something catches their eye or if it’s what they were already looking for
    • Many users want to see information related to previous searches or subjects of interest, trending pages, or recommended pages
    • Most users liked the personalization and variety offered by the feed option
    • Most users wanted the ability to customize the modules on display and their arrangement
    • Most users prefer the content in the feed to refresh every time the app is opened
    • DYK was also highly popular, with users finding it fun and engaging, a good way to learn new facts daily
    • DYK and the feed were seen as fitting with Wikipedia’s purpose of learning and information
    • Many users believed it would make them open the app more often
    • Other suggestions for improvement: incorporating an AI chat widget, breaking news
  • Our recommendations from this testing that we’re taking into developing our designs:
    • 1. 1 — Move forward with DYK and Feed variants
      2. 2 — Maintain the inclusion of the "Based on your reading," "Continue reading," and "Reading report" modules within the Feed variant
      3. 3 — Ensure ability to customize modules within the Feed variant, allowing users to rearrange and turn on/off modules to suit their preferences
      4. 4 — Refresh content upon every new tab open

• We released tabbed browsing into Beta! We plan to run an A/B test in select regions and languages before making it widely available.

• Here are the final designs for iOS tabs that will be implemented in May/June 2025.

• 
  Discovery tooltip 1/2
• 
  Discovery tooltip 2/2
• 
  Tabs entry point in the article
• 
  Tabs entry point in Places
• 
  Tabs entry point on Explore
• 
  Tabs entry point in History
• 
  Tabs entry point in Search
• 
  Tabs entry point in Saved
• 
  Long press in the article
• 
  Long press in Places
• 
  Tabs overview
• 
  Overflow menu in overview
• 
  Landscape designs for tab overview
• 
  Long press on tab item
• 
  New tabs open the main page
• 
  Satisfaction survey after using tabs
• 
  iPad design of article view
• 
  iPad design of overview

• Our engineers completed exploration work to ensure that adding tabs does not significantly increase data usage, and how we can track the data usage of the app,T386365
• We explored Android Tabs usage and examined some baseline usage numbers to inform our work on iOS
  • 20% of Android users open tabs overview in a given month. Of those who engage with Tabs, 30% come back to use it again within 2 days.
  • Android Tabs users retain at a higher rate than our baseline. Users who engage with tabs have a higher overall app retention (61%) compared to the overall average for the Android app of 48%. This doesn't show causation however, because Tabs users may already be more engaged users. Our A/B test on iOS will help us validate or disprove if offering Tabbed browsing leads to increased retention to the app.

• Our engineer created a prototype, and this allowed us to work through navigation questions, and performance concerns

T386365

• We completed usability testing for Tabs with the prototype and designs, and results were shared on this phabricator task:T389390. Our recommendations from the user testing were:
  • Keep the current back behavior that takes users back across tabs as a tab-agnostic back behavior has only been mentioned by 1/13
  • Always show the label of the previous destination next to the back button to make navigating articles easier. It has helped users immensely to navigate the prototype and understand what happens. It is recommended that the destination is always displayed on the back label. If the label is too long, apply truncation.
  • Introduce interface feedback (e.g. animation) when a new tab opens on the tabs icon so users realize that a new tab has opened (similar to Wikipedia on Android). Some users didn’t realize the tab opened in the background since the interface didn’t respond.
  • Related: Provide two options after the user’s long press: "Open in new tab" and "Open in new background tab"
    • Change the default tab behavior ("Open in new tab") to open the new tab and navigate to it.
    • Some participants expected to navigate to the tab after tapping the link.
    • Alternative: Introduce foreground/background tab setting (not recommended) as a user’s preference could vary per click.
  • Onboarding: show a tooltip for both the tabs overview and opening new tabs (use two contextual onboarding tooltips, with a "next" button and, e.g. 1/2 and 2/2 indicators)
  • For a future version, this could be considered:
    • Support gestures to move between tabs
    • Auto-close setting for tabs
    • Consider adding a link to reading history in the tabs overview more menu as it’s related
• We also reached out to users who have requested Tabs in the past to share the usability testing opportunity with them.

• We began working on Tabbed browsing (tabs)! Our designer analyzed user feedback from both iOS and Android to understand what users need and want from Tabs, created wireframes, and our lead engineer created a prototype. We began running user testing with our prototype and wireframes.T384758.

• 
  Screenshot that shows how to start using the tabs feature in the Wikipedia iOS app
• 
  Open an article in a new tab
• 
  List of six open tabs
• 
  Showing the options to save or close all tabs
• 
  Tabs Menu
• 
  Showing the open tabs while searching Wikipedia

• Here’s a summary of user feedback we reviewed:
  • From iOS users:
    • Lots of users mentioning tabs in their reviews switched from Android to iOS
    • Many of the lower rated reviews are related to the lack of tabs
    • Tabs are essential for rabbit hole journeys
    • Should work like web browser tabs (mentioned the most: like Safari, or Chrome)
    • Tabs should remember scroll position
    • Switching tabs with as little taps as possible (consider swipe gestures on address bar)
    • Users are asking for link previews (consider introducing setting)
    • Bottom navigation for tabs is expected (consider customization for top or bottom bar or additional tabs button in more menu)
    • Users asking for offline tabs
    • Make searching articles easy (consider adding the global search bar to the tabs view as well or active search on new tab)
    • Make the feature as discoverable as possible (since it hasn’t been present on iOS)

• • From Android users:
    • In general tabs should work like in Google Chrome
    • Handling of opening tabs could be optimized
    • Buggy: apparently it sometimes overrides or closes existing tabs
    • Stacked tabs is preferred over tile tabs design (maybe just bc of change-averse)
    • Manual control over tabs (when to open a new tab should be decided by user)
    • Closing multiple tabs should be possible
    • Settings (e.g. for stacked/grid view or open a new tab)
    • They want more than 100 active tabs
    • Overriding tabs when the limit is 100 could be improved (consider mitigating by informing users or save to reading list feature)
    • Setting to close tabs after x days or after app closed
    • History within a tab is important to users (consider browser back button in addition to the app back button)
    • Users requested tab groups/categories
    • Gesture based navigation, move tabs to the bottom for easier access