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.
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).
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.
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 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.
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...
— bad UX designers in 2070
They've managed to pull in pretty link previews, scientific notation and a grid layout, whilst building a highly nested markup structure?
The remarkable part? Wikipedia works great inside a text browser like elinks. It works great in a modern browser. Without sacrificing the interactivity people have grown to expect.
These are not hand-written pages, and their output is actually pretty clean compared to the crazy things I've tried to scrape. They have tons of APIs to access the backing data, and that should be your first stop.
Even if you insist on scraping, in your case you're just looking for a <td> whose immediately preceding <td> contains the text "Latest Release", and that's something any XPath-based scraper can give you straight out of the box[1].
A more resilient choice, if you still insist on (or have to use) scraping, is use the underlying template data - a regex is good enough in that case[2]
[1] e.g. http://html-agility-pack.net/ [2] https://en.wikipedia.org/w/index.php?title=Template:Latest_s...
I don't know how well they work, but the built-in parser should give you the text without markup. And since they switched to Parsoid [3] to support the Visual Editor, the've polished the wikitext formal specification so all instances of markup have a well-defined structure.
[1] https://www.mediawiki.org/wiki/API:Parsing_wikitext
Of course that is out of date and not in sync with the Wikipedia article. But there's public query services you can use to fetch stuff from there, you wouldn't need to parse html.
As for scraping... Parsing the hell that is wikitext is all you can do. Or apparently, pipe it through a text browser.
EDIT: This is unrelated, but after reading more of the comments, I legitimately can't believe how absolutely disrespectful and hateful so many of these comments are in here. I appreciate this site as a place where you can express your opinions, even if they aren't just placid support of whoever the OP is, but I really don't want to see this community dive further and further into the echo chamber of hate that it seems to be becoming.
The top-level comments are mostly positive, with one or two constructively critical ones. There are one or two sub-comments with strongly worded criticism of Wikipedia's markup (the code holding the text), but none that mention people or are in any way ad hominem.
That said, I intentionally try to read text online in the most charitable voice possible, so maybe my perception is very different from others.
Does its on-by-defaut nature disrupt the reading experience? Does summarizing linked content have problems? What about mobile (now approx. half of traffic and growing)?
I see a few comments using the word "hate" but for the most part the negative ones are just critical, with supporting points. I think a fundamental design pattern like this is worth some scrutiny alongside the support.
[1] Case in point: Safari implemented a feature similar to this a few years ago. It works generally across all sites, uses reserved gestures (3D Touch on mobile, 3-finger-tap on desktop) to gives users full control, and sidesteps the whole summarization problem by using more screen real estate to just show a bigger preview.
I think your criticism is a really good one though, especially if these link previews can be harmful towards accessibility/make basic interactions more difficult. Like I mentioned, I enabled a similar beta feature a while back that was a bit difficult to get used to, but I have grown to find indispensable. I think in the same argument, however, you can argue against any sort of hover effects on the web (drop down menus, hover animations, etc.) and to be fair, it would be hard for me to disagree with that point on many instances of that as well.
It's an appeal to emotion, too.
There are modding tools to make sure people aren't trolling or being too aggressive against other users but discourse shouldn't be censored due to offense.
What a great way of destroying the user experience with a beautifully over-engineered feature that is utterly crap while actually trying to use the underlying page.
Thanks an awful lot for breaking the ability to use the site as I am used to and making it impossible to scan with the curser as anchor for my eyes.
I'm not usually trying to police this kind of thing, but is there a way you could have phrased this without discrediting the work of a lot of people whose goal is to help others? I'm sure you'd get both a little bit hurt inside and defensive when someone in your team calls your code "utterly crap."
That said, I'm very sure they will be happy to hear about your feedback.
As for feedback, we've had 4 years of it and welcome more. Check out the FAQ and if you have something constructive to say, leave a note on the talk page.
Textselection was probably not intended as reading aid, so don't be disappointed if it is abused to actually, you know, select text to do something with it.
I agree, user scripts can be presumptuous and what not. I used to read with text selection the same way, and even reacted repulsed at advertisement hover pop-ups. But somehow I don't do it anymore, so I don't care as much.
Also personally I'm prone to going down a wikipedia rabbit hole and if last night was any indication, I think these popups will help stop that.
Sounds like you hit an edge case. Personally in that situation of a list of links I would just move the cursor outside the list. For me at least a minor change in behavior in some edge cases is worth what is otherwise a really awesome new feature.
But oddly enough, I found that Stackoverflow's "hot questions" or whatever thing is equally distracting.
I'm on a professional software developer network, and then I see a super interesting and legitimate question aaaaaannnddd... I'm in a rabbithole.
Don't know if it's helpful or not for you, but I found an extension that limits the maximum amount of tabs you can have open at a given moment, I set it to 3-4, it forces me to decide what link I do or do not want to click on. Makes me conscious of my unconscious browsing habits, might be useful for you too: https://addons.mozilla.org/en-US/firefox/addon/max-tabs-web-...
Just kidding, know how those rabbitholes are.
My work tree has somewhere over 500 items and my home one has several times that many, but it's easy to find things and keep them for later :)
Today I’m very happy with the Safari on MacOS as you’re can preview links. I like the Wikipedia implementation a lot, but as a Safari, I’m already used to have it everywhere.
[1] https://addons.mozilla.org/en-US/firefox/addon/budaneki/
https://en.m.wikipedia.org/wiki/Main_Page
for desktop these days.
I much prefer it to the standard version.
I really enjoy Wikipedia but the #1 item on my feature wishlist is "redirect me towards the non-mobile version of the site when I click a mobile link on the desktop".
The sidebar shows some major languages (German, Hindi etc), but not the ones I'm trying to learn. Clicking the "more" button then has the most ridiculous UI ever: "Suggested languages"! What is the point of suggesting Yiddish to me?!
I'd snip a screenshot, but I'm on mobile...
! Disable link preview popups on Wikipedia
en.wikipedia.org##.mwe-popups
For Wikipedia in different languages, just change the subdomain in the filter.
It's frustrating that every popular webpage nowadays is so full of distractions that I can't use the web without blocking a lot of it.
It's just wretched, backwards UI all around.
Guess what ? perfectly machine-readable data is called a DATABASE, and it works well in its scope.. and if you think that all of human knowledge, history, arts and culture are perfectly represented in a DATABASE, then congratulations, you are already more computer than human in your preconceptions.
There are several important layers to this onion.. lets call one "participation by non-specialists" .. a second "human factors, aesthetics and publishing arts" .. another is "imperfect intermediate products enable evolution" .. yet another is "taking rules before content" ..
Each topic might be an essay in itself.. Generally, I am happy to see XML essentially proposed as the answer to all human information challenges, because it takes less time to blink than to refute it, for me.
It's on a computer. It is a database. Are you also upset at people who smash the subtle beauty of music into unfeeling bits?
So if I print it out is it not a database anymore?
Were they happy enough with Safari’s 3D Touch preview which does more or less exactly this? (Only with a full screen preview so they don’t have to get into the messy business of summarizing pages.)
Bizarre reasoning.
Calling that reasoning "bizarre" is just being deliberately obtuse.
To wit, some browser vendors have already started recognizing this problem and solving it in a more general, mobile-compatible way.[1][2]
[1] https://appleinsider.com/articles/15/04/28/os-x-tips-preview...
[2] http://www.idownloadblog.com/2016/01/07/8-cool-ways-you-can-...
Mobile support is table stakes for major features these days.
[1] https://analytics.wikimedia.org/dashboards/browsers/#all-sit...
From the post: > Our initial version wasn’t good enough. Our community asked us not to go ahead with it. We answered by listening to them and making it better.
This was 2 years ago, and read the comments on the 39 votes it took to not release Hovercards - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28prop...
This meant that the silent majority didn't get these features for 2 years because some considered it 'intrusive'. A feature that you could objectively argue as being a useful utility.
If anything, I think this is an indictment of the complaints against Wikipedia from those observing it and ex-employees. While a benevolent dictatorship might be going too far, such a community process where only the loudest voice wins (over considering what is best for MOST of the users), is surely a broken process. I am surprised that product & design people work there at all in such an environment.
Well, yeah. Doing anything successfully at the scale of Wikipedia is worthy of some praise - and I say that as a US midwesterner - a culture not exactly known as the epitome of hubris. :)
You might claim I have Stockholm syndrome or something since I worked with the team that developed this feature, but the discussion you highlight did have valid feedback. The process for respecting community governance and developing consensus is more complicated than any one person could imagine. It is frustrating and imperfect. Folks at the foundation like myself are trying to do better in how we approach, work with, and deploy software changes. I agree too that it took a long time to develop, but that's not on any one single community's shoulders.
For instance, after doing due diligence we approached the English community again earlier this month and the result of that discussion was quite boring.
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(miscel...
For a technical example that lead to the time it took, the team looked at how we were generating the previews and saw an opportunity to improve them. Previously we tried to parse a bunch of wikitext with a list as long as my arm of exclusions and edge cases. Then the team figured out a way to return HTML summaries from the source article. Not just something useful for this feature and a huge improvement to how information is rendered (like math formulas). Refactoring the code and implementing a new API endpoint took time.
I hope this doesn't come across as too argumentative, I wanted to provide an alternative perspective from someone who works daily with product teams and communities within the Wikimedia movement.
One could argue that Wikipedia has a broader responsibility to the readers than to just the editors, and such a process gives the editors undue weight in the process. The vocal minority cannot always represent the needs of the silent majority and that role would lie with the product team, which in my understanding hasn't been the case at Wikipedia (I say this, and having interviewed and turned down a Wikipedia PM offer and having a few friends worked in Design at Wikipedia and leaving disillusioned).
In case you want to turn it on (or off), it's under Preferences->Appearance->Page previews. I think I'll probably leave it off personally. I like the previews that have already existed for a while in the mobile app, but on desktop not so sure.
I see these even when logged out.
Now you have a fully static Wikipedia copy, running wherever you want it to :)
It would be dumb no to take it as the complete dump is < 1Tb
I've been using it about a year now, and it has radically improved my experience reading Wikipedia.
As you point out, it's had a smoothly working link preview feature all along, as well as a beautiful, usable reading experience. Not flashy or over-designed, just clean and elegant. I get a little caught off-guard now when I see a Wikipedia page without it.
IMDB, CYC, Wolfram, and various RDF data sets, sample this space differently, and have different amounts of data and richness, probably as a result.
Wikipedia's is simple. And you can just disable it. Win/win.
Huh, that's not the behavior I see with Force Touch. Hyperlinks automatically come together, and there's some sort of heuristic for detecting word clusters such as names or places.
https://stackoverflow.com/a/48527419/4398037
Documentation: https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...
I've implemented such an ajax page preview and also a page inliner (for expanding page trees via ajax) about 10 years ago. It was major work, because you essentially send a stripped down page in xml, so it needed some architectural changes to separate the various page templates properly. In the end it needed 2 months work. phpwiki has a proper template design and its plugins cannot ever destroy a page layout or harm security.
mediawiki on the other side is horribly undesigned spaghetti code, with no proper templating and plugin integration, so it needed a few years more. It's like parsing html with regexp.
But like my mom's spaghetti, it's my favorite. :)
Think you can make it better? https://wikimediafoundation.org/wiki/Work_with_us
I work for the Wikimedia Foundation, but this subtle snark is my own, and may not reflect the views of the Foundation.
I'm not a fan of PHP as a language, but given the community has been working with PHP for 16 years, it would be odd to switch suddenly to an entirely new language and expect support and adoption.
The codebase is an absolute nightmare though, and a ground-up rebuild would be great. I wonder though about it having a similar affect to the Wordpress codebase: people who recognise the mess stay away completely, and people who don't contribute, leaving a contributor base who isn't really equipped (or extremely willing) to do a quality, maintainable rewrite.
I suspect any rewrite attempt would be doomed to end up being an unmaintainable behemoth.
A better approach would be to focus on secure integration tools and API entry-points, to make users less entrenched and solely dependent on the MW software.
It wouldn't surprise me if they could. Not to say that automation isn't great, and for this purpose probably ideal.
But, selecting a thumbnail for every Wikipedia article seems like something the community could easily have done.
https://grafana.wikimedia.org/dashboard/db/reading-web-page-...
The variety of metrics and the sheer volume of those is awesome to explore! (e.g. frequent peaks to 20M requests per minute)
You can see the specific dashboard for the Page Preview feature here (Last 6 hours):
https://grafana.wikimedia.org/dashboard/db/eventlogging-sche...
In any case, they had something 2 years ago but it was blocked by the community for not being good enough.
It's pretty cool :).
Apparently, it went into beta in 2014[1].
[1]: https://blog.wikimedia.org/2014/03/26/Hovercards-now-availab...
I couldn't care less for the huge image in the popup layer, scrollability and extra content would be much nicer.
https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_pop...
https://stackoverflow.com/a/48527419/4398037
Documentation: https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...
Indeed, as much as it took a fair bit of time, it seems the reasons behind it are all fairly logical; they actually thought carefully about the functionality and how it should work in various cases rather than just going with something that was 'good enough' to get it out quickly.
Not going to complain about that.
For the case when I came across a subject I knew not a lot about I would keep queuing them up, leading to an array of pages I'd read about a topic, leading to a deeper understanding about the topic/domain. With this feature, the probability that a page would be queued up would go down.
Sometimes going down the wiki rabbit-hole is the best form of time-sink.
How often do people use the feature to preview other pages? We set a threshold of 1000ms (one second) for a preview card to stay open before we counted it as viewed.
How often do people disable the feature? It can be disabled by clicking on a settings icon at the bottom of each preview. A high rate in disabling Page Previews would indicate that this is not a feature users want. A low rate indicates users like the feature and would continue using it."
https://www.mediawiki.org/wiki/Page_Previews/2017-18_A/B_Tes...
My experience was that suddenly something popped up over what I was trying to read so I was confused for a moment (hitting the first metric), but I did not notice the settings icon or expect I would be able to so easily turn these off (thus not hitting the second metric). After reading this I did turn it off.
I am definitely not at all a fan of this feature yet would be counted as positive by two different metrics.
https://chrome.google.com/webstore/detail/wikipreview/iioncm...
I hate our current web sometimes. The only skill it seems to know how to reward is writing code. 99% of the value of Wikipedia has nothing to do with code at all. Yet nobody gets rewarded for that.
I worry about the impact for accessibility-oriented users.