Ask Slashdot: Why Do Mobile Versions of Websites Suck?

First time accepted submitter Kelbear writes "As user traffic over mobile devices grows in leaps and bounds, it's surprising to me as a layman that so many companies still have crippled and broken mobile pages in late 2013. There must be justifiable reasons for this, so: Fellow Slashdotters, can you please share the obstacles you've seen in your own companies that have delayed or defeated efforts to develop competent mobile sites? Are the issues in obtaining or maintaining compatibility driven by platform owners like Apple and Google?"

Re: Slashdot being a prime example of bad

[Anonymous Coward]

I actually prefer, and mostly read Slashdot via mobile... either on my phone or tablet. The same goes for news sites and "blog type" sites.. less clutter gets me right to the content. That being said, most mobile sites downright suck. I refuse to bank, shop, or do any research via mobile web. I just isn't conducive to getting things done. So yes, I agree with the premise, but not this particular example.

Re:Answer your own question, Slashdot!

[Threni]

This. I keep getting asked to try it out and fill in some sort of bland, pointless questionnaire that doesn't let me express what I feel about it.

Horrible ajaxy stuff so you have no idea if it's doing something or died. Would help if there were some sort of standard `i'm doing something` animation or indication across all sites, but no. Flashy rather than basic functionality.

Mobile sites often remove stuff that would work perfectly well on a mobile site. Mobile doesn't have to mean retarded. Switching from mobile to full and vice versa should keep me on the same page in the same session, not dump me at the front page. Stop using hover on your sites - you can't hover with most mobile devices and even on a desktop it's tedious to click on something only to observe that it was a hover and you were supposed to wait for some stupid animation to finish expanding to show you a choice you were supposed to have selected one of. Stop being clever and get the basic functionality right.

Fundamentally...

[msauve]

If you consider that it's all about communicating information, smaller screens mean lower bandwidth.

Especially in a world where people seem to prefer passive information (i.e. "show me," instead of "teach me"), why would it be expected that a smaller screen with lower bandwidth wouldn't be worse?

Responsive Web Design

[Jason Levine]

Thanks to CSS3's media queries, no site should need a "mobile version." You design one site and have it modify itself based on the browser's size. A good example of this is the Boston Globe's site [bostonglobe.com]. Go to the site in Chrome or FireFox (not IE) in a large, but not maximized browser. Now slowly resize the browser, making it smaller and smaller. As you do, the site will reconfigure itself from full-fledged desktop site to small-screen mobile site (with quite a few steps in between).

The benefit of this is, of course, that you don't need to maintain two or three different sites. You maintain one site and modify it to suit different sized browsers. Compare this to a mobile site which needs to redirect users to a different URL and often needs a completely separate development effort.

Wrong question

[foobar bazbot]

When high-end mobiles had EDGE and QVGA, and many people were stuck with GPRS and 160px screens, mobile sites were absolutely necessary. But with today's phones, the question is not why mobile sites suck, but why we need mobile sites at all.

Over the past decade, the actual functionality of websites, aside from streaming video (which is huge, to be sure) has barely changed at all. Over the same decade, mobile hardware and software have advanced to match the low-end desktops of 2003. If video streaming is handled by separate apps (as it mostly is), there's little reason one website shouldn't work for both desktop and mobile use.

I only really see four differences between today's 1136x640 or 1280x720 phone and yesterday's 1024x768 desktop, as far as web browsing goes:

• mouse motion (without a button state change) - generally, depending on either mouseover or drag is bad practice (it fails not only with touchscreens, but also with software for people with disabilities), but of course they can also be very convenient (provided you actually have a mouse). The right solution is for websites to provide the same functionality another way (e.g. m.xkcd.com [xkcd.com]'s alt-text show/hide link -- note that while this is a mobile site, I and many others use it on desktops; it's a good example of one site working well for both.) Sadly we can't expect such accommodation, so the next alternative is to patch over it in the browser -- the N900's browser does this tolerably well (only permits drags, but most mouse-over stuff works ok by dragging in from an inactive area), but most other mobile browsers don't even try, and I really can't understand why.
• right click - it's mostly mapped to long-touch and works as you'd expect in a lot of mobile browsers. But in some it doesn't work at all. If one does a good fix for allowing separate position/button control, it's trivial to add support for right mouse button.
• screen size - there's a factor of 5 between a 15-20" display and a 3-4" display, so unless you use your phone at one-fifth the distance you use your monitor, you can fit less readable text on it despite the comparable or better number of pixels. But you can always move the phone temporarily closer to see tiny text, and pinch-zooming is so easy on (most) mobiles, it's a mostly solved problem for most sites. For the sites where this doesn't work well, maybe a mobile site really is the answer.
• fat-finger syndrome - UI elements that are to be clicked have to be big. Since one clicks hyperlinks, this means hyperlinks have to be big. But again, zoom fixes this well enough.

It seems like a tiny fraction of the effort spent on mobile sites (making a few changes to mobile browsers) could permit many existing sites to work just fine on both mobiles and desktops, and an additional fraction (making changes to those websites) would fix almost all the remaining ones. Fiddling with mouseover emulation and zooming clearly costs the user time vs. a good mobile-only site, but it's not at all clear to me that that's really true vs. an average mobile site (which, on average, is what you'll get) or that if it is, that the cost in wasted user time is less than the cost in developer time expended on creating and maintaining a mobile site.

Of course, this is all built on the assumption that a website that does A, B, and C today should be no more complicated and require no more resources than a website doing A, B, and C in 2003. While this may appear reasonable enough, Wirth's law says it's too much to expect. But a guy can dream, no?

The normal ./ site also has an annoying issue

[Anonymous Coward]

Why is it that when I click the BACK button on the browser I get to the top of the previous slashdot page, and not back to the (vertical) point I originally departed from?

Re:mobile is for a quick check on the go

[jc42]

Get a device with a big enough screen, and the internet isn't painful anymore. It's that simple.

Heh. That doesn't always help. A lot of the Internet is painful by design. They make it that way with malice aforethought.

A trivial example in the window I'm typing in right now: There's a horizontal scroll bar at the bottom of this /. window. OK, it has a width= attribute that shouldn't be there that's forcing it to a fixed width, right? Nope. I grabbed one of the resize handles on the window's border, and resized it a few times. No matter what size I made it on my (rather large) screen, the /. window is sized to be slightly wider than that. It dynamically detects the size, and forces the content to be wider.

This is fairly common, and the solution is trivial: Remove all the width= and other size attributes. There's nothing in this /. page that requires such things, and without them, the browser will "flow" the text so that everything fits. But /., like so many sites, tries doing something "clever" (i.e., dumb) with the sizes, and as a result, there's nothing I can do to make it fit.

This is known in legal circles as "with malice aforethought". The developers understand the problem quite well. If they didn't, they wouldn't be smart enough to use HTML in the first place. So they must be doing it intentionally.

And I've seen why this can happen. I've worked on a number of projects that needed a web interface. On many of them, I've gotten explicit orders that the pages must be sized to specific width, so they'll fit in the window the boss wants to use on his desktop. If the boss's desired size isn't the default, it won't be accepted. This sort of idiocy is quite common, and it's not easy to fight.

Actually, I have "fixed" it on a number of projects. These were cases where we had a good reason to have all pages delivered by a CGI program that parses the client's request, runs appropriate data-fetching and -munging subprocesses, and formats the results in HTML. I sneak in a little check of the HTTP_USER_AGENT, and if it's IE (which is the only browser that such bosses know exists), my code generates the required width= attributes; else it produces no sizing instructions at all. The results usually work fine on anything from a dumb "smartphone" to a humongous window on a humongous display. Or a small browser window on your screen, whatever it is. And it meets the boss's requirement for a fixed width on his screen.

So far, I haven't been caught performing such treachery by any of my bosses, but it's probably only a matter of time. They often believe that their web sites need only work on screens exactly like the one on their desk, and they explicitly order their developers to do it that way, or else.

This is just one of the many reasons for the problem we're discussing. It's yet another example of the old one about not attributing something to malice which may be explained by stupidity. (Quick, without googling it, which famous writer is that usually attributed to? ;-)

Re:Answer your own question, Slashdot!

[Jiro]

That motherfucking website has, if you examine the source, Javascript at the bottom which loads more Javascript from google-analytics. There's a comment of "yes, I know...wanna fight about it?" which pretty much indicates that the site creator knows he's being a motherfucking hypocrite by putting that on a website whose supposed point is that that sort of thing is a bad idea.

(Of course I put google-analytics as 127.0.0.1 in /etc/hosts, since I see no reason to ever want to load anything from there, even if for some reason I have to turn ad blocking off.)