@mpopov regarding the event logging for this test, I'd like to go over some details of how information about these thumbnails can be collected.
I have an idea that I think integrates nicely with the existing SearchSatisfaction schema.

A demo of this feature is available for testing by adding the following line to a users common.js file on english wikipedia:
importScript( 'User:JDrewniak_(WMF)/searchThumbs.js' );

@Nemo_bis In this context, thumbnails serve just as a visual cue for the search result, and don't have any intrinsic value on their own. This is why on mobile search (typeahead) and on other search engines, clicking on the image acts just like clicking on the text. The thumbnail + search result are perceived as one unit, so it would be confusing if the text led you to one page but the image to another.

@mxn can you take a look at updating the wikiversity logo on the portals from meta?

Link colors and title text are no problem(1 & 2), but it looks like footer link text (3 & 4) is being overridden for english wikipedia and maybe others by this text:
https://en.wikipedia.org/wiki/MediaWiki:Search-interwiki-custom
That page hasn't been updated since 2012, and since the feature has changed considerably since then, it might be a good idea to remove this override.

I've looked at this from the event logging side to see if we're accidentally logging clicks that come from the community developed sidebars, but given that the CSS selectors we use to trigger the events are different than those used in the other sidebars (and testing this myself to be sure), this doesn't seem to be the case either.

the no esclick events is certainly strange. I've checked the kafka logs, and I can see esclick events at least making it into there. Maybe they're not valid? could be an invalid param or something. I'm attaching a video and event output. We should check the logstash error logs to see if any errors are being generated.

@Gilles that API wizardry is impressive. I was unaware that API calls could be combined like that, but since they can, it seems like a good idea to me. The thinking behind making these calls separately though, was to avoid sending down data that the user might never see (in the case that they hover over 'languages' but not 'categories' for example). The cost to this approach though, like you mention, is having to wait for each response separately.

Also, a preview of this feature is available on labs:
http://sistersearch.wmflabs.org/w/index.php?search=~rainbow&title=Special:Search

@Amire80 thank you for your insight. Like you mention this issue was raised in the gerrit patch
https://gerrit.wikimedia.org/r/#/c/356169/16/i18n/en.json
but postponed because the AB test we're running is only on english wikipedia (and we don't plan to release until we have l10n coverage). However your right that "local languages" is confusing and should be changed. I was unsure whether "suggested" or "other" languages is preferable, because we're only showing results in "suggested" languages ( basically whatever is exposed via mw.uls.getFrequentLanguageList() ). From your comment it seems "other languages" is preferable, so I'll change it to that.

@mpopov those events sound good to me. In regards to the wprov we'll be using a modified version of the serp:N format (as discussed on IRC) with just _es appended to the end.

Also, the reason this was breaking no wikisource specifically, and not wikipedia,
was that someone somewhere added a CSS class that adds extra margins to all the <ul>'s on the site.

I think this was a CSS issue due to me using display:inline-block to vertically position the top of the sidebar with the top of the search results. Reducing the margin from 10% to 8% seems to fix it.

The monitor might be very high res like 4K, or it might be a resolution in between 1 and 2x, in which case it would still receive the 1x image. In any case, replacing the icons with SVG's T129634 would fix this

Regarding the UI concerns

Based on the screenshot in figure 1, it seems that only one interface was being tested, without any of the suggested tweaks of https://lists.wikimedia.org/pipermail/discovery/2017-March/001464.html. Correct?

The grunt-sketch npm module caught my eye once, is that what you have in mind with this task?

Multiline text

Initially I preferred the 'full-bleed' thumbnails, but now I see how the rounded corners (and necessary margin/padding) add finesse to the design.

Just to reiterate my thoughts on the 1rem=10px idea.

Recently the WMF has discontinued JS support for IE8, meaning we only serve JS to ES5 compatible browsers. Opera 10.6 doesn't have full ES5 support, so if we serve the non-js version to Opera 10.6, that might fix this issue (off the top of my head I don't know how we'd target ES5 browsers only... right now we only target IE specifically as non-js...)

The icons we originally made to represent generic 'content types' such as quotations, definitions, textbooks etc. This was meant to help readers who might not know what the sister projects are. However, it turns out that it's hard to make icons that clearly represent these concepts (like a book icon vs textbook icon vs definition icon, they're all book-ish in the end) and an icon alone without any other visual distinctions doesn't convey this meaning. So I think moving away from these generic icons and using the project icons is the right move here. Then at least then, like @Gryllida says, users will be able to distinguish the project names easier.

@Dzahn we monitor the performance of the wikipedia portal carefully here:
https://grafana.wikimedia.org/dashboard/db/webpagetest-portals?from=1458474417000&to=1490010417359

Why focus on pixel output values when using rems? Personally, when using ems & rems I tend to set measurements like 0.75rem, 0.25rem etc, because those are much easier to calculate relative to 1rem.

A recent patch by @JGirault https://gerrit.wikimedia.org/r/#/c/342296/ changes the highlight color on the portal typeahead to light blue instead of grey. The patch would change the portal typeahead from this to this:

With the changes to the server config and the full list of URLs in the urls-to-purge.txt, I think we can mark this issue as done.

This issue should be resolved now.

With this patch https://gerrit.wikimedia.org/r/#/c/339631/ (deployed March 14)
the sister project icons for RTL have been improved.

I think there's a lot more CSS that can be removed here.
There's a nifty chrome devtools feature that highlights what it thinks is unused CSS. These results need manual review because it picks up things like the 'no-js' and typeahead styles as unused, but I think it provides a good starting point.

@MaxSem @demon
That's the idea :)
https://gerrit.wikimedia.org/r/#/c/341379/1/gulpfile.js

This seems like a useful feature, especially on mobile where language features are often buried in some OS settings.

This seems related to the work WMDE is insterested in doing related to the advanced search UI
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Advanced_Search_Workshop

@JGirault the above patch should fix that

oh weird I guess https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existing.js is also cached...
A different fake URL like https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existingX.js does produce a 404 like intended.

before the patch the following answers are expected:

• https://www.wikipedia.org/ -> 200 OK
• https://www.wikipedia.org/portal/wikipedia.org/assets/img/sprite-icons.png -> 200 OK 815
• https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existing.js -> 301 Moved Permanently
• https://www.wikipedia.org/portalx-> 301 Moved Permanently
  
  after the patch:
• https://www.wikipedia.org/ -> 200 OK
• https://www.wikipedia.org/portal/wikipedia.org/assets/img/sprite-icons.png -> 200 OK 815
• https://www.wikipedia.org/portal/wikipedia.org/assets/js/index-non-existing.js -> 404 Not Found
• https://www.wikipedia.org/portalx-> 301 Moved Permanently

Patch https://gerrit.wikimedia.org/r/#/c/339631/ is by no means a complete RTL solution, but rather addresses the most basic readability issues.

Since the page has been localized and text-direction has been set on the HTML element (although at the moment l10n is slightly broken as we work out some caching issues), I've started work on some minor changes that should improve RTL readability

• correcting the direction of the search suggestions
• placement of the icons in the sister project links.

Given all the rationale above, it seems best to leave the cache-busting filenames as is, therefore marking this task declined.

@greg there was no updates to the portal today. This brief error today must have happened because the portal was rolled back yesterday, but the HTML page remained cached on our end for 24h (we didn't purge that url). In general the updates are done during SWAT, and should be visible in SAL (not sure why it says the last deploy was last week though).

I think the term chrome can be useful if we define it (Pau's option #1).

yup fixed

A static prototype of the 'explore similar' feature is available at this URL
https://people.wikimedia.org/~jdrewniak/SERP-sidebar/index.htm

We want to share the sistersearch demo (http://sistersearch.wmflabs.org/) on a few mailing lists to get feedback, so I wouldn't break it just yet. Once we run the A/B test on a few production wikis we won't need the labs instance, so then it should be fine to break then :)

The labs instance with relforge indices has been setup and is available at: http://sistersearch.wmflabs.org/

@Volker_E good point. Given how the related articles stack on mobile, I think they can be certainly be considered the same UI pattern (although they serve a different function )

I added a column for mobile front-end, because the usage of this UI pattern is very prominent on mobile. To be honest, when creating the portal typeahead, we based the style on mobilefrontend because that was the primary usage of this pattern (that we could find). I knew visualEditor was capable of this pattern, but wasn't sure where it was being used.

As @hashar mentioned in his comment:

@Reedy I don't know much about the server setup of the Portals repo, maybe @MaxSem can shed some light on why the symlink is necessary in the first place? (or knows who might know?)

@MarcoAurelio this looks like an error compiling lwip - the node image processor & optimizer we use to optimize the images (this thing has been a pain with Node 6 - and it cause CI to run for 15 min :/ ). The error your getting seems to be around node-gyp and the version of Python. Node-gyp documentation says to install it globally:
https://github.com/nodejs/node-gyp#installation
so first npm install --global --production windows-build-tools
and then you need to install Python 2.7 on your system, it looks like you have version 3.5.2 (I don't know much about Python version management, so I hope managing multiple python versions on one system isn't a nightmare).
After that, npm install -g node-gyp should work, as well as the local npm install

@abian I agree that this is a weird setup. But just removing the symlinks would break the page in production, and cleaning up the apache config has the potential of breaking a lot of things. I don't know enough about apache to say if the recursion can be limited in any way, @Gehel do you?

wow that looks great!

@Volker_E The patch mentioned above changes the language icon color to the M82 blue (#3366cc).
https://gerrit.wikimedia.org/r/#/c/320761/1/prod/wikipedia.org/assets/img/sprite-bookshelf_icons%25402x.png,unified