When you evaluate features using engagement metrics, there are only two possibilities. If the metric is high, users love the feature. If the metric is low, users don't know the feature exists, and more alerts or "unread" badges must be added to help them learn.
They had better metrics than just number of API requests
If the metric is high, users are spending too much time on it. Also, it is responsible for every single frustration that users have with your product.
If the metric is low, the feature can be safely removed (see: Windows Start menu).
Numbers are helpful, but sometimes they can be misinterpreted to mask the why.
That turned out really well...
Whoever is responsible for putting the touch start screen on Windows Server is responsible for 90% of my frustrations...
No-no-no. Stop right there. "Engagement metrics" are the worst kind of metrics. Engagement means next to nothing. It just means that a user interacted with something. Was it good? Was it bad? Was it intentional? Was it by mistake? "Engagement metrics" answer none of that.
And yet... They are the easiest metrics to collect and too many companies use them as if they were meaningful.
https://m.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Re...
Not sure what it says about them that they're mentioning worthless numbers instead of the way more useful data they got back during this survey.
I sincerely regret the use of that statement "people seem to like it" in my post. I've now removed it as I worry this confuses my message so thank you for pointing it out. This really trivializes all the work that went into A/B testing this and how we measured success. I really recommend a read of https://www.mediawiki.org/wiki/Page_Previews#Success_Metrics... Side note: the volume of traffic was also wrong by several magnitudes... actually 0.5 million)
My main motivation when writing this post was to share how small changes require magnitudes of effort not to express the merits of the feature. As a developer who works with product owners a lot and often get asked how I can build things quicker (I'm sure many can relate). I wanted to provide something useful to other developers that easy looking things are not actually easy to build, so thanks for flagging.
With regards to the user script, yeh that's been around for some time and was the seed for this idea. It's just taken a long time to get that from such a small audience to a mainstream one. It doesn't downplay it in my opinion, just shows how far we've come.
Thanks for reading.
Something that just happens accidentally is a bug, no matter how useful it might be if it were not happening accidentally.
When you go from reading the Atlantic, The Economist, The Washington Post... any content site... then begin to read a Wikipedia entry everything you know about reading an article no longer applies. You are now forced to change what you do.
This is just the most basic no no in web design - unplanned interactions, forcing a user to interact, forcing a user to actually think about the interface.
The developers have just forced every person who wants to consume content on Wikipedia to do it differently than on every other content site.
And there are literally countless millions of people who will have no idea how to disable it, who use computers every day but have no idea how to change something.
Just an incredible UX failure.
It soon became known as Navigation Popups[2], and is still available today.
The main documentation for Page Previews mentions Navigation Popups.[3]
[1]: https://en.wikipedia.org/wiki/User:Lupin/popups.js
[2]: https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_pop...
I also have to wonder how much bandwidth Wikipedia is going to end up using to display unneeded previews.
But that's exactly what these preview popups are for! A bit heavier than the plain URL, but much more useful and friendlier.
(EDIT: I see there's a bug in that it displays the preview even if you don't stop the mouse there. Still, this can be lighter than requiring people to click through to the full articles, considering the preview can tell you what you need or that the link is not relevant for you, and slows you going down the rabbit hole to more links. Maybe it should be located at the bottom of the screen like the plain URL popup though?)
This is interesting. There's an external arrow for external links, so I'm still good with this use case for inspecting links; for internal links I've found myself hovering where I previously clicked (and loaded) an additional page at least 50% of the time. Where I'm OK with a quick paragraph description and can then decide if the linked paragraph requires / inspires a deeper read, about 50% of the time.
I think this is a net reduction of bandwidth for my personal use-case. Wide A/B testing would reveal more, obviously.
According to https://stats.wikimedia.org/EN/Sitemap.htm , English Wikipedia gets 88K views per minute.
This response is pure sophistry.
this is a desktop feature. in general, mobile traffic > desktop traffic.
we’d need wikipedia’s browsing statistics be sure, since some sites see different ratios than others. What if 1:8 wikipedia visits are on desktop? That would make the 5K/minute much more significant.
I, too, think either that number is wrong or this wasn't a feature available to all users.
I also agree that using this metric as affirmation the feature is liked is dangerous; count me among the many here inadvertantly contributing without enjoying the feature.
in my case every single time was by accident whilst moving the mouse around, off of other text I was trying to read.
frankly, its bloody annoying
it covered the text i was reading
the search for yet another "disable" setting begins....
Your inability to figure out how to disable it was already counted as success!
> the rates of disabling the feature are negligibly low — a strong indicator that people find it useful.
https://medium.com/freely-sharing-the-sum-of-all-knowledge/w...
I think the best place for these controls are usually on the feature itself. I don't want to have to search in some independent preferences UI every I want to see if something can be tweaked, but it makes sense to offer it there as well.
— bad UX designers in 2070
Uhm, no. It just means that people are hovering over links with their mouse. It does not imply any opinion about the previews.
> The original idea was conceived four years ago
When I was active at Wikipedia/Wikibooks 12 years ago, there was a user script floating around that did the same thing, except I'm not sure if it included an image. (Mediawiki allows a user to define custom CSS and JS that get embedded in every page of their user session.)
I don't mean to express dislike or downplay the hard work that went into this feature, just to add some context.