Theme- Different theme for editing than for reading.

current APK, for initial design pass:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/2905669405

@Dbrant – I’ll take a closer look at this and provide designs in the second half of the week/maybe the beginning of the next one due to other priorities. I’m very much looking forward to doing this task! 🤩

Ok, this is excellent work @Dbrant 👏

I used this apk for the review since the one mentioned T313223#8178590 is expired:

1) Updates to bottom toolbar designs (Figma)

State	Before	After
Default
Active
Scroll

• UX updates:
  • Add dropdowns next to the text (B) and title (H1) formatting button to indicate the second row of actions (increased affordance)
  • Add a close icon add the end of the secondary edit toolbar row to make dismissing easier and maximize screen estate
  • Add paragraph icon within the second row of title (H1) formatting options at the end (after the titles)
• Change the sizing of all toolbar buttons to 48*48dp
• Colors updates:
  • edit-toolbar-background-color: color_group_50
  • edit-toolbar-border-color: color_group_18
  • edit-toolbar-item-color: color_group_5
  • edit-toolbar-item-color__active: color_group_3
• Icon updates:
  • Are now more in sync with the visual editor. Platform guidelines from Material are still at the top of the hierarchy when choosing icons, so whenever a Material icon is available, we use it.
  • Make sure that all buttons reveal their accessibility text correctly (a few icons currently use an alternative text that isn’t accurate when long pressing)
  • Both text (B) and title formatting (H1) buttons use the first icon from the second row to make it easier to grasp what they are about
    • Update text formatting icon to bold
    • Update title icon (h1, h2, h3, h4) to title, notice that the h1-h5 icons have been updated (Roboto Bold, 18sp, 0.5sp letter-spacing)
  • Update the preview link icon to visibility and remove the label
    • Update template icon to OOUI’s Template/Puzzle and remove the label
    • Change <big> icon to OOUI’s bigger
    • Change <small> icon to OOUI’s smaller

2) Move Show line numbers down one row in the settings and disable it by default. Along our philosophy to get closer to a WYSIWYG editor and font switch to sans serif– this makes more sense.

3) Minimize space on the left for line numbers. E.g. in this article, it’s double-digit only and uses too much space on the right. Ideally, the size adapts based on the total amount of line numbers.

4) Hide formatting options when the keyboard is collapsed, as their mainly used when editing text. Make sure to “reset” the toolbar when the keyboard collapse button has been tapped (only show 1 row of options afterward)

5) Bonus investigation: is there any way we can implement the interaction model below? It’s hiding the keyboard when intentionally scrolling down:

https://www.dropbox.com/s/gfrvz1765urz9s4/RPReplay_Final1662543860.MP4?dl=0

Background: I usability tested this pattern when working on iA Writer. The enhancement was exceptionally well received by participants and users of the app.

On another note @SNowick_WMF @JTannerWMF – I think we should instrument the usage of the edit toolbar (if not already done) so we can optimize the order and grouping of the features over time. Check out T313223#8216900 for visuals and more details.

https://github.com/wikimedia/apps-android-wikipedia/actions/runs/3010172366

In T313223#8216900, @scblr wrote:

1) Updates to bottom toolbar designs (Figma)

👍 👍 👍

• Add paragraph icon within the second row of title (H1) formatting options at the end (after the titles)

What does the "paragraph" button do? And the link in the above point looks incorrect.

• Change the sizing of all toolbar buttons to 48*48dp
• Colors updates:
• Icon updates:

👍 👍 👍

2) Move Show line numbers down one row in the settings and disable it by default. Along our philosophy to get closer to a WYSIWYG editor and font switch to sans serif– this makes more sense.

👍

3) Minimize space on the left for line numbers. E.g. in this article, it’s double-digit only and uses too much space on the right. Ideally, the size adapts based on the total amount of line numbers.

This is really not feasible, if we want it to remain performant. It must be a fixed, preallocated width.

4) Hide formatting options when the keyboard is collapsed, as their mainly used when editing text. Make sure to “reset” the toolbar when the keyboard collapse button has been tapped (only show 1 row of options afterward)

