@JKatzWMF

So here are some ideas around exposing the change language feature.

• Sticky footer will be at least 44pt high
• We can use the same space for watch list and edit (needs a discussion)
• Because of edit and watchlist not being in the first paragraph, the reading experience for first paragraph improves drastically
• on bigger screens, the sticky footer can have talk page links too.

Option 1 - show language icon and language code

Option 1a - if the language code is longer

Option 1b - RTL for the same

Option 2 - show number of languages the article is available in

Desktop layout

hey @Nirzar these look great. A few comments, but I think I'd like to here our resident multi-language expert @Amire80's opinion as well.

1. I am not sure that notifying the user of the language they are currently is helpful enough to have featured so prominently. If I can understand the language, I know what language it is, right? If not, then it kind of doesn't matter. Regardless, if someone is really curious about what language they are reading in, they could presumably hit the language switcher and see which is selected. Same is true of number of languages--not important enough that it should always be present. One exception: if there are 0 other languages, it should be noticeably disabled. Just my opinion.

2. Actions:
   • What does it look like when I hit the language button?
   • does the footer every disappear? Does it only appear on scroll? Can you show what it looks like with the safari or chrome chrome underneath?

3. I like moving the edit pencil, but if we allow editing in-sections, then this could be problematic...

4. Super minor and very subjective, but there is something strange about the side-shading of the toolbar on desktop/tablet. The rest of the page bleeds into the blank gutters on either side, so this additional dimensionality seems kind of strange. To me, it visually implies that the gutters are part of the page, when, in reality I think we are trying to emphasize that they are ignorable. I think the footer behavior should be consistent with the header. What does it look like when it extends the entire width, but the actions are kept to article width?

I am not sure that notifying the user of the language they are currently is helpful enough to have featured so prominently. If I can understand the language, I know what language it is, right? If not, then it kind of doesn't matter. Regardless, if someone is really curious about what language they are reading in, they could presumably hit the language switcher and see which is selected. Same is true of number of languages--not important enough that it should always be present. One exception: if there are 0 other languages, it should be noticeably disabled. Just my opinion

Good question!
Here, the language code is not to notify the"current language" but to notify that "you can change language here"

This decision was informed from various things

• We did some user testing on iOS and we used only "EN" the language code without any icon as a way to change language and almost all the participants understood that it was the way to change the language
• This same pattern is used by all operating systems.

Mac -

Windows

Other websites where language is important

What does it look like when I hit the language button?

does the footer every disappear? Does it only appear on scroll? Can you show what it looks like with the safari or chrome chrome underneath?

the footer will be sticky all the time. except for when the keyboard is up it will go over the footer.
i am working on this http://nirzar.github.io/prototypes/mobile-web/index.html html prototype . ignore the ABC on the footer but you can open that in chrome and safari and see how the stickiness works in action and with the browser chrome.

I like moving the edit pencil, but if we allow editing in-sections, then this could be problematic...

we can still persist the edit actions on section levels. the top level edit in the first paragraph will be gone and it will be more prominent as a persistent action

Super minor and very subjective, but there is something strange about the side-shading of the toolbar on desktop/tablet. The rest of the page bleeds into the blank gutters on either side, so this additional dimensionality seems kind of strange. To me, it visually implies that the gutters are part of the page, when, in reality I think we are trying to emphasize that they are ignorable. I think the footer behavior should be consistent with the header. What does it look like when it extends the entire width, but the actions are kept to article width?

yes that could be a possible. the stickiness itself introduces "layering" in the interfaces. the shadows imply that something is above and something is below. i think you are finding it odd that the footer isn't end to end with shadow perhaps. as i said that could be a possible treatment. here i mocked it up

@Nirzar thanks, this addresses my concerns.

but to notify that "you can change language here"

I am surprised the button isn't enough, but trust user research!

I am surprised the button isn't enough, but trust user research!

yeah it might be. but icon + language = zero ambiguity

A few questions:

Option 1: Does use of a Latin language code make sense for users who don't know Latin scripts or are unfamiliar with Latin language codes? If I understood the earlier comments, the assertion may be yes. However, I wasn't sure how to reason about this if the base script is something else, like this:

Option 2 small form factor: I gather that will be done in a translated fashion. In other words, "languages" would get the usual i18n treatment, right? This seems to have a pretty clear implicit CTA.

Option 2 desktop form factor: Is this the current language in the current language's script? Or is it the current language as spelled out in the user's Wikimedia profile UI language preferences? Or is it some clever hybrid like user's Wikimedia profile UI language preference, falling back to current wikilang script if no UI language preference set? Would an arrow help to indicate this is going to do something? Or does the research suggest that this is sufficiently clear as initiating a language change given it's placed in the sticky footer?

I was wondering - if section editing will still be supported with this approach, would it make sense to apply the text label "Edit" on a section-by-section basis to make it distinct from the page-level edit pencil and to avoid clashing pencils?

Couple questions from today's meeting:

1. Where do users normally scroll on their devices? Will they accidentally tap the buttons on the bottom bar while trying to scroll down the article?
2. Do we want to ever hide the bar when scrolling one direction vs. another (similar to how some sites hide their fixed header when scrolling up)? I am personally not a fan of this whatsoever as I have noticed buggy behavior several times for sites that do this with fixed headers, but it's still a question that should be answered with solid reasoning/evidence.

Dupe of my comment from T123342:

position: fixed compatibility table http://caniuse.com/#search=position%3Afixed.

@aripstra, @pizzzacat: This is the task that outlines the design problem and the mocks for the Language Switcher feature.

@phuedx @Jhernandez I guess many of you are aware of the issues with position: fixed in older mobile browsers. To recap – position:fixed has (not only, but also from my own painful experience) had serious quirks on all kinds of mobile browsers. Everything below Android 3, Opera Mini and early iOS is affected with partly bad user experience issues. Further read: http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html and http://bradfrost.com/blog/mobile/fixed-position/

One thing to consider is to have the sticky footer hidden when the user is reading and scrolling downwards.

I believe sticky footers of any kind are considering highly annoying on mobile due to limited screen space. Less distraction is always better. Discovery is good, but I think the footer being sticky at all times would be too much in one's face.

One relatively approach is to have it appear on scroll-up and automatically slide away on scroll-down. See https://medium.com/@cramforce/why-amp-is-fast-7d2ff1f48597 for example. I think it could be improved (ideally it's visible on initial page load since having to scroll -back- up is not very intuitive imho). They do the same with the header as well, which might be a better location for these tools as that is naturally visible on page-load (highly discoverable), it naturally slides away and non-distracting when scrolling down. And it can come back in when the user scrolls up (but without having to scroll up all the way, see Medium's header as example).

Just an idea :)

@Krinkle yeah I was trying that out in the prototype that I have. medium is also A/B testing it because of the distraction the scroll up and scroll down it creates. It creates an abrupt experience on iOS safari because the toolbar of safari also hides when scrolled down and shows when scrolled up.

the desktop medium is really distracting, it keeps coming up and down rapidly if i am scrolling because it goes away *only* when you are scrolling. i guess they have 3 versions out there.

it's not coming up automatically now.

but it's something that we could try.

Is this done @Nirzar ?

@Jdlrobson This is stalled for long term because we are going with T128350