Comment by wolrah | Hacker News Reader

Comment by wolrah | Hacker News Reader

If the author or anyone else with the ability to update Wikipedia's code itself is reading this, I have a suggestion for some low-hanging fruit that wastes a lot more than 300ms for all sorts of users, not just those on low-end mobile devices.

Wikipedia, like many web sites, makes it really easy for mobile users to get redirected to a mobile-specific version running on a mobile-specific domain.

The problem is that this mobile-specific version is not good for browsing on a full computer. It's not even great on a tablet. But there's no easy way to switch back when I've been sent a mobile-specific link other than editing the link by hand. Mobile links end up everywhere thanks to phone users just copy/pasting whatever they have, and desktop users suffer as a result.

Please, anyone who develops web sites, stop doing the mobile-specific URL nonsense. Make your pages adaptable to just work properly on all target devices.

If you insist on doing things this way with mobile-specific URLs, at least make it equally easy for desktop users to get off the mobile URLs as you make it for phone users to get on them.

There has been an RFC about it (for years).

"Remove .m. subdomain, serve mobile and desktop variants through the same URL" https://phabricator.wikimedia.org/T214998

There problem is when your auto-detection gets it wrong and you keep getting served the mobile version even if you are not (looking at you www.arista.com).

This is a good use of a session cookie. Or even a stored cookie.

It would be considered a non-tracking essential site function value too, so you wouldn't need to beg permission (contrary to what people who want us to be against privacy legislation will claim), and the site is probably already asking for permission anyway for other reasons so even that point is moot.

Unfortunately "non-tracking cookies" are no longer a thing in most browsers.

I was meaning non-tracking essential cookies, as defined by privacy legislation that requires permission for things that are not essential for site features.

Or are you suggesting mainstream browsers are blocking same-origin session-level cookies by default now? I'm not aware of any. And if you have a browser that is blocking such things, the worst that will happen is the current behaviour (repeated mis-guesses because the preference isn't stored) continues.

Safari drops first-party cookies (and all other storage) on sites that have not seen interaction in 7 days.

Wouldn't this log you out of everything?

Everything you've not visited in the last seven days, yes.

Things you touch regularly should be fine.

And apparently it only affects mass local storage, not cookies which are most often used for season management (so you might stay logged in but the app need to reset data previously called in local storage).

Needing to re-override the incorrectly detected mobile/not upon return after a full week away will be massively less annoying than needing to do it every new page request, so that shouldn't be problematical.

That Safari does this is useful information that I may need to warn users of one of my projects about, as it means intentionally offline data has a much shorter expiry date than on other platforms.

This is not entirely accurate. It's only script-writable storage. HTTP cookies are not removed.

I'm not defending Safari's policy, by the way, just describing. I think it sucks, and a conspiracy theorist might note how it favors native apps over web apps.

Thanks for the clarification!

how would a cookie help with better auto-detection? to store the platform, maybe, but how do you determine whether the user wants a mobile/desktop version to begin with?

It doesn't help the detection, it means that the override when the detection fails is remembered so the site knows to just pick a particular version instead of using the detection method at all.

It is a work-around improving the UX on the second and subsequent requests, not a fix for the root cause.

If you do it right you don't have auto-detection because you don't have separate versions of the page in the first place. CSS is powerful enough to adapt a page to whatever viewport it happens to be displayed on.

Hot take: the mobile site also isn't good for cellphones

Agree! I despise almost all mobile sites, even from my phone. "responsive" sites invariably suck too. Give me the full desktop site every time.

Are you so sure you want that 300px left panel on your 480px screen?

Responsive sites are great. If you really want a desktop view, use your browser's desktop mode. If it doesn't have one, find a better browser.

My main gripe about the Wikipedia mobile site is that text search doesn't work on the collapsed sections, and there's no way to expand all sections at once. The simplest thing left to do is the request/navigate to the desktop site and use your browser's find text feature then.

