Agree with all except the different content point. Depending on your site you may wish to provide slightly different content or functionality if the user is on a mobile device.
Yep, consider a site for a restaurant. Information I want front and center on mobile? Hours, address, telephone number. No I'm not looking for your latest blog post, or to learn what you're all about, or even your menu unless I'm sure you're open and close by; I'm in my car, hungry, and probably got to your site off yelp anyways.
Eighth deadly sin: over pagination. Some particularly bad sites will break content into a ridiculous number of pages (eg page 1/12) with around a paragraph of text on each.
I'm having a hard time finding an example -- IIRC, some CBS news property used to do it -- perhaps they fixed it.
On the other hand, I often find that my reading position is reset, when I open Safari on my iPad, so the chance of me finishing a long-form article in Safari is not that great.
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.
Another sin: Not letting me up/down scale the text how I like with my browser. Depending on the environment, time and other circumstances I like or need different font sizes. Leave the choice to me.
> Ah, the joy of having a huge box in front of my face telling me how good the App is and I should get it from the App Store. The irony: already have the steaming pile of sht app installed and much rather use the website. How about I just leave instead?*
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.
The more questions you'll ask your users, the more confusion you will cause. In the book, "Don't Make Me Think", the author makes an excellent point: "When you're creating a site, your job is to get rid of the question marks."
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.
How about the site that advertises the mobile app, then when you say "no", it takes you to the front page instead of the link you were following anyway.
By far the biggest mobile-website sin for me is that a high percentage of sites that auto-redirect to a mobile version actually don't work right at all:
- 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!".
This is actually somewhat understandable (even if still unforgivable) if you think about how typical non-technical businesses get their mobile websites done.
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.
This is a nice article, but I disagree with the statement that "most of the time", users are accessing the mobile web via cellular (not WiFi) networks. The data that I have seen on this is that the vast majority of mobile web usage is via WiFi - more than 70-80% of mobile pageloads occur on WiFi networks. (Context: I run the mobile web performance team at Google, part of Chrome.) This is in part because web usage is higher on tablets than on phones, but even on phones we see WiFi being the most commonly used network by far. This is not to say that cellular performance isn't important, but this skew might be somewhat surprising to people working in this area.
Matt, this is fascinating. Not for tablets - there's been plenty of data suggesting people primarily use their (say) iPads in the home. But for smartphones, wifi being predominant is not what I would have expected.
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.
Matt,
Thanks for your feedback, much appreciated - I'm surprised at this myself and the article will be updated soon.
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.
1) How about when I click on a link and you redirect me to the mobile site, you redirect me to that article, not some random page that I assume is the homepage. Looking at you Huffington Post.
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.
My favorite thing about this article is that it doesn't harp and preach and bang and shove the bandwidth conversation down your throat.
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.
My biggest gripe with mobile sites is what I call "layout jumping". It happens when CSS and JavaScript resources arrive slowly (as of course they do over many mobile connections).
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)
I wonder if anyone has posted any resources on how to design proper mobile pages?
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?
If you're interested in committing all of these sins, just use onswipe to build your mobile site. I've never known an onswipe site that I didn't immediately want to revert to the desktop site. It is by far the worst mobile experience I know.
26 comments
[ 1.3 ms ] story [ 66.4 ms ] threadI'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.
- 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.
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.
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.
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?