@Jdlrobson I've updated the task description to make things more clear

In T198708#7155561, @Jdlrobson wrote:

In T198708#7155545, @alexhollender wrote:

@Jdlrobson do you understand what is considered the "footer"? I'm having a difficult time understanding this one.

To the left of the cog.

I believe the notification bell would have a red dot in this case, so perhaps we can just hide the yellow bar below a certain width?

In T284243#7146765, @Jdlrobson wrote:

@alexhollender are there any other options we could consider e.g. collapsing the message bar into an indicator of sorts at lower resolutions?
Perhaps we can reconsider the idea in T274428 and explore making this position absolute and dismissable?

In T193993#7145045, @ovasileva wrote:

This is also quite old. I'm going to go ahead and resolve. @alexhollender - let me know if you'd like to keep it open.

@Jdlrobson do you understand what is considered the "footer"? I'm having a difficult time understanding this one.

In T192408#7143727, @Jdlrobson wrote:

Is this fixed?
@alexhollender we are focusing on page previews technical/design debt soon. Please consider if this should be a subtask of T284095.

In T201228#7143706, @Jdlrobson wrote:

At time of writing it takes 2 clicks to the history page from the diff page - one to click "Revision as of 06:47, 13 June 2018" and then the history link. Is this still too long?

In T189147#7143698, @Jdlrobson wrote:

@alexhollender should this be tagged with Minerva? Is it still relevant?

@Jdlrobson it seems ready for development. I've just updated the description to make things more clear.

@Jdlrobson it seems that all except one (T214653) of the child tasks are complete, so maybe we can close this epic? There are definitely more improvements to be made to the top of article experience on mobile, but not sure there is much guidance / value left in this task.

In T219659#7143521, @Jdlrobson wrote:

We'll be using the new wvui search experience for Minerva (T282473) so I'm declining this ticket.

Is there anything we need to add to T284242 for the wvui search experience to address this particular problem?

In T274428#7141509, @ovasileva wrote:

In T274428#7140021, @matmarex wrote:

What is the reasoning behind the capitalization in "You have a new Talk page message"? I noticed this change recently (while working on DiscussionTools) and it was distracting to me.

Not sure what I think about the capitalization. On one side it's the name of the page, on the other side, I agree that "You have a new talk page message" looks better. @alexhollender, @Volker_E - do we have guidelines around this? "You have a new Talk Page message" perhaps?

@Jdlrobson I apologize for the conflicting information.

Thanks for your thoughts @RHo & @MMiller_WMF.

In T274428#7140021, @matmarex wrote:

What is the reasoning behind the capitalization in "You have a new Talk page message"? I noticed this change recently (while working on DiscussionTools) and it was distracting to me.

@Jdlrobson maybe something like this? push the article toolbar down and put the notice under the user tools

@Jdlrobson I've added a basic mock

In T276562#7131998, @cjming wrote:

hi @alexhollender - some Qs about icons:

• For "Talk" links in the new personal menu (which is not included in this ticket's description's screenshot), which icon should be used? Based on what icons are available in https://doc.wikimedia.org/oojs-ui/master/demos/?page=icons&theme=wikimediaui&direction=ltr&platform=desktop and on https://phabricator.wikimedia.org/T276566, looks like "userTalk" is the one?

ah whoops, just updated the screenshot and yup, it's the userTalk one

@Jdlrobson ah gotcha, thanks for the clarification on both points 🙏

In T283811#7130634, @Jdlrobson wrote:

@alexhollender just to make it explicit, it sounds like you are okay with changing the default for all skins to show this link twice?

In T273473#7127579, @Jdlrobson wrote:

@alexhollender is this related to T277717 ?
it's hard to tell without the description.

@Jdlrobson I'm a little confused by you saying we currently hide the element, but if there's no confusion on your end there I think we can move on.

apologies for the delay. I think your proposal, @nray, sounds good — showing both the notification and the Talk link seems reasonable to me.

In T283756#7129849, @Jdlrobson wrote:

@alexhollender currently we hide this element by default in modern Vector. Do we want to show this for all wikis? If so, we probably should update the font-size in the codebase. If not, we should resolve this.

In T151115#7127320, @Jdlrobson wrote:

@alexhollender this is for mobile site but has a lot of overlap with T277717. One possible outcome of that ticket is we have a Vue component that can be applied to the mobile site. Could this task be repurposed so that it builds on top of T277717 in some way, or should it be merged into it?

not sure which task to attach this to — recording an idea that was proposed by benny476:

In T282027#7114398, @Srdjan wrote:
Also given that I don't think the vast majority of readers are bi or multilingual anyway, I'm skeptical on whether it could be called a "worthwhile tradeoff".

In T274428#7118633, @ovasileva wrote:

How does this sound for next steps:

• We continue with moving the link from the sidebar into the header when there is a new message
• We create a separate task for duplicating the link (having the link to the talk page appear in the menu while the new message link is available)

@alexhollender, @nray - does that sound ok?

@RHo @MMiller_WMF currently, in accordance with the general redlink treatment (Wiki documentation) some (all?) new members of the community see three red links in their personal tools area:

@Freddy2001 thanks for making this suggestion and providing mockups. We are currently planning to add a persistent/fixed table of contents alongside the article content (sort of like a sidebar), which I believe will provide the functionality you're requesting.

if we're going to work on making anything sticky on the mobile website I think we should prioritize sticky section headers, which would benefit significantly more people

@Huji what do you mean by "too big"? How are you making that determination?

In T274428#7113884, @nray wrote:

It was my understanding following our team conversation that we'll retain the position of the yellow bar /after/ notifications icons rather than before.

My interpretation from that conversation was that it was fine to change the order provided that @alexhollender and @ovasileva approved a screenshot of the change (which I posted in slack). Whether it comes before the bell icon or after the notifications icon (the status quo in legacy vector) is easy to change though. @alexhollender @ovasileva is one position more desirable than the other keeping in mind that this will affect legacy Vector and other skins as well?

@Jdlrobson ah yea sorry for the confusion there — in legacy there is an SVG for

In T276564#7086220, @bwang wrote:

@alexhollender The mocks seem to have a minimum width or width, do you have a particular value in mind? I've been using width: 12em or 192px, which looks like this: https://jmp.sh/Bz4MeqL

In T274428#7113858, @Jdlrobson wrote:

It was my understanding following our team conversation that we'll retain the position of the yellow bar /after/ notifications icons rather than before.

FYI @Pginer-WMF @Amire80 T273986#6876272

looks good. seems like the Wikimedia Incubator wordmark didn't make it in here. Perhaps we add this to our list for future logo deployments? @Jdlrobson @ovasileva

In T275048#7077001, @ECohen_WMDE wrote:

Thanks for the quick reply @Volker_E - I was following the pattern set by @alexhollender in the changes to the general search (added a screenshot below for reference). We didn't do any of our own usability testing to confirm quicker scanning, but after trying it out, it felt like a helpful improvement to carry over. Maybe Alex has additional references about how the decision was made for the new search component?

In T282027#7112405, @Izno wrote:

In T282027#7112359, @alexhollender wrote:

I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue.

Wikimedians are sensitive to whitespace. It will be a major issue.

[for clarity/simplicity sake I'm using the terms right and left and assuming a LTR language wiki here — the same points apply, just with right/left reversed, for RTL]

here are the steps I followed:

I think it would make sense for this to pass through design review. Where can it be tested @bwang?

In T276561#7070117, @cjming wrote:

Remove all the colors on hover/active/visited including the underline on the hover state, make text black for all states, and grey out the selected item for the full length of the menu width on hover?

@Jdlrobson my apologies for not being on top of this (I could have sworn we did spec this out somewhere, but alas). This is how I've been imagining it:

In T276561#7069668, @cjming wrote:

hi @alexhollender - Q re: hover/visited states for links in the new personal menu (including the personal page link + icon) -- the mocks in the ticket indicate that the links are all black - are there different colors for hover/active/visited states?

In T277534#7062844, @phuedx wrote:

@alexhollender: Could you confirm whether the quotation marks are necessary in the treatment? I ask because there's some heavy lifting involved in making them localisable.

WVUI tries to be as agnostic of MediaWiki as possible, including being agnostic of MediaWiki's i18n/l10n services. Currently, we have to parse and pass in the messages from MediaWiki to the WVUI component(s) that we're using. For this task, we have to go a step further and pass a function that parses a message; and we have to use the v-html Vue.js directive to use the result of the function, which is advised against.

In T273093#7066464, @bwang wrote:

@alexhollender Do you have a preference for the spacing when thumbnails are disabled, aka when the icon doesn't expand?

When thumbnails are enabled, we set the left padding to 24px to aligned with the search icon: https://jmp.sh/IipqpMN
But here's what the loader looks like with 24px when thumbnails are disabled: https://jmp.sh/xhGg2uq
Alternatively, we could set the left padding to 36px when thumbnails are disabled to align with the input: https://jmp.sh/bcD2UFw

@Jdrewniak awesome, looks great. @sgrabarczuk would you like to do one final inspection before we put the banners up?

@stjn thanks for clarifying. Perhaps worth checking with @Volker_E — do you have any sense of whether or not it was intentional to center captions in Minerva? I am fine with non-centered captions (as proposed here).

@Jdlrobson one final addition to the audit: WeChat (which according to this chart is quite popular: https://www.statista.com/statistics/258749/most-popular-global-mobile-messenger-apps/). Any ideas on that one?

@stjn thanks for filing this. While I think I understand your proposal it would be helpful if you could include screenshots (possibly with circles/arrows/annotations) to make it extra clear what your proposal is.

the current state of things for posterity: