Noting that this thankfully isn't an issue on Android/Chrome

Just did a quick QA on the beta cluster. The change looks good:

In T248198#5988184, @Jdlrobson wrote:

Is this by design @Jdrewniak and @alexhollender ? I remember we had a lot of different combinations for this menu (AMC, AMC+download icon, normal, normal+download icon).

I tried to work out the CSS and have proposed some additional mobile styles here: https://en.wikipedia.org/wiki/Template_talk:2019%E2%80%9320_coronavirus_pandemic_data/styles.css#Cleaning_up_the_table_for_mobile_web

@Jdlrobson @Volker_E looking at this table on mobile web (iOS/Safari & Chrome, Android/Chrome) and wanted to suggest the following possible changes:

@Jdrewniak @Volker_E documenting the conversation we had in slack regarding adding a max-width to the outer page container as well, resulting in something like:

1920px browser width (sidebar closed)	1920px browser width (sidebar open)

In T219654#5977593, @Jdlrobson wrote:

@alexhollender trust this is okay as an interim step?

@Jdrewniak nice. There are still a few minor issues with the prototype, though I'm not sure if it makes sense to continue refining it, or just wait until we start building the thing for real? Would additional work here further benefit the production effort?

In T245190#5950149, @Jdlrobson wrote:

Two questions:

1. Is it viable for the logo asset to always be a fixed width square e.g. 40x40 and make use of whitespace inside the SVG or do we need to make width and height configurable?

I've updated the guidelines to reflect our decision that the icon area will always be 50x50px

In T246170#5950156, @Jdlrobson wrote:

I've got a starting patch and have fleshed out the description. Should be enough for the estimation which should cover the back and forth between design and engineering.
@Volker_E @alexhollender it looks like we'll need to increase the header height of new Vector. This is how it looks using the existing header and guideline heights.

Prior to moving this todo we should add a mock be provided so the margins/paddings can be accounted for.

@Volker_E do you have thoughts on this? What is the current thinking around why we don't apply custom styling for blue links, as we do for OOUI elements?

@Jdlrobson moving this out of Designing/discussing as we're not currently working on this. It seems, given this task, T235193, T226125, and T225535, that we may want to make a mini-epic around notifications on mobile, though probably not something we'd work on anytime soon.

At this point it seems like this should be considered as part of the Desktop Improvements project. @spatton could you add the data you collected around the value of the Donate button, as well as the current hypothesis about why this button is important (i.e. some people see the banner but prefer to click on the link), to this task? Also, what's your current thinking about logged-in users, is the Donate button important in that case as well?

Based on T226125#5604323 I'm moving this to blocked.

@Volker_E as we've discussed a more comprehensive review of font-sizes in mobile front end is needed, however this issue seems worth addressing in the meantime.

@ovasileva @Jdlrobson possibly could be addressed during DIP

@ovasileva @Jdrewniak @Jdlrobson I wanted to call our attention to how the article bar will look with a fixed content width. Below is German Wikipedia with the max-width at 960px. Thankfully there seems to be decent responsive support here, so even if folks have gadgets that result in extra tabs we should be fine. Eventually this situation will be resolved by us moving the search bar out of the toolbar. For now I think we should be mindful of this and keep an eye on it.

@Jdrewniak I've added details to the description here. Your prototype — https://wikipedia-vue-protoype.netlify.com/p3.html#/en/wiki/Hawaiian_Islands — is getting pretty close. A few things to point out that need to be updated (please reference the task description for details):

@Demian my apologies for forgetting to address your comments about the TOC — I meant to respond to that.

@Volker_E regarding animation, @Jdrewniak has come up with a great solution as you can see in the prototype — above 1360px screen width there is an animation, and below 1360px screen width there is no animation. This avoids the weird content reflowing issue associated with animation.

In T245190#5945782, @Volker_E wrote:

@alexhollender To get back to the Farsi example above, what would be the harmonized version then?

@Volker_E @ovasileva @Demian apologies for the phab spam and potential confusion. I have renamed and rescoped this task to specifically be about whether or not the sidebar should be sticky/fixed. The epic is now T247032.

In T245734#5936114, @Demian wrote:

Demo for sidebar scrolling using above patch: http://patchdemo.wmflabs.org/wikis/197e628bad08d9ea6ab286c6db366fe7/w/index.php/Main_Page

In T245734#5924840, @Demian wrote:

In T245734#5923010, @ovasileva wrote:

Agreed that scrollbars would not be okay.

Scrollbars are commonly used for sidebars and better than having to scroll the whole article when looking for a specific link on the scrollbar. If done well it's subtle and convenient. Please see Discord for a great example, or try the userstyle for WikiZero I've posted in the first comment to see the difference with or without scrollbar on a page with long sidebar content and try WikiWand to see scrolling is usable even without a scrollbar, though it's up to the user to recognize there's more...

In T245734#5924285, @Volker_E wrote:

I feel that we're not fully clear on the added value behind making the sidebar sticky. IMO we need to be clear on why the top items in the crowded sidebar get more importance (sticky) than links further down.

Tl;dr: the reason for not seeing added value is that the site-navigation sidebar has in itself very little added value. Editors and readers are often asking for solutions to hide it.
What has added value is the TOC, the best solution would be to show the TOC on the sidebar and optionally - when the user clicks the navmenu icon -, show the site navigation (current sidebar) instead of the TOC. This is a requested feature on the DIP page, it seems this is the last time that can be effectively discussed.

Three concerns on sticky:

• We'd be breaking common user interaction patterns of one-column scrolling, like ctrl+page-up/cmd+arrow-up

FYI Ctrl+PGUP in Chrome and most browsers will go to the tab to the left. Do you mean simple PGUP?

• The scrolling behaviour won't be broken. As long as the main (content) column is focused, PGUP will have its effect there.
• If the user clicks inside the sidebar, it's expected that PGUP will affect that area.
• If the user clicks a link inside the sidebar (assuming site navigation is in the sidebar) a new page will load and focus returns to the main content.
• If the user clicks a link inside the sidebar TOC, then it is unexpected (not breaking tho) that focus (and PGUP scrolling) stays there, but easily fixed with an onclick handler that returns focus to main.

• Making language list easier discoverable comes later in the project and it's probably among most used links section (data?), which is harder to scroll into (you'd need to move your link into smaller area)

The DIP page suggests me with numerous examples that the language list is moved to a drop-down in the top-right corner. Is this concerning the special case of no-js runtime?

• Sidebar links are a weird per-project collection and it's not clear at all that most important ones are on top, where fixed sidebar would be preferable

• If projects put their important links not to the top, that's their own problem. Why would they?
• The bottom links are obscured in Vector, anyway. By the time a reader scrolls down, their focus is on reading the content, not the sidebar. These "concerns" also apply to the status quo.

Additionally on a technical level, scrollbar appearance is on many GUI systems still underwhelming and customizations are hard and non-standard. Means, they might look terrible in small space additionally to all user-experience concerns.

• Take a look at Discord. https://www.discordapp.com
• The userstyle for WikiZero I linked above.

Don't even consider defaulting to the default (system) scroll-bar, that would be terrible indeed. That's why I posted a ready-made solution above.

In T245734#5924285, @Volker_E wrote:

I feel that we're not fully clear on the added value behind making the sidebar sticky. IMO we need to be clear on why the top items in the crowded sidebar get more importance (sticky) than links further down. Three concerns on sticky:

• We'd be breaking common user interaction patterns of one-column scrolling, like ctrl+page-up/cmd+arrow-up
• Making language list easier discoverable comes later in the project and it's probably among most used links section (data?), which is harder to scroll into (you'd need to move your link into smaller area)
• Sidebar links are a weird per-project collection and it's not clear at all that most important ones are on top, where fixed sidebar would be preferable

Additionally on a technical level, scrollbar appearance is on many GUI systems still underwhelming and customizations are hard and non-standard. Means, they might look terrible in small space additionally to all user-experience concerns.

In T245734#5923661, @alexhollender wrote:

In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

In cases where the contents of the sidebar are taller than the screen having a scrollbar on the fixed sidebar is a natural result. Dependent upon user settings the scrollbar will only become visible when someone is interacting with the sidebar element. If we want to we can style the scrollbar (supported by all webkit browsers) to make it more subtle (https://webkit.org/blog/363/styling-scrollbars/) Example from Gmail:

Check out the prototype if you haven't already: http://localhost:5000/Lil_Yachty

In T245734#5923010, @ovasileva wrote:

In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

Agreed that scrollbars would not be okay. Would there be a way of avoiding this? Maybe have some max length of the sidebar and if it goes above that it's no longer sticky?

In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

In T245190#5939475, @Volker_E wrote:

@alexhollender One more question for shared understanding:
For “2. wordmark — this is dependent on whether or not there is a tagline”
I assumed from our conversation, that we're setting on a strict height and the width is flexible as… T245190#5934226
What made you fix the width, could you probably share a descriptive layout image of context with the flexible/fix ranges?

In T242381#5938913, @Jdlrobson wrote:

To get it to say "Vector preferences" we will need to revisit the solution. The solution was simple as it could be generalized. You'll note the same skin preferences section displays when Monobook is selected.

@ovasileva just wanted to clarify if this represents the implementation, or the generating of the actual svgs/assets that will be used? If it's the former then I think it could be reassigned to Volker or Jon. If it's the latter we're all set.

@Jdlrobson assigning this to you for now. I will wait until our implementation plan is a bit more finalized and then will start working on T244486 and T246430

@Volker_E @Jdlrobson here are a bunch of SVGs to start with:

Sorry for the late feedback.

per a discussion I had with @Jdlrobson I'm unassigning this from myself.

Met with @Jdlrobson and @Volker_E today to review further. I've put together some examples of how we could render the logos for Wikipedia and other projects using 2-3 separate images (depending on the project), and not much CSS (thanks flexbox): https://di-logo-sandbox.firebaseapp.com/

1. logo
2. wordmark
3. (optional) tagline

2cents: for these discussions I think it's helpful to show the icons in context

In T246420#5925864, @ovasileva wrote:

@alexhollender - would it be better if we keep this on the design board for now?

Alright, a bit more information after a broader investigation today.

In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

@ovasileva what do you think about a more minimal styling for the button? Even without the underline it seems relatively noticeable if you're looking at the sidebar.

@Andreg-p would it be possible for you to show me a few other examples of equation previews? I would like to make some layout suggestions and having other examples would be helpful.

@Volker_E @Jdlrobson @ovasileva here's where I'm at so far:

I think we should anchor on the use case where the search returns results because that's more common. I think it looks better with the proposed icon rather than no icon.

Spoke with @Volker_E — I think it's fine to swap the current contents icon for the bullet list one, e.g.

I've been in communication with @Erdinc_Ciftci_WMDE — the proposed design for mobile looks good. Removing this from our board.

Bringing what's shown in the mobile preview closer to the wikitext sounds like a good idea to me in general. I'm fine with displaying the broken-ish icons, assuming that it will lead to things getting fixed so they work better on mobile eventually.

In T243281#5899062, @Volker_E wrote:

@alexhollender Thanks for clarification. For users who reconcile or mistakenly clicked the button, the way back is preferences then, correct?
Do we have a time limitation as for how long to show this *very prominent* UI element, that pushes down possible other popular user action elements in the sidebar, for example “Recent Changes”?

@thiemowmde how we handle links seems to be a bit inconsistent (or difficult to define), see T190549 for context. Perhaps the best way to handle this is to follow what would happen if a link within the reference itself (not the reference preview) were clicked? In this case that would mean it would open in the same tab.

In T243281#5893821, @Volker_E wrote:

Lastly, as soon as you switch, does the button's label change “Switch to new look” or would that be a toggle button? Or does the design change and the button disappears completely?

@Jdlrobson @matmarex it's unclear to me what is the before & after screens to compare here?

From a certain perspective this is a bug, because any click outside of the filter menu is intended to close the menu (that's part of the mechanics of how our menus work). However as @Etonkovidova pointed out (T231053#5874095), in this case the bug is somewhat convenient.

In T237019#5879619, @Volker_E wrote:

From my perspective, 8px would be a good compromise here.
Captured the navigation proposal in patch below.

Hey @Peteole this is a super cool exploration. I'm curious about your thinking — specifically what challenges you are aiming to solve with this? I can make some guesses but always best to hear directly.

@olga small things that came up during estimation:

• is the styling of the button intentional? Sort've...it should stand out from the other links in the list but doesn't have to be a full on button (e.g. we could just add some spacing around it and make it bold)
• do we prefer people go to settings then have to switch it manually, versus just switching the setting automatically via javascript? Yes
• can we make the button text shorter / less negative? Possibly, let's try to come up with alternatives

My apologies for the long delay on reviewing this.