👍

5) Bonus investigation: is there any way we can implement the interaction model below? It’s hiding the keyboard when intentionally scrolling down:

I don't think this will be feasible, and it looks like iA Writer for Android doesn't do this.

@Dbrant – thanks for the updates; will look at them tomorrow.

To answer your questions:

What does the "paragraph" button do?

The paragraph button would do the same thing as on Desktop (Visual Editor) and basically remove formatting:

https://www.dropbox.com/s/nzq20zk1n5dstp3/CleanShot%202022-09-07%20at%2023.05.02.mp4?dl=0

And the link in the above point looks incorrect.

This is the correct link for the P icon, I know it’s used for parking usually (😏) – but couldn’t find a better one. Especially icons like this or this are pre-occupied for left/right aligning text and will likely lead to confusion. The P is also in line with the H1-H4 icons.

In T313223#8219018, @scblr wrote:

The paragraph button would do the same thing as on Desktop (Visual Editor) and basically remove formatting:

Our syntax buttons are one-way only, with a few very specific exceptions. The "paragraph" button has no way of knowing what formatting is currently surrounding the cursor.

In T313223#8219047, @Dbrant wrote:

In T313223#8219018, @scblr wrote:

The paragraph button would do the same thing as on Desktop (Visual Editor) and basically remove formatting:

Our syntax buttons are one-way only, with a few very specific exceptions. The "paragraph" button has no way of knowing what formatting is currently surrounding the cursor.

So, if a word is highlighted or if the cursor is within the markup of any kind – can’t we just remove all markup that surrounds it without knowing what it is, e.g. by using regex ?

Most updates are spot on @Dbrant – impressed by your implementation speed 🏃‍♂️💨

1) A clarifying note on this:

4) Hide formatting options when the keyboard is collapsed, as their mainly used when editing text. Make sure to “reset” the toolbar when the keyboard collapse button has been tapped (only show 1 row of options afterward)

👍

Can we make sure to show the edit-toolbar when a keyboard case or external keyboard is connected? Since there won’t be a software keyboard displayed, I’m worried they don’t see the edit-toolbar completely. Thanks for checking!

2) Please add (accessibility) labels to these buttons on long-press:

3) Show h1 to h5, similar to the visual editor on Desktop Wikipedia. To be precise, we can adapt the (accessibility) label for h2-h5 accessibility to Sub-heading x.

Desktop	Android

On a side note, I think your instinct was right to leave out the Page title option 👏

4) Top and bottom rows seem to have different heights (difference of 2-3dp) – please adjust:

Also, make sure that the height of the rows/buttons (tap target sizes) are at least 48*48dp, per Material’s spec. It’s currently around 44dp.

https://github.com/wikimedia/apps-android-wikipedia/actions/runs/3022798879

In T313223#8220189, @scblr wrote:

Most updates are spot on @Dbrant – impressed by your implementation speed 🏃‍♂️💨

Can we make sure to show the edit-toolbar when a keyboard case or external keyboard is connected? Since there won’t be a software keyboard displayed, I’m worried they don’t see the edit-toolbar completely. Thanks for checking!

great point, and... confirmed👍

2) Please add (accessibility) labels to these buttons on long-press:

👍

3) Show h1 to h5, similar to the visual editor on Desktop Wikipedia. To be precise, we can adapt the (accessibility) label for h2-h5 accessibility to Sub-heading x.

We should not show H1, since H1 is the page title, and it will never be necessary to add the page title when editing an existing page. Notice that in the Desktop wikitext editor, you only get H2 through H5.

4) Top and bottom rows seem to have different heights (difference of 2-3dp) – please adjust:
Also, make sure that the height of the rows/buttons (tap target sizes) are at least 48*48dp, per Material’s spec. It’s currently around 44dp.

👍

@Dbrant I got a little bit of energy after taking 500mg Paracetamol 💊😏 (context: currently out sick). I just checked the APK, and the updates look great. One piece of feedback re: this 👇

