Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

In iOS Safari there is a menu option ‘request desktop site’. I have now found out that don’t actually know what it does, but I used to think I did.I’m hoping someone can tell me what is actually going on. My questions:

• Could someone help me understand what it is supposed to do?
  
• how does this actually work, at a low level?
  
• is the following assessment vaguely correct, or not?
  

Some times it seems to make the appearance better, sometimes worse. Take Wikipedia for example. Selecting the option causes the page to be redrawn with a totally different appearance. Before, the page was very much simplified with a lot of stuff missing. The column down the left is missing as is the row across the top with various controls and options that Wikipedia routinely provides on a Windows box in a desktop web browser. These reappear when you hit the request desktop site option. Which is as you would expect. There’s more to it than that though. On my iPad Pro in landscape mode, with my terrible eyesight the test is quite small, usually not such a bad thing.

Bizarrely, if you hit it a second time, then I suspect it toggles, putting you back into the original state but there is no UI to tell you this or tell you which state you are in. It doesn’t change to say ‘request iPad site’ to reflect the fact that the option will now do the opposite. (If my guess is right.)

After hitting it a second time, the text is a bit larger, which is something I would normally moan about, but this geriatric’s eyesight is now so appalling that the clearer as well as larger text is quite welcome. It’s just better typography too I would think, and it uses a lot more of the page’s horizontal width. In the ‘desktop?’ state the text is flowed in a column of limited width wasting a lot of the x-width completely, for just no reason at all. Wikipedia should, if it is worried about excessive horizontal width of lines of text, switch to using newspaper columns with modern css3 facilities.

[jelv]

How it works:

Mobile site:	http://en.m.wikipedia.org/wiki/Main_Page
Desktop:	http://en.wikipedia.org/wiki/Main_Page

Other sites do similar - I've seen the mobile URL preceded by m. on several.

[Weaver]

So does it speculatively just try a head operation on m.whatever?

[sevenlayermuddle]

@Weaver, I really don’t know, but I’d like to.

Years ago, “mobile devices” were served by WAP which is now, I believe, pretty much obsolete.   Mobile browsers identified themselves as WAP, which  was a markup language of its own.  If I understand right (I probably don’t), it was effectively cut-down version of HTML.  And in those days it was a simple boolean choice... is it WAP, or HTML?   

A basic mobile device, with limited screen resolution and low data rate, would be served WAP content.  But a very advanced (by  contemporary standards) phone that supported full HTML could just access the HTML version, rather than WAP.

Nowadays, I really don’t know how to predict what will happen when I select “desktop site”. Sometimes it does what I want, which is to show the site as it would appear on a desktop PC.   But not always.    From a quick search I don’t think this uncertainty is restricted to Apple, the same choices exist with Google software.

Sorry, nothing helpful there, more questions than answers.

[Weaver]

At work I looked at the spec for WAP which was something very very different from the internet. WML produced very crude and nasty results and no one took any notice of it.

[Ronski]

My interpretation is that sites often present a layout optimised for small screens, if I want to view the full screen site then I request the desk top site, been using the option for years on phones/tablet's.

[sevenlayermuddle]

At work I looked at the spec for WAP which was something very very different from the internet. WML produced very crude and nasty results and no one took any notice of it.

I do remember hacking together some WAP content and putting on my own website as a means to an end to get a Java (J2ME) Applette to run on early handsets (early 2000s), just for fun.    I got it to work too and guess what, can’t remember a darned thing about it.   Filed under “things I have forgotten”.

[Chrysalis]

Those were the good days which wikipedia still does, where mobile sites were optimised for mobiles, and normal sites for desktops.

Now we have this horrible system where web masters optimise one site for both devices so they consider no need for two variants, alhough often its still optimised for mobile and doesnt look so good on desktops (excessive whitespace, large fonts, no pagination etc.).

Basically it can still be done as mobile devices can still be identified its just the way web development has gone to not do it much anymore.

[niemand]

Take a packet capture?

[Weaver]

That’s the right thing, I’ll capture it.

Another question, do any other browsers offer a similar thing?

If there’s no standard, how are web servers supposed to know what to do / what to look out for?

[Weaver]

I used a proxy VPN tool in iOS to try to snoop on the traffic. I couldn’t see much because of stupid TLS and I had not managed to faff about with the appalling (lack of) user interface in the snooping tool regarding digital certs, anyway the snooping on TLS should ‘just work’ and I should not have to do anything myself apart from giving my approval for the require request for an action that is potentially suspicious from a security standpoint.

I could see that it was sticking a .m. in the url, so en.wikipedia vs en.m.wikipedia. Also the UI in iOS is broken, because when I hit the button it actually toggles the state without changing the UI to reflect the fact. When I first went to wikipedia, from its appearance I could tell it was the ‘desktop browser version’. When I then hit ‘request desktop site’ it did the exact opposite, giving me a page with a simplified appearance. Hitting it again toggled the state back.

[Weaver]

This web site understands the ‘request desktop site’ request from iOS Safari:
    https://dict.leo.org/german-english/
It has an attractive ‘simplified’ appearance, which is of course totally unnecessary for the huge iPad Pro especially in landscape and possibly a waste of time for all standard iPads in landscape, not sure about portrait mode, and not sure about iPad mini.

After you try to toggle back, it’s url doesn’t have a .m. and the toggle-back doesn’t work.

[sevenlayermuddle]

it’s actually on my small iPhone screen (a 5c) that I find the ‘mobile optimised’ layout most annoying.   Trouble is of course on such a small screen, it is hard to find the content of interest, or to read the tiny fonts.    That is why pinch and zoom gestures became so useful,  as I can just zoom in to the area of interest.   

And, since I know my way around most websites that I use, I know where to zoom.    Except I don’t, because it often turns out that for mobile optimised sites the layout is nothing like that to which I am accustomed, so I have no idea where to zoom.   Sometimes indeed, the content to which I’d like to zoom is simply not present.

Same applies vice versa of course.   I might stumble upon a website that I find useful on the phone and then revisit on my iPad, or a PC, only to find the layout is totally different, requiring relearning on my part.

[Weaver]

When I worked briefly on web stuff, I made sure that web pages make sense with no css at all, and that each was ‘logical’ if linearised, so that it would give the user a sensible experience when read aloud. Speech synth mode has no such thing as 2d ‘layout’; there’s only disjointed order or sensible order of earlier / later, before / after, and obviously no such thing as ‘above’ and ‘below’ really. I also always made a rule to put the main content right at the start, with absolutely no preceding junk of any sort, and that means no nav list or menus at the start of the page before the content. When it’s being read aloud you just get straight into it. Articles I have read said that some blind users use header navigation, with ‘jump to next header’ > ‘next header’ > ‘next header’ and maybe use a ‘give me a list of headers’ function if available.

The hope is - naive though it very well may be- that this kind of design should have the added benefit of give mobile usage a chance, because then the mobile-targeted css chosen can be fairly minimal, the idea being to forget 2D layout and let the browser make a lot more of the decisions.

It’s a long time since I looked at this stuff and the iOS devices have made things pretty complicated nowadays with a lot of reading required.

[petef]

When mobiles started to support the web it became common for sites to provide two URLs, one each for mobile and desktop. Wikipedia still does this.

A desktop site often tries to redirect to the mobile version if it detects it. The mobile browser may provide an option to spoof its identity so that the web site thinks that it is a desktop.

Best practice nowadays is to have a single URL that is responsive. The layout and style is adapted for a range of window sizes, not just a binary choice between mobile and desktop.

Spoofing has less effect on responsive sites as they are looking at size rather than user-agent.