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?"
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. 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.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
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? ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.