Show HN: I made a modern web UI for Wikipedia • Hacker News Board

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

#401

Post by dkonofalski » Tue, Dec 07, 2021, 4:44 PM UTC

tshaddox wrote: post #341

dkonofalski wrote: post #334

Earlier quoted context omitted.

No one is saying that mobile readers shouldn't ever share a URL on the "m." subdomain (despite them, quite literally, saying that). The criticism is that Wikipedia even has 2 separate resources for the same article and that the default behavior on "m." is to share the mobile resource while that's not the same case for the "en." subdomain (or other language variants). The only thing being said is that it should be con…

I agree with criticism of Wikipedia’s behavior. I disagree that ordinary visitors to the website should need to or indeed should manually manipulate the URL of the page they’re on in order to share it with someone else. If you’re sharing the URL directly with a specific person who you know feels strongly about which URL they received, then sure, do it to be nice. But I disagree with prescribing that one URL should be…

> I disagree that ordinary visitors to the website should need to or indeed should manually manipulate the URL of the page they’re on in order to share it with someone else.

Everyone agrees with you on this point. You shouldn't need to manually manipulate anything but, because Wikipedia keeps a desktop resource and a mobile resource, there is a distinction and so you do need to manually manipulate it if you're sending a link from mobile to someone else and don't know their device. That doesn't change the fact that sending a mobile URL should always show the mobile page because that is, in fact, a unique resource and, therefore, has a unique URL.

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

#402

Post by t-writescode » Tue, Dec 07, 2021, 5:15 PM UTC

account42 wrote: post #373

t-writescode wrote: post #303

Earlier quoted context omitted.

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

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.

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

#403

Post by [deleted] » Tue, Dec 07, 2021, 5:50 PM UTC

surajs wrote: post #161

nomemory wrote: post #24

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.

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

[deleted]

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

#404

Post by Robotbeat » Tue, Dec 07, 2021, 5:56 PM UTC

account42 wrote: post #369

Robotbeat wrote: post #353

Earlier quoted context omitted.

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

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.

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

#405

Post by naikrovek » Tue, Dec 07, 2021, 7:22 PM UTC

jasonkester wrote: post #364

amatecha wrote: post #121

Earlier quoted context omitted.

Whoa, I had no clue about these key-combos. So handy! Thanks!! For anyone curious, MS has a useful summary of how this works here: https://support.microsoft.com/en-us/windows/snap-your-window...

Thanks for giving me a name for this that I can search for to turn it off. There’s nothing more annoying in my day than when I drag a window from one monitor to the other, then the windows cuts it in half and sticks it to the side of my screen. I never knew what windows called it before, so there was no way to get rid of it in settings.

> I never knew what windows called it before, so there was no way to get rid of it in settings.

The settings pages aren't that big. You could read through it all in 5 minutes. Did you look? I mean sometimes things are annoying and you just can't be bothered to dig around to find the thing that turns it off, but at least in this case, it's easy:

Settings > System > Multitasking > Snap windows

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

#406

Post by jasonkester » Tue, Dec 07, 2021, 8:11 PM UTC

naikrovek wrote: post #405

jasonkester wrote: post #364

Earlier quoted context omitted.

Thanks for giving me a name for this that I can search for to turn it off. There’s nothing more annoying in my day than when I drag a window from one monitor to the other, then the windows cuts it in half and sticks it to the side of my screen. I never knew what windows called it before, so there was no way to get rid of it in settings.

> I never knew what windows called it before, so there was no way to get rid of it in settings. The settings pages aren't that big. You could read through it all in 5 minutes. Did you look? I mean sometimes things are annoying and you just can't be bothered to dig around to find the thing that turns it off, but at least in this case, it's easy: Settings > System > Multitasking > Snap windows

You can't possibly be serious.

Out of curiosity, I just opened Windows 10 Settings. I see sixteen top level options. I opened the first one and it had 16 submenus, the first of which is two pages tall and has 8 additional settings links from it. Of course, Control Panel is also a place it could be hiding, and it's even bigger.

So, no. One does not simply click on every single thing in settings hoping to find the annoying thing that Windows is doing today that you don't have a name for.

Typing "Snap Window" into search narrows it down to three, which makes it possible to accomplish.

Thanks again to the GP for enabling that.

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

#407

Post by tshaddox » Tue, Dec 07, 2021, 8:27 PM UTC

dkonofalski wrote: post #401

tshaddox wrote: post #341

Earlier quoted context omitted.

I agree with criticism of Wikipedia’s behavior. I disagree that ordinary visitors to the website should need to or indeed should manually manipulate the URL of the page they’re on in order to share it with someone else. If you’re sharing the URL directly with a specific person who you know feels strongly about which URL they received, then sure, do it to be nice. But I disagree with prescribing that one URL should be…

> I disagree that ordinary visitors to the website should need to or indeed should manually manipulate the URL of the page they’re on in order to share it with someone else. Everyone agrees with you on this point. You shouldn't need to manually manipulate anything but, because Wikipedia keeps a desktop resource and a mobile resource, there is a distinction and so you do need to manually manipulate it if you're sendin…

> because Wikipedia keeps a desktop resource and a mobile resource, there is a distinction and so you do need to manually manipulate it if you're sending a link from mobile to someone else and don't know their device.

As I've explained, even knowing their device is not sufficient, because someone on a desktop device may prefer the "mobile" design (which is responsive) or someone on a mobile device may prefer the desktop design (because it apparently contains more features). And if you're sharing the link with multiple people or publicly, you obviously can't accommodate mutually exclusive preferences.

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

#408

Post by jfrunyon » Tue, Dec 07, 2021, 8:40 PM UTC

thaumasiotes wrote: post #352

jfrunyon wrote: post #332

Earlier quoted context omitted.

> This is already the behavior of Wikipedia mobile pages. No, it's not. The behavior of the mobile pages is always mobile-optimized no matter what .

Yes. "Always the same no matter what" is what was described. If your friend is looking at a mobile wikipedia page, and sends you the URL for that page, then you too will see the same mobile wikipedia page when you follow the link. That's the whole concept of being "the same".

No, what was described was specifically "the same Wikipedia page their friend saw, adapted to their screen". "The same Wikipedia page their friend saw" meaning the same contents - the same rendered Wikitext - they don't care about getting the same experience, they want the same data. "adapted to their screen" meaning NOT seeing the mobile experience on a desktop!

I can only assume you are trolling because you are assuming a meaning that is the complete antithesis of what namdnay explicitly said (and what everyone else in this dead thread has been telling you). Therefore I will go ahead and say farewell and good luck.

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

#409

Post by jfrunyon » Tue, Dec 07, 2021, 8:46 PM UTC

dkonofalski wrote: post #316

tshaddox wrote: post #188

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

en.m. is NOT a seperate resource from en.. It is the SAME resource because it has the SAME content and because editing the content on EITHER changes the content on the other. It is a different PRESENTATION of the content, which should be served at the same URL. This is WHY HTTP has such headers as Vary and Accept.

If en.m. is asking for the mobile version, then en. is asking for the desktop version, yes? So why does en. redirect to en.m. on mobile?

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

#410

Post by iggldiggl » Tue, Dec 07, 2021, 8:52 PM UTC

account42 wrote: post #372

mattnewton wrote: post #231

Earlier quoted context omitted.

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

You're goning to need 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…

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