7 Deadly Sins of Mobile Websites
10kloc.wordpress.com
10kloc.wordpress.com
- Redirects to home page
- Page not found on mobile site
- Mobile version has reduced features that were the primary reason for visiting the page
- Redirecting to new mobile-specific URLs that make sharing with desktop users difficult (or impossible!)
- No way to not get the mobile version (no link, or doesn't remember preference).
If auto-redirect actually suited the visitor's needs, then in many cases it would be fine. Instead, I find that many seem to be implemented in the most naive way -- probably one of those circumstances where a novice developer said to the site owner, "automatically showing the mobile site to mobile visitors is EASY!".
The desktop site was created first, and the mobile site was added much later. Often, the two sites aren't even on the same server(s) because the mobile site was contracted out to a different agency that uses an incompatible technology. My most recent freelance gig was to unify two websites run by the same organization. One was written in PHP 4.4 and the other was written in ASP.NET.
The only thing they share is the database, and even that might be handled by an export+import batch job (.vbs anyone?) rather than actually sharing the same database, because none of the ORMs are compatible with one another.
So what happens is that whoever maintains the desktop website has no idea how the mobile website works, and vice versa. If you pay them another grand or two, they might be able to figure out which URLs in one website correspond to which URLs in the other website, but the client probably cut that from the spec. Hence http://xkcd.com/869/
What I don't get is how hard it would be for someone to say "Hmm, maybe redirecting to the home page is actually a pretty awful idea. If that's the best we can do, maybe we should only auto-redirect pages where we actually know the equivalent (static pages and such) until we can afford a better solution."
As a side note, I've just realized it's things like this that are why I can't stand front-ends that are built on or tightly integrated with the same ORM the backend uses.
Is the data you've seen internal Google data, or is any of it available to us non-Googlers? Would be interesting to know the ratio of usage, how it varies by time of day, by activity, etc.
From personal experience, some of my friends use their smartphones for all their browsing, even when they are at home. That could be one of the reasons the WiFi stats are so high.
I'm having a hard time finding an example -- IIRC, some CBS news property used to do it -- perhaps they fixed it.
Slate/Salon tend to put something like 100 words on a page, and NYT also have way too few words on a page. New York Magazine and the New Yorker tend to strike a decent balance, as I seem to recall.
This one always irks me. Anyone have A/B testing to back up conversions on this?
Even if it's annoying but leads to more engagement, than I'd continue to redirect people to the app.
These days, three questions are most common: 1. Visit the Full Site 2. Visit the Mobile Site 3. Download the App
"Hmm... which one should I pick... I'm not sure..."
Besides, it is plain annoying to see this every single time.
2) When I want to share a link, I don't want to share the mobile version. Please have a "share link" button. Youtube does this right with their youtu.be links.
It stems from:
- Developers viewing their sites only from fast WiFi connections
- Poor 3rd party ad & tracking service integrations
It goes like this:
1. Tap link for article. Text loads, user begins reading.
2. [CSS file loads with typography styles --> TEXT JUMPS TO NEW POSITION]
3. User adjusts position of eyes, or possibly scrolls to find location in text to resume reading
4. [CSS file loads with some layout styles -- TEXT JUMPS TO NEW POSITION]
5. ... possibly 2-4 repeated several times for various stylesheets (no compilation)
6. User scrolls to resume reading after being interrupted again.
7. [JS resource loads for ad. Creates banner box -- TEXT JUMPS TO NEW POSITION].
8. Again user finds reading position to resume
9. [3p CSS arrives to style the ad -- TEXT JUMPS TO NEW POSITION]
10. User begrudgingly finds position, wondering if this article is worth the trouble.
11. (steps 7-10 repeated for a few more add boxes / other nuisances)
...
For my own personal site[1] I tried my best to maximize the viewing area while keeping some padding of the text from the edge of the screen for "comfort" and a small pinned navbar for usability.
Idk if that is best practice though. I want to see one so that I can follow those for a few projects I'm currently making.
Also: I want to see a millisecond by millisecond breakdown of what happens when for a typical mobile page load.
[1]: Shameless plug, but I don't really design mobile websites that also acts as a desktop one: https://shuhaowu.com
Narrow column layout are awesome: You can zoom in to full width, resulting in big fonts for your screen. Most website's fonts are too small by default to be read on an iPad. It gets worse when I'm on a subway or reading while walking home (90% of my HN reading time): Font to small, can't zoom, = leave the website.
So rule #8: Let people use the pinch-to-zoom on your mobile website (Ironically, the OP itself has pinch-to-zoom disabled).
Which leads me to a more important point: Why do "responsive" js libraries sometimes disable pinch-to-zoom?
Truly, the bandwidth conversation is relevant mostly to non-motivated or new users. The abandonment issues are real, don't get me wrong, but abandonment really occurs if the user is marginally motivated. If I'm trying to buy something I want or if I'm trying to register for a service I truly want to use, I will wait.
Point in case, I waited not seconds, but weeks, for my Mailbox account.