@Jdlrobson how would someone find such a page?

Advanced Mobile Contributions solves the history and talk use cases. I wonder if we should consider adding "View categories" as a link in the AMC page actions toolbar overflow menu (T216418) @Jdlrobson @ovasileva?

Clarification:

I followed the replication steps in T217805#5010345 but I'm not clear on what the issue is / what to be looking for. After clicking "back" I landed at the top of the article, not the section I was at when I left the article.

FYI @MMiller_WMF

Related to this topic: it seems like we'd benefit (both on iOS and Android) from moving the "Publish" button in the Talk > Reply UI to the header. For Android users this would mean the button is always visible, and for both iOS and Android it would be a more consistent experience with other Publish/Save actions.

Spoke with @Jdlrobson and now have more context here. As I understand it, on iOS (any browser) fixed elements only scroll away as the result of tapping into a <textarea> element (note this doesn't occur for <input>). Since the inconsistent behavior between Android and iOS is the result of an OS-level difference I don't think it's critical (or realistic) for us to have a consistent experience.

@Niharika I've just pinged @Nirzar and @Prtksxna off-thread to comment on the sketch below. I'm also curious about your thoughts. I will aim to collect design feedback and post an update here with an opinionated rationale within the next week.

In T217616#5038738, @Volker_E wrote:

Do we agree that we should treat non-Arabic numeral ordered lists equal to Arabic numeral (all Latin scripts to my knowledge) ones?
If we don't set decimal as default, ordered lists fall back to decimal. Which we should override with better treatment for serving our communities (we do this in other skins already).

Can somebody clarify the open design questions here?

@Jdlrobson helped me better understand the issue here. Starting with what we do on vector/desktop:

Ok, all clear here. Moving this out of design.

I've left a comment on T218414 to address desired VE behavior. Regarding all other overlays, I think it's safe to say that the rule should be that the header remains fixed, regardless of the keyboard being open or closed. Perhaps there will be exceptions in the future, but it seems like a sensible starting point to keep them fixed by default.

@iamjessklein and I met to discuss this earlier today. There are at least two different headers in the VE experience:

general header	text-tools header

General header - as long as this header always re-appears at the top of the screen upon closing the keyboard (as it currently seems to when in source-editing mode, though not in visual-editing mode), it is not necessarily an issue that it scrolls offscreen while the keyboard is active. There is even a perspective that it's beneficial to the user for it to disappear while the keyboard is open since there is such limited screen space at that time.

I wanted to share some additional thoughts that came up today.

Thanks for pointing that out @Jony. I assume you're referring to the Move page action? If so, that action would be part of the page actions menu, which you can see in T216418. Currently we are not planning to include the Move page action, however if you think there's a strong case for including it on mobile it'd be great for you to add a comment on that task.

That makes sense to me. Moving it over.

Alright, the two points of feedback I received were about feature parity between the JS and non-JS search results experience. Since they are independent issues I think it makes sense to put them in a separate task. I will note them here for completeness (and so I can reference this when I have time to make the separate task).

In T217197#5002681, @Jdlrobson wrote:

Flagged revs is another example:
https://id.m.wikipedia.org/wiki/Si_Doel_Anak_Sekolahan

Ok. Per @ovasileva's suggestion I've added a design recommendation to this task (which I believe everyone in this discussion is already in support of), and created T218208 to investigate the larger question.

@ovasileva to clarify, is the question we'd like to answer (potentially with research):

• should redlinks lead to the creation/edit mode, or a read mode?
  • should the default behavior differ based on certain factors (e.g. namespace), or can we be entirely consistent?

Not clear on what the proposed change is?
Current: "Success! Your edit was saved"
Proposed: "Success! Your edit was published"

I've just added some updated designs to the task description. I sent them to the design team for review so will see if I get any notes in the next few days, otherwise I think we can consider this good to go.

I'm not particularly familiar with red links and how we handle them. Although I wonder if it's as simple as: whenever following a red link, unless it's stated in the interface that "You can create page X" (as it is in the screenshot below), that you land on the empty-state version of the page. I imagine there are reasons why sometimes on desktop you'd want to land directly in the editor, but to mitigate possible confusion it seems like the additional step (of landing on the empty state, then having to navigate to the editor) would be worth it no mater what. I at least feel confident enough saying this is true for mobile.

From an experience perspective, I think we should aim to have the same behavior as we do when navigating to a red user link from a diff:

diff	empty user page
tap on username

Looks good to me. Here is what I'm seeing on staging:

In T18691#5002545, @Esanders wrote:

In T18691#5001370, @iamjessklein wrote:

I suspect that this will be a bit of cognitive overload for the user, showing them so many different action options.

I agree with this. I prefer the hover -> link icon in gutter approach proposed earlier and used on sites like GitHub: https://github.com/wikimedia/eslint-config-wikimedia#example-configurations

I disagree. I do not believe that the addition of one action, only on '<h2>` elements, (resulting in two actions total for the majority of users) warrants cognitive overload. Furthermore, the expected increase in awareness by showing the link without having to hover, in my opinion, is worth the persistent presence of the action (even if it comes at the cost of causing a slight distraction).

I think this task is almost ready to go. The blocking element is the icon "add article" icon, which is not currently in OOUI. I've spoken with @Volker_E and he thinks it would be a good icon to add.

@ovasileva FYI this came up during grooming today. Apparently this component would allow us to present the type of contextual AMC hook that we've discussed, such as:

After speaking with @Jdrewniak a bit more, we think the best course of action is to continue using the current toolbar layout for now, which means there will be no jumping icons. With the addition of the history icon AMC users will see:

iOS	Android	Android w/ map

@Jdlrobson we can leave the font-size as is. Assuming it would be inside this div <div id="bodyContent" class="content"> (?) the right/left margins will be taken care of, so we should just need margin-top:10px. If it isn't inside that div we should just mirror its margin, which is margin: 0 16px;.

@dbarratt great catch — that was not intentional. I've just updated the left/extreme case mockup.

Alright, there have been a lot of awesome ideas since I last posted here. I am attempting to address them all in these updated designs. General notes:

• As @Msftwikipmey pointed out, the Edit (and Edit source) links are currently present for all section headers. This made me realize that the page I used for the initial designs I posted perhaps wasn't the best (since it only had <h2>s). So this time I'm using two different Wikipedia pages: one which is rather extreme (it has a bunch of headings, all the way down to <h5>), and another which is more ordinary (<h2>s and one <h3>).
• While logged-in users with their Editing mode preference set to "show me both editor tabs" will see both "Edit" and "Edit source" actions, I've decided to focus the mockups on the more common case, which is people who only see Edit (this would be all logged out users, and all logged in users without the "both editor tabs" setting).

In addition to the float being picked up from the drawer header/title's CSS (.drawer.references .cite .text), it is also picking up other styling rules, which makes the link look different from the rest of the content (letter-spacing, font-size, text-transform). Perhaps we could add the following CSS to .drawer.references .cite .text a:

ok, the proposed solution looks good to me. Moving this out of design.

Looking at the video that @matmarex posted (T210630#4938902), the Edit overlay (at least in the case of section editing) has the appearance that the content on-screen before the overlay is called, remains on-screen, and that the overlay is really just the toolbar on top of the content that was already there. I'm mainly just curious what's actually happening in that case, and ultimately if these are two different types of overlays: one that is seamlessly transitioning using existing content (e.g. section editing overlay), and another that transitions an entirely new view on top of the existing one (e.g. Talk or Languages).

To clarify what I'm understanding to be the main point of this task, if you compare footnote 11 on https://de.m.wikipedia.org/wiki/Axel_Krau%C3%9Fe:

Ok cool. Moving out of this column.

+1

documenting a conversation @Jdrewniak and I had offline. It seems like we may largely avoid the awkwardness loading situation, at least for now, because the following default cases will not be affected by it:

AMC off (iOS)	AMC off (Android)	AMC on (iOS/Android)

@Jdlrobson @Jdrewniak: ok, thanks for that information. I think I should create a separate ticket for the external link icon issue. Any ideas on the main issue?

Notice that, in the footnote tooltip, the link is in the wrong position entirely. It should actually be at the very beginning of the footnote.

@Jdlrobson my inclination is still that this isn't worth fixing. Is there something new that I'm missing? It seems like it would happen quite rarely, plus at that screen width the site doesn't do great in general, so I'm not sure it's worth fixing page previews (of all things). Disabling the entire feature seems like overkill, as you can still use it and get value from it in many (maybe even most) cases.

It seems like there are two open questions here:

1. can we fix the styling of infobox captions on mobile, such that read more like titles?
2. should include infobox captions and titles if they are an exact match to the page title?

@Jdlrobson I think it makes sense to move them in between hatnotes and the article content. I imagine this content structure map isn't complete (side note, it'd be great if we maintained something like this on one of our project pages to help people, and ourselves, understand how Vector transposes into Minerva/MFE), but here is what I've got so far:

A few questions & thoughts regarding the design here:

• Would it be beneficial to make this available without having to hover over the page title? I believe it would increase discoverability, decrease complexity of interaction, and minimize elements on the page jumping around.
• Might we think about this more as a "share" feature, rather than an "obtain link" feature? Perhaps the nuance is subtle, but I think it might make sense to focus on (what I'm guessing will be the most common) intent, which is wanting to share a section with someone, rather than the more technical aspect which is obtaining the link to the section. "Share" also feels like an appropriate companion to "Edit", in that they are both actions you can take on the section.

I'm not sure it's worth introducing another term here.

• I understand the semantic concern, however I'm assuming that the majority of the footnotes are references/citations, and that comments are an edge case.
• We are already referring to it as a "reference" in the title of the preview (Book reference, Journal reference, etc.) so I think it might be more confusing to then have a button that says "Jump to footnote"...it feels disconnected from the thing you're already looking at.
• As far as I can tell the article section where you are jumping to is called "References" (in English), so there is already the idea that we call these things references, even if sometimes they are just comments

A few months ago our team was thinking about how to improve in-article navigation. At the time we weren't considering find-in-page as an aspect of in-article navigation, but interestingly during user testing it came up a lot, and I think it's fair to categorize it as a navigational tool. Some people scroll, some people search — they're different ways of accomplishing the same task.

Looks awesome, thanks for pinging me.