🙌🙌🙌

Nicely done!

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault jgirault@wikimedia.org wrote:

Hi everybody,

Following up on last week's email, the team has made significant improvements to the *enhanced search box*:

• We developed a JavaScript-only version of the language picker, on

top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker. - Shorter language code is displayed, allowing more space for text within the search input. - Triggers the native selector on mobile devices. - The search box looks better overall.

Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.

*It's merged into master, and deployed on beta!*

*Check it out:* http://www.wikipedia.beta.wmflabs.org/

*Deployment to production * (Phab ticket for reference: Epic T125472 https://phabricator.wikimedia.org/T125472)

The patch has been submitted for Thursday's Evening SWAT (Thu 00:00–01:00 UTC, Wed 16:00–17:00 PST) https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A010 .

Last chance to enjoy the "good old search" https://www.wikipedia.org/ !

Chris https://www.mediawiki.org/wiki/User:CKoerner_(WMF) and Deborah https://www.mediawiki.org/wiki/User:DTankersley_(WMF) will answer any question or concern related to this deployment

*Some screenshots:*

*Modern browsers:*

Chrome, JS: http://i.imgur.com/Jb8JVbd.png Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language picker because no JS)

*IE browsers:*

IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker because old IE) IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker because old IE) IE10, JS: http://i.imgur.com/OY6MVwJ.png IE11, JS: http://i.imgur.com/nQUk8fg.png *Note: the CSS for the suggestions needs some attention, currently seeing weird padding.*

*Mobile browsers:*

iOS, JS: http://i.imgur.com/7mbCKu6.png iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression). If you don't have JS, you will have to submit the form in order to get results.

*Next A/B test: Use language detection to re-arrange the primary links to suit the user better*

*Coming soon!* The team has also made significant progress, stay tuned!

For the Wikipedia.org portal team,

Julien.

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Hi,

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!

Deb

-- Deb Tankersley Product Manager, Discovery Wikimedia Foundation

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault jgirault@wikimedia.org wrote:

Hi everybody,

Following up on last week's email, the team has made significant improvements to the *enhanced search box*:

• We developed a JavaScript-only version of the language picker, on

top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker. - Shorter language code is displayed, allowing more space for text within the search input. - Triggers the native selector on mobile devices. - The search box looks better overall.

Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.

*It's merged into master, and deployed on beta!*

*Check it out:* http://www.wikipedia.beta.wmflabs.org/

*Deployment to production * (Phab ticket for reference: Epic T125472 https://phabricator.wikimedia.org/T125472)

The patch has been submitted for Thursday's Evening SWAT (Thu 00:00–01:00 UTC, Wed 16:00–17:00 PST) https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A010 .

Last chance to enjoy the "good old search" https://www.wikipedia.org/ !

Chris https://www.mediawiki.org/wiki/User:CKoerner_(WMF) and Deborah https://www.mediawiki.org/wiki/User:DTankersley_(WMF) will answer any question or concern related to this deployment

*Some screenshots:*

*Modern browsers:*

Chrome, JS: http://i.imgur.com/Jb8JVbd.png Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language picker because no JS)

*IE browsers:*

IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker because old IE) IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker because old IE) IE10, JS: http://i.imgur.com/OY6MVwJ.png IE11, JS: http://i.imgur.com/nQUk8fg.png *Note: the CSS for the suggestions needs some attention, currently seeing weird padding.*

*Mobile browsers:*

iOS, JS: http://i.imgur.com/7mbCKu6.png iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression). If you don't have JS, you will have to submit the form in order to get results.

*Next A/B test: Use language detection to re-arrange the primary links to suit the user better*

*Coming soon!* The team has also made significant progress, stay tuned!

For the Wikipedia.org portal team,

Julien.

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Hi again,

Based on the fact that I'll be out of the office most of the day today for a Product Team offsite, let's delay the release to, at the earliest, to Thursday evening (west coast time).

Cheers,

Deb

On Mar 9, 2016, at 9:01 AM, Deborah Tankersley dtankersley@wikimedia.org wrote:

Hi,

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!

Deb

-- Deb Tankersley Product Manager, Discovery Wikimedia Foundation