Scroll down to the bottom, click "Desktop". Not easy to notice that this is an option, not too hard to use once you've found out.

And yet practically very little effort for Wikipedia to serve the correct version

But how do you determine the users intent?

They asked for the mobile version - but they're on desktop.

Do you serve what the asked for? Or what you think they should want?

What if they actually want the mobile version - if you always send desktop to desktop, then they can't get mobile...

On mobile, they asked for the desktop version, and got redirected to mobile. Does intent not matter there? If you are going to redirect automatically, then redirect back automatically.

You do what's best for the majority of users.

This is the opposite of accessibility.

Not necessarily. You can optimize for the majority, but still keep things functional for everyone else.

Not sure why the downvotes, this is a reasonable question. (As evidenced by all the other answers...)

The simple answer is that you don't encode device specific intent in the URI, you put in in style sheets where it belongs.

Not a downvoter, but I can understand them. GP's comment assumes that there need to be different versions of the page, while HTML allows degradable experience. Just have the same page and make it work properly everywhere.

You’re getting downvoted, but this is a totally legitimate comment. A sizable minority of people prefer the mobile WP interface and find it cleaner even on a non-mobile device.

m.wikipedia isn’t the default, so it’s different from regular wikipedia.com redirecting a mobile user to the mobile version.

It’s easier for them to go to m.wikipedia.com than to change their user agent, especially if they aren’t that technical.

There are plenty of websites where you can switch between mobile and desktop websites without using multiple URLs.

The point is that the user can go to `m.wikipedia.com` and not do anything else. They don't have to hunt around for a footer option, they don't have to do multiple page loads (which can cost some people money!), they don't have to keep some cookies around or use the same device for their preference to be maintained.

Note also that WP isn't alone in their choice. Facebook, another website with a large non-Western user base, also maintains the same behavior. Go to https://m.facebook.com, you won't be redirected to https://facebook.com .

There are tradeoffs either way, and no matter what WP does, they'll be making some users unhappy. Not all of these users fit the same profile, either. Wikipedia has a global user base, so what's best for most American sites isn't necessarily what's best for Wikipedia. Ultimately, it's not the case that one option is right, and the other is wrong.

I think the right option is to use whatever is best for most users. Most users (by far) will be fine with being served the mobile/desktop website automatically, depending on whether they use a mobile/desktop browser.

m.wikipedia also requires less network bandwidth which may be exactly what you want in some situations.

- Desktop: 388kB (https://en.wikipedia.org/wiki/Rickrolling)

- Mobile: 221kB (https://en.m.wikipedia.org/wiki/Rickrolling)

Modern browsers all have buttons to toggle user agent preferences in their dev tools. This is a highly technical request and the solution really only needs to be accessible to highly technical users... it's much _much_ more likely that less technical users with strong style preferences will use one of the dozens of pre-configured alternative CSS extensions or just write up their own stylesheet.

I love user customization but this is extremely niche.

No there is no asking for mobile version in the link, the links are the same for both.

You rely on saving the user display preference as a cookie that persists across sessions.

They declare their preference on a device a single time on the site and that's remembered. None of this has anything to do with which URL is being used.

(Not to mention that following a link on a page like "en.m.wikipedia.org" isn't even user intent, it's author intent at most. But usually not even that, because the author just copied the link without even thinking whether it had an "m." in it or not.)

You send them what their browser is asking for - if the user wants a different screen format they're tech savvy enough that they can manually edit their user agent request headers. It's actually quite easy and most browsers (if you pop open dev tools) will have an option to switch the render area to a variety of mobile devices and doing so will cause the request headers to be adjusted appropriately.

Yeah, but that takes longer than 300ms ;)

Since the redesign the expandable categories of the mobile Wikipedia website expand no more than once on Android Firefox beta, so I constantly must reload the page to read new categories.

Fixing this might be a good way to reduce bandwidth.

I'd add shareable links, with some "copy link" ui for headings in articles, please!

Reply on news.ycombinator.com