Hi, My name is Moshtagh, I'm a Product Designer from Iran. I followed the tasks here to find a way to help the project, I saw this task and thought it could be a point for starting.

I believe if we want not to allow people to publish without an edit summary, then we should lead the user to type sth by default instead of offering some ready options. That's why I think it's a good idea to have a text field and use the "Fixed typo", "Fixed grammar" & "Added links" as some ready-to-use texts which can help the user to type faster.

here's my suggestion for the edit summary:

Figma file

I used the Material design and our type guidelines

Please feel free to tell me about edits in case I can continue working on it.

Hi Dear @JTannerWMF

How can I make it ready to develop?

Wow thank you so much for this feedback and the work you've done @Mostafameraji , we will draw inspiration from it to implement these changes. Our team's lead designer @scblr will add just a few more guided notes for the engineers, but I hope you stay engaged on this task to provide input and reviews as we build

As it relates to the point about consistency of watchlist and edit history, please see the images

Added more definitions on how to handle custom text input storage to the task, per @JTannerWMF’s question from yesterday.

8) Chip is stored

• This feature exists already and might help users prepopulate the field if tasks are done repeatedly. We will keep it to respect existing user flows.
• After publishing an edit summary with custom text, the contents of the custom text (e.g., “Formatting") are saved as a chip below the input field.
• Chips appear in a horizontally scrollable list, per Material’s definition.
• Chips with custom text can be removed by tapping the “remove” icon.

CC @cooltey @Dbrant

@scblr @Dbrant and I talked about this and will get rid of the "Other" chip or custom stored chip but keep the "Fixed Grammar", Added Link", "fixed typo" and when someone types their summary in the bar what they've written before will show up in the input field as a drop down option.

I have completed the designs per our discussion @Dbrant @JTannerWMF. Check out the task’s description and especially step 6) Suggestions: 👇

• This feature exists already and might help users prepopulate the field if tasks are done repeatedly. We will keep it to respect existing user flows.
• After publishing a custom edit summary, the contents of it (e.g., “Formatting") are stored.
• Once users start typing, the previously stored custom edit summary is presented as an autocomplete suggestion.
• Tapping the suggestion fills the input field and takes users to 7)

And I moved the task to the next column (Needs analytics). I suggest measuring if the changes in the task’s description lead to more (valuable) edit summaries written in the Android app (CC @SNowick_WMF).

Hi @scblr

The implementation is completed. Please download the APK from the ticket description. Thanks.

BTW, I found the following things that would like to discuss with you:

1. I tried to reduce the margins between summary tags but looks like the last item will be pushed to the next line in a small screen device. (I am using Samsung S9).

2. About the "Watch this page" checkbox, I found the desktop version also provides an option to change the expiry. Should we follow that?

In T296952#8196779, @cooltey wrote:

Hi @scblr

The implementation is completed. Please download the APK from the ticket description. Thanks.

BTW, I found the following things that would like to discuss with you:

1. I tried to reduce the margins between summary tags but looks like the last item will be pushed to the next line in a small screen device. (I am using Samsung S9).

Can we use horizontal scrolling for these “chips” instead of stacking?

2. About the "Watch this page" checkbox, I found the desktop version also provides an option to change the expiry. Should we follow that?

To not overwhelm users with settings – I think it’s fine to keep it a simple checkbox.

Hi @scblr

Can we use horizontal scrolling for these “chips” instead of stacking?

Yes and done.

To not overwhelm users with settings – I think it’s fine to keep it a simple checkbox.

👍

Excellent work so far @cooltey – I noticed some other issues:

1) Change color of status bar in the Preview to color_group_50 (same as in the article)

2) Tapping the chips below should move the cursor to the end, not the beginning

Video explanation: https://www.dropbox.com/s/20auz1j8bfut0xw/screen-20220905-143640.mp4?dl=0

3) There are color / theme issues:

1. Use color_group_3 for the checkbox (to increase affordance when empty, per designs)
2. Use [[ color_group_5 | color_group_5 ]] for the label
3. For disabled elements (e.g. Watch this page when not available), use the same definitions as in 1. and 2. but reduce the opacity to 50%

4) Open all these pages in-app, not in the browser:

5) Chip style: use the same colors for the label and background from the results in reading lists:

In T296952#8211490, @scblr wrote:

Excellent work so far @cooltey – I noticed some other issues:

1) Change color of status bar in the Preview to color_group_50 (same as in the article)
2) Tapping the chips below should move the cursor to the end, not the beginning
3) There are color / theme issues:
4) Open all these pages in-app, not in the browser:
5) Chip style: use the same colors for the label and background from the results in reading lists:

@scblr
All done! Please download the updated APK from the ticket description. Thanks!

Perfect @cooltey – one last issue before moving it to QA signoff.

1) Due to the fact that links are now opened in-app (🥳) – we can remove the external link icon here:

Hi @scblr,

1. Due to the fact that links are now opened in-app (🥳) – we can remove the external link icon here:

Done!

Great! Moving it to the next column! 🎯

Hi @scblr

Based on @Dbrant's code review comment here: https://github.com/wikimedia/apps-android-wikipedia/pull/3536#pullrequestreview-1100817361

The Wikipedia URLs will bring up the app-chooser when the user clicks on the links and it will break the current edit session. It would be better if we use the previous approach, which opens the URL in an external browser. Does that make sense to you?

Ok, but isn’t the app-chooser an edge case for us who work on the app and have multiple Wikipedia app versions installed (Production, Beta, Alpha, Dev)? What happens if you only have production installed– will it (breaking the current edit session) also happen? If the answer is yes, then it makes sense to use the previous approach (open in browser and add the external link icon again)

Scriblr, the answer is yes, if I'm understanding the context right. Before today, I only had the production version of the app installed and when editing on the mobile browser and trying to click publish, it would open up the app.

In T296952#8223525, @scblr wrote:

Ok, but isn’t the app-chooser an edge case for us who work on the app and have multiple Wikipedia app versions installed (Production, Beta, Alpha, Dev)? What happens if you only have production installed– will it (breaking the current edit session) also happen? If the answer is yes, then it makes sense to use the previous approach (open in browser and add the external link icon again)

@scblr

It will still pop up the app chooser that allows you to pick either your browsers or the Wikipedia app since the Wikipedia URLs are supported by browsers AND the Wikipedia app.

Thanks @cooltey & @Clovermoss, then please apply this:

If the answer is yes (app chooser pops up), then (...) use the previous approach (open in browser and add the external link icon again)

Looks good to me on 2.7.50420-alpha-2022-09-21

Looks good!

Actually moving this back to ensure we are being inclusive of languages. I will make a separate task for this.

I think we borrowed the links from iOS and when I click on the links for iOS it takes me to EN Wiki, but I am also testing with my device being in English for both Android and iOS was wondering if there was thought put into what help links people see on varying language wikis for edit summaries when iOS built this.

On Desktop it varies by language. On EN it takes people to the page we are directing people to, on AR it has no help links, on FR it sends it to the relevant help page for French. On Mobile Web on FR there aren't help links.