...

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault jgirault@wikimedia.org wrote: Hi everybody,

Following up on last week's email, the team has made significant improvements to the enhanced search box: We developed a JavaScript-only version of the language picker, on top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker. Shorter language code is displayed, allowing more space for text within the search input. Triggers the native selector on mobile devices. The search box looks better overall. Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.

It's merged into master, and deployed on beta!

Check it out: http://www.wikipedia.beta.wmflabs.org/

Deployment to production (Phab ticket for reference: Epic T125472)

The patch has been submitted for Thursday's Evening SWAT (Thu 00:00–01:00 UTC, Wed 16:00–17:00 PST).

Last chance to enjoy the "good old search" https://www.wikipedia.org/ !

Chris and Deborah will answer any question or concern related to this deployment

Some screenshots:

Modern browsers:

Chrome, JS: http://i.imgur.com/Jb8JVbd.png Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language picker because no JS)

IE browsers:

IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker because old IE) IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker because old IE) IE10, JS: http://i.imgur.com/OY6MVwJ.png IE11, JS: http://i.imgur.com/nQUk8fg.png Note: the CSS for the suggestions needs some attention, currently seeing weird padding.

Mobile browsers:

iOS, JS: http://i.imgur.com/7mbCKu6.png iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression). If you don't have JS, you will have to submit the form in order to get results.

Next A/B test: Use language detection to re-arrange the primary links to suit the user better

Coming soon! The team has also made significant progress, stay tuned!

For the Wikipedia.org portal team,

Julien.

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

There do seem to be some caching problems, so I used this URL: http://www.wikipedia.beta.wmflabs.org/?dsadsadasff

On Safari 9.0.3 in a private browsing window, I also have no type-ahead. It works in a regular window, an in Chrome (48.0.2564.116 (64-bit)) in both a regular and private window.

I have two other problems:

1) I'm not getting the bookshelf images. I get weird partial circles, in both Chrome and Safari. Screen grab below.

[image: Inline image 1]

2) The element to select a language extends over into the "search" button. If I click the center of the button, I get the language selection menu. If I click a corner, I search. See screenshot of selected element below. This is in both Safari and Chrome.

[image: Inline image 2] HTH, —Trey

On Wed, Mar 9, 2016 at 12:01 PM, Deborah Tankersley < dtankersley@wikimedia.org> wrote:

Hi,

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!

Deb

-- Deb Tankersley Product Manager, Discovery Wikimedia Foundation

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault jgirault@wikimedia.org wrote:

...

Hi everybody,

Following up on last week's email, the team has made significant improvements to the *enhanced search box*:

• We developed a JavaScript-only version of the language picker, on

top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker. - Shorter language code is displayed, allowing more space for text within the search input. - Triggers the native selector on mobile devices. - The search box looks better overall.

Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.

*It's merged into master, and deployed on beta!*

*Check it out:* http://www.wikipedia.beta.wmflabs.org/

*Deployment to production * (Phab ticket for reference: Epic T125472 https://phabricator.wikimedia.org/T125472)

The patch has been submitted for Thursday's Evening SWAT (Thu 00:00–01:00 UTC, Wed 16:00–17:00 PST) https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A010 .

Last chance to enjoy the "good old search" https://www.wikipedia.org/ !

Chris https://www.mediawiki.org/wiki/User:CKoerner_(WMF) and Deborah https://www.mediawiki.org/wiki/User:DTankersley_(WMF) will answer any question or concern related to this deployment

*Some screenshots:*

*Modern browsers:*

Chrome, JS: http://i.imgur.com/Jb8JVbd.png Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language picker because no JS)

*IE browsers:*

IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker because old IE) IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker because old IE) IE10, JS: http://i.imgur.com/OY6MVwJ.png IE11, JS: http://i.imgur.com/nQUk8fg.png *Note: the CSS for the suggestions needs some attention, currently seeing weird padding.*

*Mobile browsers:*

iOS, JS: http://i.imgur.com/7mbCKu6.png iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression). If you don't have JS, you will have to submit the form in order to get results.

*Next A/B test: Use language detection to re-arrange the primary links to suit the user better*