3) Show h1 to h5, similar to the visual editor on Desktop Wikipedia. To be precise, we can adapt the (accessibility) label for h2-h5 accessibility to Sub-heading x.

We should not show H1, since H1 is the page title, and it will never be necessary to add the page title when editing an existing page. Notice that in the Desktop wikitext editor, you only get H2 through H5.

This makes sense. What we need to do to represent it correctly is change the “first-row” button to an h2 rather than h1, like this:

+1 user sent the next through Android support email:

I'm a regular Wikipedia mobile editor using the excellent and continually improving Wikipedia app for Android. Though I love the app and have been a vocal proponent of its convenience and accessibility for years, like everything that's good it has its occasional imperfections.

Recently I've encountered a very peculiar imperfection when editing via the app: swype-to-type keyboard functionality seems to break when the editor is open. I'm as much a veteran swype user as I am a WP fiend, so it's very frustrating for me not to be able to use swype-style typing on my phone when editing.

I suppose I should clarify that the keyboard input system I'm referring to is not Swype per se - the original application is now discontinued. I'm using "swype" as the genericized term for all similar virtual keyboard typing systems, e.g. Google's 'glide typing', which involves typing words by dragging your finger from letter to letter without lifting it from the screen. I use this input system in every app including SMS and email.

And it used to work when editing Wikipedia, too - but just in the past week or so, inexplicably, it no longer does. It just appears to have stopped working entirely. I originally thought the issue might be unrelated to the Wikipedia app and instead be a wider problem, but it only happens when editing Wikipedia - in every other app and context, I can still swype just fine. Even when searching Wikipedia, by typing in the search box, swype still works normally. It only stops working when I click the icon to edit an article or section and the wiki markup appears. I've tried updating both my phone and the Wikipedia app, uninstalling/reinstalling, playing with keyboard settings, even installing non-default keyboard apps like Gboard, all to no avail. The problem is the same with all of them: when editing Wikipedia, and only when editing Wikipedia, swype-to-type doesn't work anymore.

So I'm thinking now that there may be a bug that was introduced with the latest update of the Wikipedia app. Can you guys check your code and see if that's the source? I suppose it's possible it's still something unique to my phone, but I don't know what might've changed in just the past week; it has always worked just fine in the past, never an issue until now. I'm struggling to find an explanation.

I appreciate any help and troubleshooting you can provide. I know you guys are good for it - I've written to you about other issues in the past and you've fixed them relatively quickly. I have every reason to believe you'll do the same here. You've built one of the most well-loved apps in smartphone history, and I am very grateful for all the customer service that comes along with it. Thank you so much for your time and attention - please let me know what you find out!

In T313223#8235996, @scblr wrote:

This makes sense. What we need to do to represent it correctly is change the “first-row” button to an h2 rather than h1, like this:

https://github.com/wikimedia/apps-android-wikipedia/actions/runs/3082861328

Done!

Looks good to me @Dbrant

Looks good to me on 2.7.50421-beta-2022-10-03

+1 user through the Android email support:

I use Wikipedia application, Japanese Edition for Android smartphone.

However, I tried to edit Wikipedia
pages in Japanese, "hiragana", "katakana" and "kanji", but input mode didn't turn into Japanese mode.

I would appreciate it if you find the cause.

This can still go in production, I wonder if the add a link icon and image icon should be swapped, and the preview link icon should be moved up. I say that because it feels strange that adding a link is so far away from previewing it? Also after you preview a link they keyboard goes down, but not sure if that is something on our end we could fix? @Dbrant @scblr

@JTannerWMF

This can still go in production, I wonder if the add a link icon and image icon should be swapped, and the preview link icon should be moved up.

That makes sense. To recap, you are suggesting the following order:

Pro tip: long press a button to see its label

Also after you preview a link they keyboard goes down, but not sure if that is something on our end we could fix?

+1 if feasible. To recap, what should happen:

1. User taps inside a link in the editor (keyboard shows)
2. User taps preview icon (bottom sheet appears)
3. User taps space above bottom sheet (bottom sheet closes)
4. Keyboard shows