Live data from Hacker News

Why it took a long time to build the tiny link preview on Wikipedia

blog.wikimedia.org

201–210 of 255 posts

Re: Why it took a long time to build the tiny link preview on Wikipedia

#201

Earlier quoted context omitted.

> Even if you insist on scraping, in your case you're just looking for a whose immediately preceding contains the text "Latest Release", and that's something any XPath-based scraper can give you straight out of the box Sure, until it changes. Here it is in Jan 2016 when it was included in the opening paragraphs as the text "The latest version of OS X is ". https://en.wikipedia.org/w/index.php?title=MacOS&oldid=69769.…

I can't help feeling like there is a lot of tool blaming happening when the wrong tools were used in the first place. Wikipedia is pretty easy to scrape general blocks of text (I'm the author of an IRC bot which did link previewing, inc Wikipedia) but if you need specific, machine readable, passages which aren't going to change sentence structure over the years then you really should be getting that information from…

Agreed. It's some mix of the XY problem plus the self-entitlement of "if I had the idea, then it should work."

Yet the classic HNer confuses this for inherent weaknesses in the underlying platform that they then need to share lest someone has something good to say about the platform. And they'll often be using words like "terrible", "garbage", and "I hate..."

Re: Why it took a long time to build the tiny link preview on Wikipedia

#202
post #44

Earlier quoted context omitted.

I hate that I don't have the bar on the left to be able to switch to a different language conveniently. I use it all the time and I've no idea if it's even accessible at all in the mobile version. The mobile version also wastes a ton of screen real-estate but I guess that's fashionable these days. I really enjoy Wikipedia but the #1 item on my feature wishlist is "redirect me towards the non-mobile version of the sit…

Don't worry, they've also removed the ability to switch to other languages on the normal Wikipedia. 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?!

What? It will remember what languages you have clicked and put them outside.

This feature is a godsend, I no longer need to scroll hundreds of languages to find the one I need.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#204
post #124
post #86

Earlier quoted context omitted.

And what exactly is not "done right" about that? If it displays the information it's supposed to in a clean and organised way, and loads as fast as any other website, then I couldn't care less if it's a '90's table layout' or using whatever the hot new JS framework is.

Try to read today's Featured Article in a text-to-speech program. The markup is so mangled it can't even read a complete sentence because it breaks anytime the text links out.

JAWS didn't have any issues for me, which reader are you using?

Re: Why it took a long time to build the tiny link preview on Wikipedia

#205

There's a lot of negativity in these comments (which is to be expected, as it is still HN after all) but I've been using the preview boxes for a while now and have to say that I absolutely love them. I use Wikipedia a LOT for primative/secondary research and being able to even just figure out the dates someone lived, the very basic information, or even sometimes just a photo saves me from so many instances of new-tab…

Describing the comments here as "an echo chamber of hate" is inaccurate and serves to raise the temperature in itself.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#206

Earlier quoted context omitted.

You've misrepresented the reasoning. The best practice is: if you're going to tackle a major web UI problem, you should choose an approach that works for mobile (including iPads), which is already about half the traffic to wikipedia and growing. Especially if you are going to invest years of effort. Calling that reasoning "bizarre" is just being deliberately obtuse. To wit, some browser vendors have already started r…

That is not a best practice when there are fundamental differences between mouse vs touch. In fact, trying to smooth over both desktop and mobile experiences with the exact same UI brush is the main reason we're left with the worst of both worlds. By the way, Facebook also has hover previews on desktop. :) Also, force touch OSX UI isn't a replacement when you need to manually highlight multi-word selections for it to…

> trying to smooth over both desktop and mobile experiences with the exact same UI brush is the main reason we're left with the worst of both worlds.

Exactly the opposite is true. Browser vendors are able to customize the solution to the device and leverage new gestures. Case in point: Safari on desktop (3 finger tap) vs. mobile (3D touch). Even within page content, responsive design techniques can customize it to different devices.

> Also, force touch OSX UI isn't a replacement when you need to manually highlight multi-word selections for it to work.

There is no such thing as force touch on OSX (macOS). And we are talking about hyperlink previews, not selections. It sounds like you're a little confused here.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#207

Earlier quoted context omitted.

Oh, I absolutely agree. I am in no way saying that constructive criticism (or hell, even warranted, non-constructive criticism sometimes) is fine and should be encouraged! The comments I was referring to (many have either been deleted or removed) were quite a bit less focused on constructive criticism than they were on just a barrage of insults towards the team responsible as if this decision was made intentionally j…

My criticism is actually about lack of mobile support. I think it's not a good practice to invest years of effort solving a problem in a way that's fundamentally incompatible with mobile. Already nearly most traffic to wikipedia is mobile, and the share is growing.[1] Browser vendors seem better positioned to solve this problem. Indeed, my reaction to this was I've been doing this with Safari for years already (3 fin…

Mobile keeps growing indeed, but around 45% of our pageviews are still on desktop. Here's an overview on how this has changed in the last half decade: https://www.mediawiki.org/wiki/Wikimedia_Audiences#/media/Fi... (I'm the data analyst who has been working on this software feature, and also keeps track of Wikimedia's reader traffic in general.)
Post reply on HN