*Coming soon!* The team has also made significant progress, stay tuned!

For the Wikipedia.org portal team,

Julien.

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

0. My work Mac has a retina display and I see it too. Probably looks the same on recent smart phones, too. The "blurry" bits are old low resolution images, that's all. But next to crisp fonts, they do look blurry. ... 4. I also have worried slightly about fair use images showing up in the type ahead. I think the problem is that fair use images should (perhaps) not be used in the type-ahead drop-down. Take the image on the page https://en.wikipedia.org/wiki/Black_and_Blue —it's not licensed under creative commons; it's copyright by The Rolling Stones, or their record label, or someone like that. It can accompany the article under "fair use" for purposes of identification, education, and/or criticism. Whether it can accompany the title in the type-ahead is unclear. The explanation for on the image's page ( https://en.wikipedia.org/wiki/File:Blackblue.jpg ) says:

The image is used for identification in the context of critical commentary

of the work for which it serves as cover art. It makes a significant contribution to the user's understanding of the article, which could not practically be conveyed by words alone. The image is placed in the infobox at the top of the article discussing the work, to show the primary visual image associated with the work, and to help the user quickly identify the work and know they have found what they are looking for. Use for this purpose does not compete with the purposes of the original artwork, namely the artist's providing graphic design services to music concerns and in turn marketing music to the public.

It seems reasonable that including it in the type-ahead also contributes to the user finding and identifying what they are looking for—and I know there was a lawsuit about Google showing thumbnails in image search that went in favor of Google—but "reasonable" is not really a legal category, and I am not a lawyer.

—Trey

Trey Jones Software Engineer, Discovery Wikimedia Foundation

On Wed, Mar 9, 2016 at 4:18 PM, Jan Drewniak jdrewniak@wikimedia.org wrote:

Hi Moushira,

0. I can't speak to the blurriness of the text, does it look blurry in

that section only?

1. Thanks for pointing out the Russian text bug

https://dl.dropboxusercontent.com/u/19492365/screenshots/Screen%20Shot%202016-03-09%20at%208.53.29%20PM.png. This issue is occurs because the cyrylic font on ubuntu seems to be slightly wider than on other operating systems. We hope our up-coming A/B test https://people.wikimedia.org/~jdrewniak/localizedtoplinks/index.html#language-detection-a will make this a none-issue though :) 2. We have plans to disable the 'find a language' feature since it has been broken for quite a while and nobody seemed to notice, but we will replace it with something better eventually. 3. We have localization on our road-map, but there is a lot of work to be done server/infrastructure-wise to make that a possibility. 4. I'm not sure I understand the concern with using fair-use images (to be fair I don't know the slightest thing about what is and isn't fair-use). For the search-suggestions we use the thumbnail image associated with the wikipedia article, just like on mobile web https://en.m.wikipedia.org, if the thumbnail is violating copyright, then it's probably as issue with the article content, no?

Thanks, Jan

On Wed, Mar 9, 2016 at 7:15 PM, Moushira Elamrawy <melamrawy@wikimedia.org

...

wrote:

...

For c

On Wed, Mar 9, 2016 at 7:39 PM, Moushira Elamrawy < melamrawy@wikimedia.org> wrote:

...

Hello, I have a few comments:

0. Both Wikipedia text on the top and sphere are a bit blurred, no?
1. The Russian text is overlaying the Wikipedia sphere is kind of

distracting. I know this is how it currently looks like on stable, but possibley with the minor magnification, it just doesn't seem right. :)

For clarity, this is for Firefox 44.0 on Ubuntu! :)

Thanks! M

...

2. What is the <find a language> field supposed to do? Right now it on

beta and stable it directs to incubator, even for existing languages. 3. When I hover with my mouse over the languages, around the Wikipedia sphere, I get the name and description in native language again, while it might be more interesting to have this displayed in the language of my browser. Same applies to the list of languages below. 4. The dropdown menu shows fair-use images while searching in English, but I assume this will be figured out soon.

Cheers, Moushira

On Wed, Mar 9, 2016 at 7:01 PM, Deborah Tankersley < dtankersley@wikimedia.org> wrote:

...

Hi,

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!

Deb

