Hacker News Reader

Comment by nomemory | Hacker News Reader

I am one of those people who actually like Wikipedia the way it is. It's what I hoped the web to become.

But i am sure there are people who will appreciate your effort. Thank you for your work.

I agree with you except the one pain point that Wikipedia still continues to use "m.*" sub-domains for displaying mobile content. I know most people exclusively use mobile these days but I use desktop browsers for reading more than 60% of the time and its really annoying to click on a Wikipedia link on HN/Reddit and having it open the mobile site on desktop. It's OK to use m.* subdomains instead of reactive design but there should at least be redirects to the correct subdomains.

edit: formatting

I’m sure there is JS that will redirect you to non mobile, pretty sure I installed something like that and never had that issue.

Firefox plugin: Skip Mobile Wikipedia

https://addons.mozilla.org/en-US/firefox/addon/skip-mobile-w...

Down the bottom there is a link to the desktop version of the site.

Whoa, thanks.

However, that link is totally in the wrong place, no wonder I could not find it. I just assumed there was no such link/button and always angrily removed the 'm.' from each URL.

TIL!

Equally, I don't like it when websites try to guess what kind of browser I'm in and force me into the mobile experience when I have a window take up half the screen on a 1080p monitor, ... so I guess there's really no easy win for this :(

I think proper media queries breakpoints solve this

No, it won't. There is no clear distinction between mobile and tablet first of all.

Orientation and width not enough?

When I pin a browser to the left or right side of one of my monitors, these sites will often go into mobile mode despite the fact that the browser is still wide enough that desktop mode works fine, merely because the window is now taller than it is wide. And I find that incredibly annoying.

This is hard and often done wrong- mobile phones are usually high dpi and have gotten quite large, so it can be hard to distinguish between a large phone and half a desktop screen. Some people get quite annoyed by being bumped into a mobile experience when you resize your window from fullscreen on a laptop.

> This is hard and often done wrong- mobile phones are usually high dpi and have gotten quite large, so it can be hard to distinguish between a large phone and half a desktop screen.

A tablet could be easily confused, or a phone in landscape mode, too, but for a phone in portrait mode this seems a bit hard to imagine, because DPI is taken into account when converting the display width into CSS pixels, so even a phone cramming 1080 or 1440 or whatever amount of physical screen pixels into its display width should still come in at something like 300 to 400ish CSS pixels. Or am I misunderstanding something?

You have it right.

You're right, and it's certainly a solvable problem but one that often is not solved correctly is my point. You may have to also introduce a (nonstandard) viewport tag to prevent mobile browsers from laying out the page at a much higher resolution and then zooming/shrinking on you https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m... If you don't, you may falsely conclude from manual testing that you need large breakpoints for mobile.

Also, many times mobile breakpoints don't look at the device orientation and pick numbers like 800px, to capture landscape orientation on medium sized phones or something (I'm not sure where this number comes from to be honest). This obviously breaks the two windows side by side case on laptops but is a top result for me if you google the arcane syntax for how to target mobile browsers with a media query.

I am not 100% sure what all the pitfalls are with the current interface, but they exist often enough for me to run into them semi-frequently on smaller laptops.

You're goning to need <meta name="viewport" content="width=device-width, initial-scale=1"> tag for any reactive design with mobile browsers since otherwise the site will look completely different between browsers and browser versions as they use different rules for how to render sites.

The worst part of this is that simple mostly text sites without a fixed-with layout would look perfectly on mobile if this tag was the default but somehow mobile browser vendors thought it was better to hack around sites with table layouts by giving them a larger viewport (but still inconsitently scale the font sizes so you have to zoom in and out to read different parts).

> (but still inconsitently scale the font sizes so you have to zoom in and out to read different parts)

Once you start with the hack of giving non-mobile-compatible pages a larger viewport in order to not break layouts that react allergic when being squeezed into 300-something pixels, what else do you want to do?

Not scaling font sizes at all just gives you either tiny text (if you zoom out to fit the large viewport onto the small mobile screen) or loads of scrolling around if you display the page at 100 % zoom level instead.

And scaling up all text means you end up approximatively just where you started before you started resizing the viewport. It might not be absolutely exactly the same layout breakage as when squeezing an old page directly into the 300 or so pixels available on a mobile phone in portrait mode, but it will be pretty similar.

So that only leaves trying to scale up only the main body of text (which normally isn't that sensitive with regards to scaling up the font size and therefore increasing its size requirements) and leaving alone smaller bits of text like menus, the page navigation etc., which are more likely to be size-constrained and start causing layout breakage if increased by an extraordinary amount.

I don’t understand those people at all. If my browser window is the width of a mobile phone’s screen, than a version of the website designed for that size is exactly what I want!

Right! If you've got a window that narrow, the only way the design will even work or layout correctly is with the "mobile" layout...

The bigger problem is people hiding functionality if you're in the mobile breakpoint. That's an issue: all functionality should be enabled, at least in some way IMO. Mobile should never be a second class citizen :)

There's also a big problem where the mobile layout will tend to make controls huge to present a reasonable size touch target. This is unnecessary on the desktop, and may even result in less information fitting on screen than before switching to the mobile layout.

Thats a fun one to solve!

   @media (hover: none) and (pointer: coarse) {

That allows the dev to select for devices that do not have a mouse and such rely on touch targets, to increase the sizing. I've been implementing this myself recently in our web application, while still allowing us to change the layout to fit the narrow width!

I'm sure there are some devices it doesn't fit perfectly for though. This stuff is capital-H hard.

> capital-H hard

You mean quote-unquote Hard?

I wish.

The implementations for these have some... complications, the device sets we now deal with are huge, and making sure there are no idiosyncratic bugs that creep up when using them is legitimately a fair bit of work.

https://css-tricks.com/interaction-media-features-and-their-...

> If my browser window is the width of a mobile phone’s screen

It's not, is the thing.

I have a 23 inch screen for my 1080p screen. My phone has a 6ish inch diagonal.

When I make a window 960 x 1080, that's still something like 10 inches across and 11 inches tall. It's sheet-of-paper sized. I'm perfectly comfortable reading that as it was designed for a desktop layout.

> I have a 23 inch screen for my 1080p screen. My phone has a 6ish inch diagonal.

Do you sit as close to your monitor as you hold your phone?

Not GP, but yeah, about the same? From your phrasing I expect it's how close we hold our phones that differs though.

I would say that half of my monitor, more accurately, is about the dimensions of an iPad at comfortable viewing distance.

Phones are far taller than half of a 1080p screen.

Half a monitor is: 960 x 1080, or 1:1.125 A iPhone is: 828 x 1792, or 1:2.164

So websites tend to shove a candybar shape into a nearly square sheet of paper and waste a lot of usable proportions for things like controls or hamburger menus.

Not necessarily: the real-world size matters too. Desktop-sized UI is hard to hit on a touchscreen when shrunk; meanwhile mobile-sized UI wastes space when enlarged on a desktop monitor.

Do you also want the version for touch controls?

The worst part is that the other points you could use: DPI, resolution, touch capability... all of this exists on certain laptops now!

But, at least as far as I approach media queries, if you've triggered the mobile breakpoint (well, default CSS as mobile-first is the way we approach it), its because the desktop design we've used literally will break on a browser window that narrow.

I also get annoyed when I get bumped to the "mobile" "experience" even when I'm on a smartphone. With reactive design, "request desktop site" generally doesn't work, either.

I really, REALLY prefer desktop mode for almost everything, relying on pinch to zoom.

> With reactive design, "request desktop site" generally doesn't work, either.

It shouldn't, because with proper reactive design therre are no "mobile" and "desktop" versions but only one version that adapts to the viewport size. If you want a larger viewport that should be solved at the browser level by providing the website with a larger viewport. Seems firefox behaves this way while chrome does something weird that increases the viewport a bit but then still "intelligently" scales some text.

Well what if you don’t WANT the interface to change between viewports? We used to use Desktop-style interfaces on 1024x768 displays, or even 640x480. Now we just get a one-dimensional mobile interface when the viewport is smaller than whatever arbitrary threshold is fashionable among designers. It’s incredibly annoying to have interfaces become downgraded (ie hyper-simplified) regardless of what the user requests just because they haven’t kept up with the resolution upgrade treadmill. Pinch and zoom (in BOTH directions) is such a powerful UI tool from the user’s perspective but its usefulness has become completely neutered by insistence on “reactive” design ripping control away from the user.

Even better: Don't have media queries breaking at some arbitraty widths at all, and have a design, which is responsive for all widths without breaking suddenly, orienting size of boxes depending on the content.

As soon as you have any kind of columns in your layout you need sudden breaks at some points, explicit or not.

I agree that you should prefer flow and size-to-fit but that does not mean that break points are never the right tool.

Install Firefox Redirector: https://addons.mozilla.org/en-US/firefox/addon/redirector/ Add a rule to redirect (https?://)?(\w+\.)m\.wikipedia.org(.*) to $1$2wikipedia.org$3 Then you never have to deal with mobile Wikipedia on desktop again. You can use this for other sites too, like forcing all uses of Reddit to always open in old.reddit.com.

Just as a sidenote on the Reddit point, you can force old Reddit from your settings after you log in. That setting seems to stick even if you log out/your session times out, and you can go back to new Reddit with new.reddit.com.

> It's OK to use m.* subdomains instead of reactive design but there should at least be redirects to the correct subdomains.

I agree, although in the case of Wikipedia the "mobile" design is actually the one that is responsive. I want the "mobile" design on all browsers including my desktop. I believe you can actually set your default theme if you're logged into Wikipedia, but I don't know if their cookies eventually expire or what, but I often end up clicking on Wikipedia links and getting the awful "desktop" design.

All of this is just to say that, yes, they shouldn't use separate "m." URLs, but it's just as wrong to get upset at mobile users sharing "m." URLs as it is to get upset at desktop users sharing URLs without the "m." Arguably if you expect all users to always share the most versatile URL, you should expect them to always share the "m." URL since it has a responsive design.

I might be ok with "the mobile reactive version everywhere" if it didn't also lack a bunch of features. Not being able to easily get to the talk page to contextualize what you're reading makes the mobile site very frustrating.

Note that a link to the talk page has recently been added to the top of the mobile page.

Oh nice, thanks for letting me know! I can stop forcing it to desktop mode by default heh.

If it pinned the headings/outline to the left side of the article (like the extension showcased does) it'd be that much better for a responsive design on Desktop.

Yes, I only use Wikipedia on a desktop and I exclusively use the m. site.

I disagree that the m. url is the most versatile because of the one-sided redirect.

Also the mobile site might be more responsive in the sense that it better scales down to narrower viewports but it does not scale up to make use of larger viewports by e.g. bringing back the sidebar and other links that are hidden behind dropdowns. That's a problem with many mobile-first designs - in reallity they are mobile-only designs.

semi-OT but Twitter seems to have recently started putting "mobile.twitter.com" in my URL bar (on mobile), as well as adding a UUID in a "t" query param when you use their "copy link" flow, which is all annoying cruft to have to delete when sharing links.

They used to just put "?s=19" through "?s=22" or so, which enumerated clients (desktop, mobile, Android, etc), which was better than the junk most other services stuff in (like utm_source and friends...)

What bothers me most about this is that if you go to www on a mobile device, it redirects you to m - that's great, and probably the "right" thing to do. There is probably a "View Desktop Version" link on the mobile page, somewhere. But if you go to the m subdomain on a desktop device, there's no easy way to get to the desktop version without manually changing the URL. If you can redirect from www to m, surely you can redirect from m to www when appropriate.

> But if you go to the m subdomain on a desktop device, there's no easy way to get to the desktop version without manually changing the URL.

You may find humour in the comically small "desktop" link at the very end of the page, next to the privacy policy.

I feel like there's the issue on Reddit

I feel like this is the least of the issues of Reddit(’s mobile version, social ones excluded for lack of knowledge).

I use the No More Mobile plugin to fix that: https://github.com/spixy/NoMoreMobile

For me on safari I just click “request desktop site” and it does redirect me to the non mobile domain.

https://phabricator.wikimedia.org/T214998

That seems to be about serving the different variants directly instead of the redirect when there really should only be one variant that makes the best use of any viewport size.

I dunno. Maybe it is different on a phone but on a tablet the desktop Wikipedia is better than the mobile Wikipedia.

+1 to this. My iPad is plenty big enough please show me the real Wikipedia. The redirect is incredibly frustrating.

On a phone, the mobile Wikipedia is perfect tho.

I got annoyed at this enough to write this tiny userscript:

    // ==UserScript==
    // @name         Redirect from mobile wiki to desktop
    // @namespace    http://tampermonkey.net/
    // @version      0.1
    // @description  try to take over the world!
    // @author       You
    // @match        https://*.m.wikipedia.org/*
    // @grant        none
    // @run-at       document-start
    // ==/UserScript==
    
    window.location.hostname=window.location.hostname.split(".")[0]+".wikipedia.org";

Hint: Use `document.location.replace()` to prevent the back button from going back to the mobile version, creating an endless loop.

Counterpoint to this:

I’m career military and the fact that Wikipedia (and Facebook) have low bandwidth m.* redirects made life immensely easier on the limited internet in far off places. We really appreciated it being available.

Just checked the first acticle linked on the home page:

https://en.wikipedia.org/wiki/Yugoslav_gunboat_Beli_Orao - 913.39 KB / 298.41 KB transferred

https://en.m.wikipedia.org/wiki/Yugoslav_gunboat_Beli_Orao - 919.43 KB / 270.18 KB transferred

Not much of a difference. Would be better to spend time optimizing the desktop site for everyone.

As one of the people who uses a mobile device only if I have no other choice (which is never), I definitely feel the pain of this.

Yeah, it's so annoying. I always strip the mobile subdomain when I post links to wikipedia.

It is also pretty fundamentally broken on iPad, since whether it reports itself as a mobile or desktop device depends on the size of the browser window.

Just a small nitpick: you mean _responsive_ design (_reactive_ means something else)

I usually shy away from "modern redesign" but this one feels rapidly valuable both in legibility and usability.

The chasing left side TOC is really useful. The typography is slightly fancy without trying to be in your face.

The search (kbd /) is nice too.

I'd motivate the author to experiment with more stuff around accessing categories and hyperlinks in the page.

Yeah, I actually like the existing Wikipedia design, but I like what the author has done here - I see it more as a minor UI evolution, with some additional conveniences.

I like it!

I too like wikipedia current status a lot, and i like basic static content too.

Agreed with most of this stuff, but search on / (and even ctrl-f on some websites!) is horrible because it overrides the browser's shortcuts. When I press / I expect the Firefox quick find bar to come up, complete with highlighting and markers in the scrollbar and ctrl-{shift}-g to move between results and esc to exit search. Not some half baked JS search implementation or an unrelated search like in this extension - it searches for wiki pages, not text within the current page.

Fortunately this is pretty simple to disable with Greasemonkey (also 's' on github, though the userscript doesn't seem to work on Gitlab...).

This isn't so bad but consider new Reddit vs. old Reddit.

If "new" were to become the only way to access Reddit, I would probably abandon it.

It is really annoying to be shown the new site so I just use mobile apps to read it now.

I love my mobile app as well (RIF), but do you know about old.reddit.com? Still works great with RES, I couldn't imagine Reddit on the desktop any other way

Yup still do that on desktop, I have it automatically redirect me, I would hate to lose it!

Sometimes links to other subs go to the new site, sometimes stays on old, I suppose depending on how the links are set up.

> so I just use mobile apps

That might have been their goal?

Although I detest having to use apps for every site. The Reddit app is also super buggy.

I use Sync for Reddit on Android and Apollo on iOS.

They don't need to force you to migrate, the new site pushes people into mindless meme sharing only, and completely altered the contents of the site already.

I've had to banish a good 40+ subreddits off my feed manually using RES to just deal with the politics spam.

And even then, browsing /r/popular is just awful. Elimination games. People blatantly asking for personal information from teenagers. "Tell me your favorite X and we will judge you" Dumb NSFW 'questions'. Repost bots for content from years ago. Misinformative titles. "Unpopular opinion" threads.

It's a mountain of trash to wade through to get any decent content.

I always stay away from /r/popular. The subreddits that appear there like /r/PublicFreakout are selected for display so you can get angered, join the echo chamber in the comments and boost engagement metrics.

Watching many of those short anger-inducting videos can make even a calm person change. The sort of stuff Reddit PMs have signed off on in the name of engagement is despicable.

I agree, and I have already left using reddit. What's the alternative to some random content consumption (like reddit)? Like hacker news but for non-technology topics.

I can suggest wiby.me 's random button to discover new sites with modern opinions.

There's various Lemmy [1] instances. Maybe one of them works for you?

[1] https://join-lemmy.org/

+1 for Lemmy. The project still has quite a lot to improve on, but it is already really great! I'd love to see the community/network grow and evolve :)

disclaimer: I run lemmy.pt and use the platform on a daily basis

How does the new design push people to mindlessly meme share? Reddit has been like that for a decade or more at least IMO.

They only show a few comments on certain pages, which deemphasizes discussion. I'm not aware of any other changes to new Reddit that would do that.

Although other changes might have made things better, like changing how default subreddits work (although this applies to new and old reddit).

With the exception of a few subreddits that have made explicit rule changes (either encouraging or discouraging memes), I haven't really noticed a significant long term trend in meme-posting within subreddits.

On desktop you can choose to remain on the old format.

On mobile you seem to need to do old.reddit.com every time.

Never installed the app on mobile.

I saw this comment, and assumed I would agree with you, but the sample image that was presented to me on clicking the link to the post appealed to me in at least one major aspect, and that's the table of contents on the side of the content. I'm often having to scroll to the top to quickly visit a couple different sections when I'm looking for some specific knowledge, and being able to quickly navigate with less scrolling would be a welcome improvement in my eyes.

On another note given that Wikipedia's content is in the open, maybe this new UI could be hosted at another domain e.g. pickypedia.org or itchypedia.org or something else funny instead of being a Chrome plugin.

Chrome plugins add more unwelcome startup bloat to the web browser, and while they are super useful to fix the UI issues of commercial, copyrighted websites, Wikipedia can totally legally be replicated at another domain.

You'd still need the old wikipedia to edit any articles and you'd still need a browser extension to redirect regular wikipedia links to your favorite frontend.

Also just like with open source projects, just because you are allowed to fork does not mean that you should as you could end up hurting the original project by e.g. confusing users.

Wikipedia's style is almost perfect except for one thing that bugs me: the line width in desktop style is unlimited, meaning in a big window it can be hundreds of symbols long, which is pretty bad from the readability standpoint (https://baymard.com/blog/line-length-readability).

They've changed that, but so far I've only seen the change on French Wikipedia. I think they test it on us before broader release.

Indeed! Good to know.

Yeah they have changed some other Wikis too (like Portuguese). I think this is up to each wiki's governance (afaik they are somewhat independent) to opt-in on the new design.

I'm not sure I like it. The better line width is really welcome, but I'm tad uneasy about the rest. And as far as I can recall, it doesn't have a dark theme (yet).

Same here, we're fortunate it hasn't gone down the road of typical webdev anti-patterns. (at least besides the donation banners, which is understandable ;) )

Agreed, still love the untouched UI but work like this seems like it will only help reinforce the accessibility and long-term health of the project.

I will say I am glad you did this -- and practiced restraint. It is a nice modern update without overdoing it.

Yes but...

I miss the Encarta encyclopedia content/design. I wish Wikipedia could get to that level of content quality. The multimedia and interactive articles were way ahead of its time and were only partially matched by some Flash-based interactive animations.

"Modern web" isn't bad because of it's design, it's awful because of the dark patterns and 5s+ load times.

You don't need 20MB React bundles to make a good-looking website, and OP proves that perfectly

Wikipedia still doesn't show the talk page when you are on mobile.

Actually, I'm wrong. It looks like they FINALLY added it less than a week ago.

Took them long enough.

That extension doesn't change how the web is. The web is still the same whether you use client side CSS override or not.

This is exactly how CSS and HTML were intended to operate and the kind of results to be expected.

> But i am sure there are people who will appreciate your effort. Thank you for your work.

How is that called ? A complimentsult ?

Not at all a complimensult. I can appreciate the work of someone, if even I won't use it. I don't know how to put it otherwise.

You just say thanks for sharing and drop the other bit.

Well, I don't consider I've insulted someone by saying I like the way Wikipedia is.

There's no insult in saying it isn't for me because ... but good job. Positive criticism can be useful too.

Yeah this is great but I'd rather stick with the tightly wound tools at Wikimedia, they probably know what they're doing more than this anemic blasphemy

Why not be positive? Instead of insults you could give positive criticism. There's nothing positive gained from being negative.

Electrons brought us a lot positivity with their negativity! Checkmate!

Seing as wikipedia still has a separate m. subdomain in $current_year instead of just one responsive page means any claims that they know what they are doing will need to be backed up by evidence.

Reply on news.ycombinator.com