Page MenuHomePhabricator

WikimediaShopLink should insert the shop link in PHP, not JavaScript
Closed, ResolvedPublic

Description

Visual elements that appear out-of-sequence prolong the interval of time that users perceive as latency. It's also very distracting to have things blink in and out of existence when you've already started reading the article.

Let's add the shop link via PHP, instead. This could be done by removing the JavaScript module and replacing it with the following hook handler:

$wgHooks['SkinBuildSidebar'][] = function ( $skin, &$sidebar ) {

		global $wgWikimediaShopLinkTarget, $wgWikimediaShopEnableLink;

		if ( !$wgWikimediaShopEnableLink ) {
			return;
		}

		$sidebar['navigation'][] = array(
			'text'  => $skin->msg( 'wikimediashoplink-linktext' ),
			'href'  => $wgWikimediaShopLinkTarget,
			'title' => $skin->msg( 'wikimediashoplink-link-tooltip' ),
			'id'    => 'n-shoplink',
		);

};

The only thing missing from this implementation is the use of GeoIP information to control the display of the link, but using GeoIP on every page load is problematic for a host of reasons anyway. In my opinion, we could live without it; it doesn't seem like the end of the world if the shop says "Sorry! the Wikimedia Shop is not available in your country", and tracking such visits might help us identify countries to which service could be profitable expanded.


Version: unspecified
Severity: normal

Details

Reference
bz57939

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:14 AM
bzimport set Reference to bz57939.

Change 98885 had a related patch set uploaded by Ori.livneh:
Unconditionally insert shop link via PHP

https://gerrit.wikimedia.org/r/98885

The GeoIP script is loaded on every page load anyway (and is not likely to change because of CentralNotice and other targeted extensions. The only reason I have it checking in this extension is in case someone installed it on a non WM wiki.

That said I'm not horribly against this as long as fundraising (copied in now) is ok with it and with the added load from international. The store itself is available for other countries (and so people would not get an unavailable message) but is less reliable (much more expensive shipping, which we sometimes subsidize etc) there.

That said, while I highly prefer a PHP insert over a js insert in general I don't agree that this is currently a huge issue. On English Wikipedia (and on most other languages where this extension would be activated in anywhere close to the near future) there is quite a bit of other javascript insertions in the interface (both the sidebar and up top) which are significantly more obvious then the shop link.

(In reply to comment #2)

On English Wikipedia (and on most other languages where this extension would
be activated in anywhere close to the near future) there is quite a bit of
other javascript insertions in the interface (both the sidebar and up top)
which are significantly more obvious then the shop link.

Fully agree; I didn't intend to single out the shop link. One at a time, though. :)

Thanks for the reply, James -- let's wait to hear from FR.

Hi Ori — thanks for bringing this up. For the time being, I believe the GeoIP is in the best interest of the shop and potentially international customers. We are working out ways to make international shipping more affordable and reliable, but until we do so, we think it's best to keep the shop's scope relatively limited.

This is related to other bugs I've looked into recently such as bug #37797. If we are going to be exposing the shop on a global level, we'll want to be able to support multiple languages, currencies, *and* have a shipping option that is sustainable. Our goal is to perfect the shop in English, then expand our reach.

We are looking into global shipping as the first step in this process, but the earliest we will move on this will be mid-2014.

I'm sorry I can't give much more detail at the moment, but please feel free to ask questions if there is anything I can clarify.

(In reply to comment #0)

Visual elements that appear out-of-sequence prolong the interval of time that
users perceive as latency. It's also very distracting to have things blink in
and out of existence when you've already started reading the article.

Let's add the shop link via PHP, instead. This could be done by removing the
JavaScript module and replacing it with the following hook handler:

$wgHooks['SkinBuildSidebar'][] = function ( $skin, &$sidebar ) {
    global $wgWikimediaShopLinkTarget, $wgWikimediaShopEnableLink;

    if ( !$wgWikimediaShopEnableLink ) {
        return;
    }

    $sidebar['navigation'][] = array(
        'text'  => $skin->msg( 'wikimediashoplink-linktext' ),
        'href'  => $wgWikimediaShopLinkTarget,
        'title' => $skin->msg( 'wikimediashoplink-link-tooltip' ),
        'id'    => 'n-shoplink',
    );
};

The only thing missing from this implementation is the use of GeoIP
information
to control the display of the link, but using GeoIP on every page load is
problematic for a host of reasons anyway. In my opinion, we could live
without
it; it doesn't seem like the end of the world if the shop says "Sorry! the
Wikimedia Shop is not available in your country", and tracking such visits
might help us identify countries to which service could be profitable
expanded.

GeoIP being used in other extensions already doesn't say much about whether it /should/ be used for this purpose, as the same could be argued for any of its other uses :) In fact, the current usage of the GeoIP lookups in general is problematic for other reasons already and we have plans of changing it in the future (see #57126, as filled by Ori).

If the shop has restrictions on where from it can be used, then this certainly shouldn't affect each and every page load on every project of ours. Having every Wikipedia reader's browser compute in Javascript whether the shop link should be displayed or not (and modify the DOM for a large percentage of our user base) sounds, frankly, crazy to me. Unless you have evidence to support that a significant percentage of readers shop from the site *and* you have a lot of false positives of users entering the site and saying "bummer, this is expensive", merging this sounds extremely obvious to me.

Having a link is fine, but the extra computation because of application logic is not. If you think this functionality is useful for the shop, then this logic should be pushed into the shop site itself; the extra pointless click will only affect a tiny minority of users who I'm sure wouldn't mind seeing the "sorry it's so expensive to your place" notice that much.

On a more general note, the site currently is full of "small harmless snippets" like that that overall make the performance horrendous; it's essentially death by a thousand cuts, and we finally have someone who's actually going around and providing patches to fix all of these cuts, so I'm inclined to just let them make those calls :-)

Change 98885 merged by jenkins-bot:
Unconditionally insert shop link via PHP

https://gerrit.wikimedia.org/r/98885

(In reply to comment #4)

Hi Ori — thanks for bringing this up. For the time being, I believe the GeoIP
is in the best interest of the shop and potentially international customers.
We are working out ways to make international shipping more affordable and
reliable, but until we do so, we think it's best to keep the shop's scope
relatively limited.

The shop link is still enabled exclusively on the English Wikipedia, so it is still fairly targeted, inasmuch as Americans and Canadians make up a substantial portion of its traffic. If it is actively harmful to display the shop link to English Wikipedia users in other countries, we can remove the link altogether, but we can't continue injecting it late into the page based on GeoIP data, because it degrades the user experience of substantially more users than the number that ever make it to the shop.

(In reply to comment #9)

The shop link is still enabled exclusively on the English Wikipedia, so it is
still fairly targeted, inasmuch as Americans and Canadians make up a
substantial portion of its traffic.

Namely, about 46 %: http://stats.wikimedia.org/wikimedia/squids/SquidReportPageViewsPerLanguageBreakdown.htm.
Rather than the 54 % of unreachable users, I'd care about the sidebar real estate "stolen" to the 99.9999 % users (estimate based on comscore stats and number of shipped items) who don't use the shop. Is the PHP link shown to unregistered users too? If yes I'll file a bug, seems the next obvious step.

(In reply to comment #10)

(In reply to comment #9)

The shop link is still enabled exclusively on the English Wikipedia, so it is
still fairly targeted, inasmuch as Americans and Canadians make up a
substantial portion of its traffic.

Namely, about 46 %:
<http://stats.wikimedia.org/wikimedia/squids/
SquidReportPageViewsPerLanguageBreakdown.htm>.
Rather than the 54 % of unreachable users, I'd care about the sidebar real
estate "stolen" to the 99.9999 % users (estimate based on comscore stats and
number of shipped items) who don't use the shop. Is the PHP link shown to
unregistered users too? If yes I'll file a bug, seems the next obvious step.

Yes, it is, they were always the main target of the link in fact. I think it is completely reasonable there and is a relatively unobtrusive way for people to find it (especially since there is no other real public link to the shop).

In the end it would be up to the Caitlin and the fundraising team since it isn't my role anymore but personally I'd say if you were going to remove it for anonymous users I'd just remove it completely. However if that is a goal I think it would be something that should get consensus on wiki, rather then bugzilla.

(In reply to comment #11)

In the end it would be up to the Caitlin and the fundraising team since it
isn't my role anymore but personally I'd say if you were going to remove it
for anonymous users I'd just remove it completely. However if that is a goal I
think it would be something that should get consensus on wiki, rather then
bugzilla.

Was there (on-wiki) consensus to add the link to the sidebar?

(In reply to comment #11)

Yes, it is, they were always the main target of the link in fact.

Ah, ok. I had understood the opposite, that editors were the main target of the shop. My bad. I agree on-wiki discussion first would be best then.

(In reply to comment #12)

(In reply to comment #11)

In the end it would be up to the Caitlin and the fundraising team since it
isn't my role anymore but personally I'd say if you were going to remove it
for anonymous users I'd just remove it completely. However if that is a goal I
think it would be something that should get consensus on wiki, rather then
bugzilla.

Was there (on-wiki) consensus to add the link to the sidebar?

There was not, I did it on my own after speaking with others (both volunteer and staff) and agreeing with the unanimous (unscientific) consensus that it was more of a fundraising type link that was reasonable to put up on my own. For some reason my memory says one of them may have been you... but I don't have my logs from back then (new computer type) and I am in no way positive so I can't be positive on that :).

(In reply to comment #14)

Was there (on-wiki) consensus to add the link to the sidebar?

There was not, I did it on my own after speaking with others (both volunteer
and staff) and agreeing with the unanimous (unscientific) consensus that it
was more of a fundraising type link that was reasonable to put up on my own.

The same unscientific consensus may be able to guide us going forward as well. :-)

It's not uncommon for sites to put a "shop" link in the footer. We could consider moving the shop link in a separate bug report.

(In reply to comment #15)

It's not uncommon for sites to put a "shop" link in the footer. We could
consider moving the shop link in a separate bug report.

Filed as bug 60466, if anyone's interested.