-- Deb Tankersley Product Manager, Discovery Wikimedia Foundation

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault jgirault@wikimedia.org wrote:

...

Hi everybody,

Following up on last week's email, the team has made significant improvements to the *enhanced search box*:

• We developed a JavaScript-only version of the language picker,

on top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker. - Shorter language code is displayed, allowing more space for text within the search input. - Triggers the native selector on mobile devices. - The search box looks better overall.

Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.

*It's merged into master, and deployed on beta!*

*Check it out:* http://www.wikipedia.beta.wmflabs.org/

*Deployment to production * (Phab ticket for reference: Epic T125472 https://phabricator.wikimedia.org/T125472)

The patch has been submitted for Thursday's Evening SWAT (Thu 00:00–01:00 UTC, Wed 16:00–17:00 PST) https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A010 .

Last chance to enjoy the "good old search" https://www.wikipedia.org/ !

Chris https://www.mediawiki.org/wiki/User:CKoerner_(WMF) and Deborah https://www.mediawiki.org/wiki/User:DTankersley_(WMF) will answer any question or concern related to this deployment

*Some screenshots:*

*Modern browsers:*

Chrome, JS: http://i.imgur.com/Jb8JVbd.png Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language picker because no JS)

*IE browsers:*

IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker because old IE) IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker because old IE) IE10, JS: http://i.imgur.com/OY6MVwJ.png IE11, JS: http://i.imgur.com/nQUk8fg.png *Note: the CSS for the suggestions needs some attention, currently seeing weird padding.*

*Mobile browsers:*

iOS, JS: http://i.imgur.com/7mbCKu6.png iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression). If you don't have JS, you will have to submit the form in order to get results.

*Next A/B test: Use language detection to re-arrange the primary links to suit the user better*

*Coming soon!* The team has also made significant progress, stay tuned!

For the Wikipedia.org portal team,

Julien.

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

