Hey @schoenbaechler please add a 2C variant for modes where the flow is not exposing editing and talk page elements or the toolbar. Someone navigates to customize experience and above the options in 1 customize experience there are reveal and hide toggles that turn on and off CTAs for Editing, the talk page entry point within the article, and allows the toolbar to be hidden completely.

Additionally, please have the behavior for picture 1, when a user slides Share up, it bumps down whichever option was last in the bottom bar, instead of "replacing" it

Also, please represent top bar as "Overflow Menu" and Bottom bar as "Article View Toolbar"

Just watched the recap videos. I love these!

I agree that user testing will be very helpful to determine which is most intuitive.

Two question for now:

• In variant A - Are toolbar items in the settings twice? Once in the overall settings, and once in the toolbar-specific settings screen? If so, can you move them around with the first screen?
• Do we have analytics on how often theme and/or font changed currently? Once every six months at most, or for some number of users near-daily? (In this case, changing multiple times over 10 minutes is “one change”.) Or is this something we could easily instrument to get some quick data?

I've updated my thinking from earlier, after considering the various options some more - I think variant A from the videos seems best, and I’m not even sure we need User Testing (though obviously I am fine with it if Jazmin/Robin want it).

Variant A - putting these options with the theme/font options on a toolbar item - seems like the best of all worlds. Given that users will now have the ability to move items from the toolbar to the overflow menu (via the customization that this feature is about), leaving this as a button lets every user do what they want - they can keep it close as a toolbar button, or banish it away to the overflow menu. (There is still a question as to whether the default setup should include this item as a button or overflow menu item, and I am registering no opinion on that.) The other two options make it more rigid (thus removing user choice), and I’m not sure I understand what is gained by them.

This is great feedback @MattCleinman.

I think variant A from the videos seems best, and I’m not even sure we need User Testing (though obviously I am fine with it if Jazmin/Robin want it).

I’m with you here, as it provides the most flexibility. I’ll run it by the design team today and will ask what they think.

Plus, I think we should consider different language and iconography:

• Is Theme still accurate? Does the Font icon (Tt) still represent what it is? I can imagine it being called View settings, Article view settings, Customize view or Article settings. The latter would allow for a straightforward integration in the general settings of the app.

There is still a question as to whether the default setup should include this item as a button or overflow menu item, and I am registering no opinion on that.

I think we should keep the default as is, since users are used to it. We could onboard users to the new functionality with a tooltip. This would guarantee to not break the existing experience (and muscle memory) of existing users while offering the benefits of the new functionality.

(Feedback on Slack)
to ensure we’re on the same page: users can have 1-5 buttons on the toolbar, right? Not fixed at 5? And if they drag away all buttons, we essentially turn off the toolbar? (edited)

This sounds good and feels intuitive. I’ll design a screen for the described state and will update the task’s description.

Feedback from design review:

Design team members almost unanimously voted for variant A from these three directions. Here’s the recording (the first 20minutes) of the presentation. The GIST of the (written and vocal) feedback I received is:

• Variant A looks good → one thing at a time. Getting to the customization intentionally.
• Include a “reset to default” setting.
• “Reading focus mode” and “Hide toolbar on scroll” can be unified to just “Reading focus mode” with a supporting copy that says what it does exactly.
• Related feedback: How will users know the difference between reading focus mode and hide the toolbar on scroll?
• Onboarding: ask people how they use the app and then adjust the default toolbar based on that (can be done at a later stage as well).
• Add copy to let users know how many items they can add to their toolbar.
• Further work and refine UX copy
• Instrumentation? How can we instrument this and track its usage?
• Define behavior if there’s just 0,1,2,3,4 toolbar item

I’m currently processing this and will update the task’s description and visuals accordingly.

Robin and I chatted today, he will create two subtasks and put it in Ready for Dev by EOD:

• Reading Mode: Hies Talk page bubble, Editing CTAs and hides toolbar on scroll
• Exposing the theme section through the bottom sheet

TBD:

• Copy of new features
• How the new elements will appear when someone access theme via settings
• The number of quick links available to add and remove
• Toolbar onboarding and education

@JTannerWMF

• Reading Mode: Hies Talk page bubble, Editing CTAs and hides toolbar on scroll

T254771

Will incorporate the active conversation UI element (talk page bubble) into designs tomorrow.

• Exposing the theme section through the bottom sheet

T297134

Observation: Figma calls a related feature also “Quick actions”. It lets users quickly access actions via search box from anywhere in the app (similar to Spotlight on macOS or the large search bar on Android).

Great feedback from @Pginer-WMF to consider:

• Icon for reading focus mode: The reading focus mode option makes perfect sense there. However, given the above elements are more prominent (slider with icons for size, and big buttons for font) I wonder if the reading focus option may be a bit buried or perceived as a sub-option of fonts. Maybe adding an icon for it (book? glasses? headphones?) would help it to be a bit more prominent and sit at the same level as the options above.
• Usability test consideration: Small detail to check during usability: do people understand where items that are put in the "menu" section will appear? Since people access this option through the toolbar at the bottom maybe it is worth being more explicit (e.g., "menu on top"). But it would be good idea to confirm this may be an actual issue first with users before making the UI more verbose for no reason.
• Edit/reading mode distinction: Although the focus mode would hide several contextual entry points, the most significant change is the pencil icons to disappear. This may not be enough for a user that activated the focus mode as a reminder that it is still on. Otherwise there may be a risk that months after enabling it, the user becomes frustrated trying to correct a typo and does not find the pencil. I wonder if there are other changes that help to both focus on reading and setting the mode a bit more apart from the standard one. An example (not sure it is the best idea, just to illustrate the point), the bottom bar could become icon-only to give more space for reading.

@Dbrant @cooltey you probably thought about this already but I just realized it today: please make sure to display the new features (customizable toolbar, reading focus mode) in the app settings:

thanks