The AMC toggle seems to be working great! Please note: the mocks in the description of this task are currently outdated (but I didn't want to swap in the new ones for the sake of posterity). Please refer to T214195 when making any further design changes to the settings page.

@Lea_WMDE here are the design specifications:

Seeing this bug on mobile today -- Android/Samsung Galaxy/Chrome/logged out

@Jdlrobson awesome. My apologies for not keeping this task up to date. I've updated the task description with the correct designs and links to the live prototype where you can get CSS details from

Here is a video of the bugs I was experiencing on iOS yesterday: https://drive.google.com/file/d/1MGmryRAoUdnRucfDBJT0KjyXpjbioLTA/view?usp=sharing. The same issues don't seem to occur on Android.

@Huji I made this task more general and created two sub tasks for the proposed changes

@Huji that would be awesome. Please tag me on the task.

I've added QA instructions to the task. Also, I just tried this again on Android/Chrome, however the scroll is not animating as it was before.

All set. Thanks @Huji!

Look great. Subtle but effective.

ah, thank you for the reminder @Jdlrobson : )

@Niedzielski my opinion is that a page preview of the page you're currently on is more confusing than helpful. I understand from the perspective of consistency that any link should have a corresponding page preview, however given the context (you are already on the page) I think the page preview a) doesn't add value to your experience, and b) potentially confuses you (for myself at least it usually takes me a few seconds to realize that I'm looking at a preview of the page I'm currently on). I am therefore okay with breaking the pattern in this case.

@Jdlrobson @pmiazga apologies for the switch up / sneak attack here. When we initially discussed the idea of an incremental/progressive AMC release I mentioned that one counter-balance I'd like is an explicit call-out on the settings page to let users know what we're up to, roughly what's coming, and a place to submit feedback. I should've explicitly mentioned to y'all that I was following through with that idea here, with these updated mocks. It sounds like we've got things sorted now.

@Huji would it be okay for me to assign this task to you? I believe all the details you need are in the description.

For completion the logical next step were to define the :active (currently pressed) link color as well…

@RHo ah, thank you for the additional context. That was great to read, and good to know everything still checks out.

From an experience perspective I am fine with us not showing page previews for so called self-links. So far I cannot think of any cases where this would present an issue.

On T212216#4853533 @Niedzielski asked:

Android / Chrome: the scroll effect is working, however I have to press the up/down arrow twice in order to trigger the scroll.

I agree with @Jdlrobson here. Adding in @RHo and @Pginer-WMF for further consideration regarding the button triggering some kind of translation flow when no translations exist.

@Nirzar thanks for taking a look. I too think purple 1 is a good choice.

@Nirzar you can see colors in context here: https://en.m.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox#Link_color_tests

@Jdlrobson is there a general practice against self linking? Do you know where there is WP documentation about this? In terms of manually created self links within the article contents I wonder if this issue lies more within the editing realm?

I spoke with Nirzar and we concluded that this behavior is not desired. Two possible solutions:

• replace the page preview with a simple tooltip that says something like "jump to where this is referenced in the article" (hopefully more concisely than that)
• remove the page preview and do nothing on hover

@Volker_E can you clarify the difference between them for my understanding?

@Jdlrobson do you think it would make sense to merge this with T190549?

@RHo @MMiller_WMF this isn't very high priority from our perspective, but perhaps something y'all would be interested in working on? Happy to toss it over to you

@Jdlrobson how can I try this out on mobile? I went to https://en.wikipedia.org/w/index.php?title=Special:CreateAccount&campaign=loginCTA&useskin=minerva but the experience seemed to be the same as what's currently in production (i.e. I'm not seeing inline error messages like there are in the GIF in the description)

Thanks for the questions.

Due to the slow speed of the scroll the affect is a bit frustrating on long articles. Additionally, if you've used the TOC to navigate to multiple sections, then use the back button, it results in slightly confusing behavior. My apologies for not anticipating this earlier.
Here is a screen recording

• do we believe that the first letter of the Wikidata descriptions should always be capitalized?
• is the current best practice on Wikidata to capitalize the first letter of descriptions? If not (i.e. we can't count on them slowly being updated), what other method do you think might work to achieve the capitalization @Jdlrobson? From Wikidata's perspective I could imagine that storing the description without any capitalization is preferred

@Huji thanks for your investigation and thoughts. I would just like to clarify a few things to make sure we're both approaching this from the same foundation:

@ovasileva sounds good, will do signoff today

@Jdlrobson there isn't a specific task for History, although this task covers history as well as a few other things: T210659.

Interesting...okay, so something like this might make more sense, however:

1. in some cases the panel itself will need to be scroll-able (assuming we don't want to make it taller - I imagine this would frustrate people)
2. in most(?) cases the page itself will also be scroll-able. It does seem like we could remove the Wikipedia page footer from the diff views so at least shorter diffs don't result in a scroll-able page.

@Dvorapa good catch, I forgot about the Thank button. Here is an updated design for consideration:

Looks great to me on desktop and mobile. @abian were there any specific concerns?

@Jdlrobson maybe some additional clarification is needed — you said:

The request is to make it behave like a mobile device in portrait mode, but a tablet device in landscape mode.

@Force_Radical this is awesome. It looks like there is an updated editUndo icon on OOUI. Although I wonder if the icon adds much in this context? I think it also potentially works well to just have "Undo edit" as the label on the button:

I tested the following pages via https://polishdeveloper.pl/wmf/proton/, and found no major issues:

Confirming this bug (although on iOS/Chrome & Safari I am unable to reproduce it). As far as I can tell this only occurs as the result of using the browsers "forward" button to enter into the media overlay. I would guess this isn't a particularly common flow, and thus this is lower priority, but perhaps we could confirm with data?

I am unable to reproduce this on either Android or iOS. However, oddly, if I follow the reproduction steps on T211162, I am then able to reproduce the bug described here.

@ovasileva I'm fine with us not supporting fully functional page previews at this browser width. Oddly enough there is enough room to display the preview though, so I wonder if there's something relatively straightforward we can tweak in the display logic that avoids this?

Just for clarification, this is what happens on desktop/Vector:

@Jdlrobson adding your idea here of including the language icon (whatever it ends up being) next to the "Language" list title in vector

In T193993#4249743 I suggested:

@Niedzielski I'm +1 for making this change. Here's a basic mockup:

@Jdlrobson what device/browser are you seeing this on? I just checked on an iPhone/Chrome & Safari and am not seeing this issue.

@Jdlrobson I agree that Option 2 seems like the best UX. In terms of optimizing the threshold so that we minimize requests, I'm not quite sure how to go about figuring that out. Trial+error: trying, looking at data, and revising. Or some kind of engineering solution that predicts the chances of someone reaching the bottom?

Seems like for protected articles we exclude the edit icons from sections. I think we should follow that pattern. Moving out of design.

@Jdlrobson can you clarify what the open question is?

@Jdlrobson I think this is ready to go. Going to move it out of design.

Some notes based on the discussion in design review on 11/21:

This is rad. In terms of UX it works great, as I would expect.

@Remagoxer thanks for creating this task. Which app are you using? When you say "ability to see what changed" are you referring to a diff? Here is an example: https://en.wikipedia.org/w/index.php?title=District_Attorney_of_Philadelphia&type=revision&diff=867562841&oldid=867562827&diffmode=source

@Jdlrobson @ovasileva set priority to low, feel free to change