First of all, as some of you may have noticed, the beta page was displaying the old search box around 9am PST. We had similar issues before (https://phabricator.wikimedia.org/T126061) and apparently the problem keeps coming back. We'll try to improve this process. In the meantime, please keep keeping us informed when this happens so that we can re-deploy as soon as possible.

- *Moushira*: I think most of your concerns are not related to this improvement (the new search box). If you are seeing these issues on https://www.wikipedia.org/ too, I suggest you create Phabricator tickets or follow-up with Chris and Deb directly.

- *Deborah*: Thanks for finding this bug. I created https://phabricator.wikimedia.org/T129408

- *Trey*: Thanks for finding this bug, I created https://phabricator.wikimedia.org/T129409

- *Moushira/Trey*: This sounds like quite an important, legal concern.

I can't say much about this (I am not a lawyer either...), but I can say that:

- these images are returned by the search API, - this search API and these thumbnails are currently used in several places, like the mobile webpage (https://en.m.wikipedia.org/wiki/Main_Page) and the mobile apps (iOS, Android).

Deborah, Dan, Chris: Please help figuring this out.

Per Deborah's request, I *moved the deployment* to Fri 3/11 - 00:00–01:00 UTC - Thu 16:00–17:00 PST https://wikitech.wikimedia.org/wiki/Deployments#Friday.2C.C2.A0March.C2.A011 .

Thanks for your engagement. It's very helpful.

On Wed, Mar 9, 2016 at 1:53 PM, Trey Jones tjones@wikimedia.org wrote:

0. My work Mac has a retina display and I see it too. Probably looks the

same on recent smart phones, too. The "blurry" bits are old low resolution images, that's all. But next to crisp fonts, they do look blurry. ... 4. I also have worried slightly about fair use images showing up in the type ahead. I think the problem is that fair use images should (perhaps) not be used in the type-ahead drop-down. Take the image on the page https://en.wikipedia.org/wiki/Black_and_Blue —it's not licensed under creative commons; it's copyright by The Rolling Stones, or their record label, or someone like that. It can accompany the article under "fair use" for purposes of identification, education, and/or criticism. Whether it can accompany the title in the type-ahead is unclear. The explanation for on the image's page ( https://en.wikipedia.org/wiki/File:Blackblue.jpg ) says:

The image is used for identification in the context of critical commentary

...

of the work for which it serves as cover art. It makes a significant contribution to the user's understanding of the article, which could not practically be conveyed by words alone. The image is placed in the infobox at the top of the article discussing the work, to show the primary visual image associated with the work, and to help the user quickly identify the work and know they have found what they are looking for. Use for this purpose does not compete with the purposes of the original artwork, namely the artist's providing graphic design services to music concerns and in turn marketing music to the public.

It seems reasonable that including it in the type-ahead also contributes to the user finding and identifying what they are looking for—and I know there was a lawsuit about Google showing thumbnails in image search that went in favor of Google—but "reasonable" is not really a legal category, and I am not a lawyer.

—Trey

Trey Jones Software Engineer, Discovery Wikimedia Foundation

On Wed, Mar 9, 2016 at 4:18 PM, Jan Drewniak jdrewniak@wikimedia.org wrote:

...

Hi Moushira,

0. I can't speak to the blurriness of the text, does it look blurry in

that section only?

1. Thanks for pointing out the Russian text bug

https://dl.dropboxusercontent.com/u/19492365/screenshots/Screen%20Shot%202016-03-09%20at%208.53.29%20PM.png. This issue is occurs because the cyrylic font on ubuntu seems to be slightly wider than on other operating systems. We hope our up-coming A/B test https://people.wikimedia.org/~jdrewniak/localizedtoplinks/index.html#language-detection-a will make this a none-issue though :) 2. We have plans to disable the 'find a language' feature since it has been broken for quite a while and nobody seemed to notice, but we will replace it with something better eventually. 3. We have localization on our road-map, but there is a lot of work to be done server/infrastructure-wise to make that a possibility. 4. I'm not sure I understand the concern with using fair-use images (to be fair I don't know the slightest thing about what is and isn't fair-use). For the search-suggestions we use the thumbnail image associated with the wikipedia article, just like on mobile web https://en.m.wikipedia.org, if the thumbnail is violating copyright, then it's probably as issue with the article content, no?

Thanks, Jan

On Wed, Mar 9, 2016 at 7:15 PM, Moushira Elamrawy < melamrawy@wikimedia.org> wrote:

...

For c

On Wed, Mar 9, 2016 at 7:39 PM, Moushira Elamrawy < melamrawy@wikimedia.org> wrote:

...

Hello, I have a few comments:

0. Both Wikipedia text on the top and sphere are a bit blurred, no?
1. The Russian text is overlaying the Wikipedia sphere is kind of

distracting. I know this is how it currently looks like on stable, but possibley with the minor magnification, it just doesn't seem right. :)

For clarity, this is for Firefox 44.0 on Ubuntu! :)

Thanks! M

...

2. What is the <find a language> field supposed to do? Right now it

on beta and stable it directs to incubator, even for existing languages. 3. When I hover with my mouse over the languages, around the Wikipedia sphere, I get the name and description in native language again, while it might be more interesting to have this displayed in the language of my browser. Same applies to the list of languages below. 4. The dropdown menu shows fair-use images while searching in English, but I assume this will be figured out soon.

Cheers, Moushira

On Wed, Mar 9, 2016 at 7:01 PM, Deborah Tankersley < dtankersley@wikimedia.org> wrote:

...

Hi,

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!

Deb

-- Deb Tankersley Product Manager, Discovery Wikimedia Foundation

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault <jgirault@wikimedia.org

...

wrote:

...

Hi everybody,

Following up on last week's email, the team has made significant improvements to the *enhanced search box*:

• We developed a JavaScript-only version of the language picker,

on top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker. - Shorter language code is displayed, allowing more space for text within the search input. - Triggers the native selector on mobile devices. - The search box looks better overall.

Users who disable JavaScript, or are using old IE versions, get the native selector already presented in last email.

*It's merged into master, and deployed on beta!*

*Check it out:* http://www.wikipedia.beta.wmflabs.org/

*Deployment to production * (Phab ticket for reference: Epic T125472 https://phabricator.wikimedia.org/T125472)

The patch has been submitted for Thursday's Evening SWAT (Thu 00:00–01:00 UTC, Wed 16:00–17:00 PST) https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A010 .

Last chance to enjoy the "good old search" https://www.wikipedia.org/ !

Chris https://www.mediawiki.org/wiki/User:CKoerner_(WMF) and Deborah https://www.mediawiki.org/wiki/User:DTankersley_(WMF) will answer any question or concern related to this deployment

*Some screenshots:*

*Modern browsers:*

Chrome, JS: http://i.imgur.com/Jb8JVbd.png Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language picker because no JS)

*IE browsers:*

IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker because old IE) IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker because old IE) IE10, JS: http://i.imgur.com/OY6MVwJ.png IE11, JS: http://i.imgur.com/nQUk8fg.png *Note: the CSS for the suggestions needs some attention, currently seeing weird padding.*

*Mobile browsers:*

iOS, JS: http://i.imgur.com/7mbCKu6.png iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker because no JS)

Note that JS is required for the typeahead/suggestions feature (this is already the case with the current page, no regression). If you don't have JS, you will have to submit the form in order to get results.

*Next A/B test: Use language detection to re-arrange the primary links to suit the user better*

*Coming soon!* The team has also made significant progress, stay tuned!

For the Wikipedia.org portal team,

Julien.

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

FYI all, deploying on beta just got even weirder. They are running `git submodule update --rebase` regularly on the mediawiki-config repository, and what happens is that git could not automatically rebase the submodule without conflicts.

Because of this, it stopped in the middle of rebasing, and that intermediate state got deployed to production within the last hour. As a consequence, some of you may have seen, and tested, the webpage in the state it was... 2 weeks ago :-/

Sorry for the inconvenience. It makes me think of a suggestion I got from Deborah, not so long ago, of introducing a version number in the page, so that two people can make sure they are talking about the same version of the page.

On Wed, Mar 9, 2016 at 2:26 PM, Moushira Elamrawy melamrawy@wikimedia.org wrote:

Thanks Jan and Trey for the answers. Refreshing now, both images and text on the seem crisp. The text overlay is still an issue on Firefox. All seems good on Chromium. The fair-use images issues I mentioned are tackled here https://phabricator.wikimedia.org/T124225, it is a policy issue. Will be looking forward to the localization stuff.

Thanks again! M

On Wed, Mar 9, 2016 at 11:53 PM, Trey Jones tjones@wikimedia.org wrote:

...

0. My work Mac has a retina display and I see it too. Probably looks the

same on recent smart phones, too. The "blurry" bits are old low resolution images, that's all. But next to crisp fonts, they do look blurry. ... 4. I also have worried slightly about fair use images showing up in the type ahead. I think the problem is that fair use images should (perhaps) not be used in the type-ahead drop-down. Take the image on the page https://en.wikipedia.org/wiki/Black_and_Blue —it's not licensed under creative commons; it's copyright by The Rolling Stones, or their record label, or someone like that. It can accompany the article under "fair use" for purposes of identification, education, and/or criticism. Whether it can accompany the title in the type-ahead is unclear. The explanation for on the image's page ( https://en.wikipedia.org/wiki/File:Blackblue.jpg ) says:

The image is used for identification in the context of critical

...

commentary of the work for which it serves as cover art. It makes a significant contribution to the user's understanding of the article, which could not practically be conveyed by words alone. The image is placed in the infobox at the top of the article discussing the work, to show the primary visual image associated with the work, and to help the user quickly identify the work and know they have found what they are looking for. Use for this purpose does not compete with the purposes of the original artwork, namely the artist's providing graphic design services to music concerns and in turn marketing music to the public.

It seems reasonable that including it in the type-ahead also contributes to the user finding and identifying what they are looking for—and I know there was a lawsuit about Google showing thumbnails in image search that went in favor of Google—but "reasonable" is not really a legal category, and I am not a lawyer.

—Trey

Trey Jones Software Engineer, Discovery Wikimedia Foundation

On Wed, Mar 9, 2016 at 4:18 PM, Jan Drewniak jdrewniak@wikimedia.org wrote:

...

Hi Moushira,

0. I can't speak to the blurriness of the text, does it look blurry in

that section only?

1. Thanks for pointing out the Russian text bug

https://dl.dropboxusercontent.com/u/19492365/screenshots/Screen%20Shot%202016-03-09%20at%208.53.29%20PM.png. This issue is occurs because the cyrylic font on ubuntu seems to be slightly wider than on other operating systems. We hope our up-coming A/B test https://people.wikimedia.org/~jdrewniak/localizedtoplinks/index.html#language-detection-a will make this a none-issue though :) 2. We have plans to disable the 'find a language' feature since it has been broken for quite a while and nobody seemed to notice, but we will replace it with something better eventually. 3. We have localization on our road-map, but there is a lot of work to be done server/infrastructure-wise to make that a possibility. 4. I'm not sure I understand the concern with using fair-use images (to be fair I don't know the slightest thing about what is and isn't fair-use). For the search-suggestions we use the thumbnail image associated with the wikipedia article, just like on mobile web https://en.m.wikipedia.org, if the thumbnail is violating copyright, then it's probably as issue with the article content, no?

Thanks, Jan

On Wed, Mar 9, 2016 at 7:15 PM, Moushira Elamrawy < melamrawy@wikimedia.org> wrote:

...

For c

On Wed, Mar 9, 2016 at 7:39 PM, Moushira Elamrawy < melamrawy@wikimedia.org> wrote:

...

Hello, I have a few comments:

0. Both Wikipedia text on the top and sphere are a bit blurred, no?
1. The Russian text is overlaying the Wikipedia sphere is kind of

distracting. I know this is how it currently looks like on stable, but possibley with the minor magnification, it just doesn't seem right. :)

For clarity, this is for Firefox 44.0 on Ubuntu! :)

Thanks! M

...

2. What is the <find a language> field supposed to do? Right now it

on beta and stable it directs to incubator, even for existing languages. 3. When I hover with my mouse over the languages, around the Wikipedia sphere, I get the name and description in native language again, while it might be more interesting to have this displayed in the language of my browser. Same applies to the list of languages below. 4. The dropdown menu shows fair-use images while searching in English, but I assume this will be figured out soon.

Cheers, Moushira

On Wed, Mar 9, 2016 at 7:01 PM, Deborah Tankersley < dtankersley@wikimedia.org> wrote:

...

Hi,

Things look really good! I haven't been able to fully test everything I want to, as of this morning, but looks very nice! :)

I did find something interesting on Safari (on a mac) and using a private browser (so I didn't have to clear my cache) the type-ahead didn't seem to work for me (with the meta data display). Can someone verify that they see the same thing?

Thanks - I'll test more later on today!

Deb

-- Deb Tankersley Product Manager, Discovery Wikimedia Foundation

On Tue, Mar 8, 2016 at 9:20 PM, Julien Girault < jgirault@wikimedia.org> wrote:

> Hi everybody, > > Following up on last week's email, the team has made significant > improvements to the *enhanced search box*: > > - We developed a JavaScript-only version of the language picker, > on top of the previous patch, so that users who have JS enabled (93% of our > traffic) get a nicer version of the language picker. > - Shorter language code is displayed, allowing more space for > text within the search input. > - Triggers the native selector on mobile devices. > - The search box looks better overall. > > Users who disable JavaScript, or are using old IE versions, get the > native selector already presented in last email. > > > *It's merged into master, and deployed on beta!* > > *Check it out:* http://www.wikipedia.beta.wmflabs.org/ > > > *Deployment to production * > (Phab ticket for reference: Epic T125472 > https://phabricator.wikimedia.org/T125472) > > The patch has been submitted for Thursday's Evening SWAT (Thu > 00:00–01:00 UTC, Wed 16:00–17:00 PST) > https://wikitech.wikimedia.org/wiki/Deployments#Thursday.2C.C2.A0March.C2.A010 > . > > Last chance to enjoy the "good old search" > https://www.wikipedia.org/ ! > > > Chris https://www.mediawiki.org/wiki/User:CKoerner_(WMF) and > Deborah https://www.mediawiki.org/wiki/User:DTankersley_(WMF) will > answer any question or concern related to this deployment > > > > > *Some screenshots:* > > *Modern browsers:* > > > > Chrome, JS: http://i.imgur.com/Jb8JVbd.png > Chrome, no-JS: http://i.imgur.com/JcBfz2h.png (basic language > picker because no JS) > > *IE browsers:* > > IE8, JS: http://i.imgur.com/Nef2rn6.png (basic language picker > because old IE) > IE9, JS: http://i.imgur.com/o1yrhcA.png (basic language picker > because old IE) > IE10, JS: http://i.imgur.com/OY6MVwJ.png > IE11, JS: http://i.imgur.com/nQUk8fg.png > *Note: the CSS for the suggestions needs some attention, currently > seeing weird padding.* > > *Mobile browsers:* > > > > iOS, JS: http://i.imgur.com/7mbCKu6.png > iOS, no-JS: http://i.imgur.com/F2rQpEE.png (basic language picker > because no JS) > > Note that JS is required for the typeahead/suggestions feature (this > is already the case with the current page, no regression). > If you don't have JS, you will have to submit the form in order to > get results. > > > *Next A/B test: Use language detection to re-arrange the primary > links to suit the user better* > > *Coming soon!* > The team has also made significant progress, stay tuned! > > > > For the Wikipedia.org portal team, > > Julien. > > _______________________________________________ > discovery mailing list > discovery@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/discovery > >

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

On 9 March 2016 at 14:26, Moushira Elamrawy melamrawy@wikimedia.org wrote:

The fair-use images issues I mentioned are tackled here https://phabricator.wikimedia.org/T124225, it is a policy issue.

It's complicated, of course. www.wikipedia.org is not the English Wikipedia, so it is debatable whether the policy applies there, and both sides of that argument have legitimate points. It's also important to note that the non-free content exceptions https://en.wikipedia.org/wiki/Wikipedia:Non-free_content#Exemptions now explicitly includes a note that non-free images are allowed in search results without an accompanying fair use rationale being needed on the file page of the image in question, so we're actually covered there even if the policy does apply.

Regardless, the fix for the broader PageImages issue which does unquestionably affect the English Wikipedia and other projects (as documented in T124225 https://phabricator.wikimedia.org/T124225) will be rolled out tomorrow. All PageImages API consumers, such as the portal, but also mobile web, mobile apps, and VisualEditor, will start using the new images automatically. It may take a little bit of time for that to happen due to caching, and so on.

Thanks, Dan

re-deployed to beta. Beta should (i hope) now update itself to the master branch of the portals repository in gerrit every 5 minutes now.

On Wed, Mar 9, 2016 at 6:16 PM, Julien Girault jgirault@wikimedia.org wrote:

Giving up on Beta for today, we need to make some changes on the beta cluster.

In the meantime:

• If you want to see/test latest master (all code currently already

merged) : https://people.wikimedia.org/~jgirault/search-box-master-0309/

• If you want to see/test latest master + T129409 patch

https://phabricator.wikimedia.org/T129409 : https://people.wikimedia.org/~jgirault/search-box-T129409-0309/

On Wed, Mar 9, 2016 at 4:46 PM, Dan Garry dgarry@wikimedia.org wrote:

...

On 9 March 2016 at 14:26, Moushira Elamrawy melamrawy@wikimedia.org wrote:

...

The fair-use images issues I mentioned are tackled here https://phabricator.wikimedia.org/T124225, it is a policy issue.

It's complicated, of course. www.wikipedia.org is not the English Wikipedia, so it is debatable whether the policy applies there, and both sides of that argument have legitimate points. It's also important to note that the non-free content exceptions https://en.wikipedia.org/wiki/Wikipedia:Non-free_content#Exemptions now explicitly includes a note that non-free images are allowed in search results without an accompanying fair use rationale being needed on the file page of the image in question, so we're actually covered there even if the policy does apply.

Regardless, the fix for the broader PageImages issue which does unquestionably affect the English Wikipedia and other projects (as documented in T124225 https://phabricator.wikimedia.org/T124225) will be rolled out tomorrow. All PageImages API consumers, such as the portal, but also mobile web, mobile apps, and VisualEditor, will start using the new images automatically. It may take a little bit of time for that to happen due to caching, and so on.

Thanks, Dan

-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

---

discovery mailing list discovery@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery