Live data from Hacker News

Show HN: I made a modern web UI for Wikipedia

modernwiki.app

311–320 of 426 posts

Re: Show HN: I made a modern web UI for Wikipedia

#311
post #247
post #12

Earlier quoted context omitted.

I've just looked into this, it seems Chrome displays that because of the "tabs" permission: > "Technically this permission allows observing the history via chrome.tabs.onUpdated, but not read the previously existing history, so the phrasing is not entirely correct, strictly speaking." https://stackoverflow.com/questions/64063754/chrome-extensio... To be clear, the extension doesn't access your browsing history at all…

Note that you could also make it a bookmarklet which requires no permissions and only accesses the current tab when the user clicks it. Would be nice for trying out how it looks, given how little it changes I was expecting this would be a little bookmarklet and was a bit disappointed I had to add an extension to my browser for trying the look.

A bookmarklet would have to be clicked every time you open a new wikipedia page. I think it would be more productive to just fix the main permission issue (can view entire browsing history - author says in a comment they'll be fixing it). Chrome also lets you keep the extension inactive - you can easily activate it on-demand from the toolbar. If you do that on a minimal-permission extension, you have the equivalent of a bookmarklet.

Re: Show HN: I made a modern web UI for Wikipedia

#312

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 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.

Re: Show HN: I made a modern web UI for Wikipedia

#313
post #299

Earlier quoted context omitted.

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.

Re: Show HN: I made a modern web UI for Wikipedia

#314

Earlier quoted context omitted.

> But I would say that it's the HN commenters being incredibly obnoxious, not wikipedia being wrong for giving you the mobile site when you specifically ask for it. But it's kinda crazy that if I'm on my phone I can't just share a URL to a page with someone who happens to be using a desktop. While I'm not sure if this is made explicit in any of the RFCs or standard docs, in my view a URL should be a locator for a res…

> But it's kinda crazy that if I'm on my phone I can't just share a URL to a page with someone who happens to be using a desktop. > in my view a URL should be a locator for a resource that is agnostic of the user agent. You're not making sense. The mobile page has a dedicated URL. If you're browsing it, then sharing the URL will send anyone else to the same resource you're browsing, regardless of their user agent. Ev…

I always remove the m. from Wikipedia links when I share them somewhere that people can browse from the desktop (example HN). People tapping on that link on a phone will be redirected to the mobile version anyway. I don't remove the m. when I share on a messenger (example WhatsApp) when is somebody could receive the message on a desktop. I should probably always remove the m.

Re: Show HN: I made a modern web UI for Wikipedia

#315
post #299

Earlier quoted context omitted.

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.

Re: Show HN: I made a modern web UI for Wikipedia

#316

Earlier quoted context omitted.

> You're mistaken. Wikipedia automatically redirects you to the m. website if you type "en.wikipedia.org" into your phone browser. The same is true even if you explicitly type an article's URL into your phone browser, like "en.wikipedia.org/London". What am I mistaken about? This is exactly what I said happens. I focused this information pretty heavily: >> The standard page will redirect mobile user-agents to the mob…

You're mistaken that being on the "m." subdomain indicates that you have made some decision to do so, and that sharing that URL ought to send anyone to the mobile design. On the contrary, the entire point of a URL is for sharing a resource, and if a URL to a public resources is not shareable that is a mistake on the part of the web site, not a mistake on the part of the visitor. It's certainly not the case that "Ever…

I'm just jumping into this now but you're not really listening to what the parent is saying. You seem to be acknowledging their point but then ignoring what they're saying.

No one is talking about what should happen. They're saying that, as you've confirmed, m.* is a separate resource from en.* because they exist as 2 separate pages on wikipedia.org. On the en.* page, people on mobile are incorrectly redirected to m.* which it seems that everyone agrees shouldn't be the behavior. The opposite, m.* redirecting people on desktop, doesn't occur.

That means that your statement that "URLs should be for a specific resource" contradicts your other statement that "sharing that URL ought [not] to send anyone to the mobile design". If the mobile page is a separate resource, then sending someone a link to m.* should always load that resource (the mobile version) which seems to the be the opposite of what you're suggesting.

Additionally, there seems to be additional confusion because everyone is assuming that the page loaded at m.* is the same page as that loaded on en.* but that doesn't seem to be the case as the page isn't responsive. It's the same text content but the stylesheet and headers are different which, by web standards, is a separate resource.

Re: Show HN: I made a modern web UI for Wikipedia

#317
post #74

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 bu…

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

Re: Show HN: I made a modern web UI for Wikipedia

#318

Earlier quoted context omitted.

That, and the density. I like desktop UIs to be dense. They don't have to be sparse with ample padding like on mobile devices since you don't poke your fingers into your monitor. Yet somehow, people keep designing desktop UIs as if there's a touchscreen or something.

> people keep designing desktop UIs as if there's a touchscreen or something I think that also has to do with "more white space = more scrolling = more ads". Reddit is a perfect example of this. When they "updated" their UI to the current one, they added a ton of extra white space which forced people to scroll longer, thus spending more time on the site and viewing more ads. They also use a ton of other dark patterns…

Along with a tiny body font, the effect is to more or less force you to maximize the window to make the site usable -- i.e. commandeer your desktop. Squarespace was an "innovator" in this technique.

Re: Show HN: I made a modern web UI for Wikipedia

#319
post #6

OP, thanks for making this, I bet it was fun to build. That being said, I want someone to do the opposite of what this does. Less chrome, less bytes over the wire, less predictive search, less "flatness?", less timely, more timeless .

Oh dang, yeah. An extension that makes the whole web look and work like the default Mediawiki skin would be glorious. And _fast_. I miss windows having borders. Just dug up a registry hack (obscene that such a thing was needed) to force win10 to have window borders again, because I keep ending up in situations where I honestly couldn't tell where one ends and the other begins. They spent decades researching and build…

Any more details on that registry hack? I have been using RetroBar to have clear borders on taskbar and nostalgia. It doesn't have all actual features of windows 10 taskbar though.

Re: Show HN: I made a modern web UI for Wikipedia

#320

Earlier quoted context omitted.

You're mistaken that being on the "m." subdomain indicates that you have made some decision to do so, and that sharing that URL ought to send anyone to the mobile design. On the contrary, the entire point of a URL is for sharing a resource, and if a URL to a public resources is not shareable that is a mistake on the part of the web site, not a mistake on the part of the visitor. It's certainly not the case that "Ever…

I'm just jumping into this now but you're not really listening to what the parent is saying. You seem to be acknowledging their point but then ignoring what they're saying. No one is talking about what should happen. They're saying that, as you've confirmed, m.* is a separate resource from en.* because they exist as 2 separate pages on wikipedia.org. On the en.* page, people on mobile are incorrectly redirected to m.…

I understand all of that and still disagree with the claim that mobile readers should never share a Wikipedia URL containing on the "m." subdomain. I simply do not agree. They got to that URL probably without every explicitly asking for a mobile-specific page, so they ought to freely share that URL. Moreover, this "mobile" design is in fact more responsive than the "desktop" design, and some people might even prefer to always see the mobile design even when they are on a desktop computer. I think it's outlandish to say that mobile users should never share the URLs they are viewing simply because some (but not all!) desktop users might prefer the desktop design.
Post reply on HN