Hacker News Reader

Comment by barrkel | Hacker News Reader

This is somewhat to my annoyance, because I frequently find mobile-friendly pages less friendly on mobile than desktop pages.

Specifically, mobile-friendly typically disables zoom, so that zooming can't be used to choose text size or to scroll through the page at a higher rate. Instead, everything is reduced to a kind of very long ticker-tape, where if you're deep into the page, you need to scroll many, many times to get anywhere.

Alternatively, you get a page broken up into expandable sections, like mobile wikipedia, where it's very tedious to visually scan the page. Wikipedia is one of the best examples of a site where I prefer the desktop page on mobile.

Another issue is limited functionality. Sites with complex forms typically present a hobbled or otherwise limited, basic mobile experience.

View on HN

" mobile-friendly typically disables zoom"

That's just a stupid choice made by (so many) web developers. I checked a sampling of my own sites with Google's tool and they all passed as mobile friendly, but none of them disable zooming. (HN fails, of course.)

I made a bookmarklet for that reason:

    javascript:m=document.querySelector('meta%5Bname=viewport%5D');m.content=m.content.replace(/.*(width=%5B%5E,%5D+).*/,%22$1,maximum-scale=10,minimum-scale=0.1,user-scalable=1%22);

And a second one to disable CSS-based responsiveness:

    javascript:m=document.querySelector('meta%5Bname=viewport%5D');m.content=%22width=1024,maximum-scale=10,minimum-scale=0.1,user-scalable=1%22;

What's a good way to easily call up bookmarklets on mobile? I use short, unique bookmark names. If you know of any better method, I'd love to hear it :)

I really want a "disable zoom disable" button.

HM doesn't disable zoom, it just displays in a teeny tiny font.

This is a well known and hard to fix bug that I've been following. It affects other websites too, typically forums and other pages with large tables and short paragraphs of text.

https://bugzilla.mozilla.org/show_bug.cgi?id=707195

Firefox for Android has the Always Zoom extension, https://addons.mozilla.org/en-US/android/addon/always-zoom/?....

> That's just a stupid choice made by (so many) web developers.

Sometimes it's stupid, sometimes not. Disabling zoom removes the 300ms delay added to most interactions on mobile devices [1]. You can alternatively use fastclick.js [2] or swiftclick.js [3], but that's an extra lib/http request to load.

[1] http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-a...

[2] https://github.com/ftlabs/fastclick

[3] https://github.com/tmwagency/swiftclick

According to your first link, there is no reason to disable zoom. This gives you the best of both worlds:

    <meta name="viewport" content="width=device-width">

It retains zoom and gets rid of the 300ms delay. At least in chrome, so the site says.

FF says this issue is "RESOLVED FIXED", so maybe they implemented it too:

https://bugzilla.mozilla.org/show_bug.cgi?id=941995

I have that meta tag on all my sites and I just tested on Android and iOS: Clicking on links and other controls seem instant. And zoom works. Hurray!

    "<meta name="viewport" content="width=device-width">"

Which is just what I do. Disabling zoom is one of those nonsensical practices that spreads as web "developers" copy code from each other. I suppose there's a use case for it somewhere, but its main purpose is to remove choice and make sites harder to use.

EDIT: Actually I also include the initial-scale as in the comment below.

I have

    		<meta name="viewport" content="width=device-width, initial-scale=1.0">

Huh. I only have the initial-scale entry, and I think that my sites always show up with page width matching device width as a result. Is there something important that the extra width specification does that I'm missing?

ah excellent, went ahead and updated my properties :)

Disabling zoom prevents people with visual acuity issues from browsing your site.

I know only lip-service is paid towards accessibility but zoom shouldn't be able to be disabled except by the user.

I disable zoom to prevent IOS and Android from zooming in when a textbox is focused. How else can I prevent this?

Why do you feel you need to prevent it? As a user I'm pretty sure I'd rather just zoom back out if I want to, or use a browser that didn't do this if it really bothered me. But not having the option to zoom is annoying.

As a user I find having to do this incredibly annoying.

Maybe my phone is just a little zealous with the zooming, but it loves to zoom into the top-left corner of the textarea. The first thing I do uses three pinches' worth to zoom back out, and if I ever have to move the cursor and thus touch into the textarea again, it zooms in again.

As a front-end dev, I'm really curious about this. If you're using a native mobile app, do you expect the UI to zoom in on text inputs as well? Is that a common UI behavior?

I've always been a fan of moving mobile web towards the standards and behaviors of native apps which generally did not require zooming to get tasks done.

Yes, it does happen on some text inputs, it tends to depend on relative size (for example, I recall zoom in landscape but not necessarily in portrait, etc.).

Generally I welcome it, because I can click on the teeeny input field and have it come "closer" to me for editing then get out of the way.

It used to be the case and I think still is for a large case of mobile/tablet devices to just set font size on inputs to 16px.

I think with ios 8 this has changed.

There's a magic font-size that prevents this... I think it was around 19px, but I'm not sure...

FYI, it seems to be 16 http://stackoverflow.com/questions/2989263/disable-auto-zoom...

Make the font of your input larger: http://stackoverflow.com/a/6394497/93995.

For someone who just heard about this change, what Google tool are you referring to?

Presumably https://www.google.com/webmasters/tools/mobile-friendly/

Awesome, thank you!

I disabled zoom on a web property i own because it played havoc with a `position:fixed` top header. When you zoom in, the top header scales up as well and covers the entire content.

This may not be within your power, but you should consider removing the fixed header instead. They take up precious screen real space on already small devices, usually in the name of branding.

I disagree. People needs to have fixed headers that auto hides on scroll down and auto shows when you start scrolling up.

Due to that low screen real estate there is an extreme amount of scrolling down, whenever you need that header to navigate you end up needing to scroll a long way to the top.

Links from the bottom are easily forgotten about when you're half or 80% of the way through an article. Likewise follow you around widgets are a painful annoyance 100% of the time.

> I disagree. People needs to have fixed headers that auto hides on scroll down and auto shows when you start scrolling up.

I still find that very annoying. Sometimes I have to scroll up and find that damn thing covering part of my screen again.

Fortunately I have a bookmarklet that zaps all the position:fixed elements to static :) It works brilliantly in 99.9% of the cases :)

https://gist.github.com/tripzilch/5656025

Same point as ChrisLTD, but less nice. I don't like your position:fixed top header and will likely avoid your site because of it.

> Wikipedia is one of the best examples of a site where I prefer the desktop page on mobile.

I actually have the opposite opinion, that the mobile wikipedia version is much better-designed and intuitive. I prefer the mobile version on desktop.

I absolutely despise the fact that all sections are collapsed on load on mobile. That means "search in page" is broken and Wikipedia without search in page isn't Wikipedia at all.

That only needs an "expand all" button; apparently that's been denied, though: https://phabricator.wikimedia.org/T21924

That is an ancient bug report not related to the current mobile interface ("MobileFrontend"). I think it predates that by a year or two.

You have "search in page" on your mobile browser? (My iPhone doesn't have that!)

Chrome on iOS has in the burger menu "Find in Page". That burger menu scrolls.

It's iPhone's number 1 unknown feature. I've been using computers since I was two and it took me more than a year to find this: just type in the search term in the safari search bar, then scroll down in the autocomplete results (without hitting go or enter). It'll come up after autocomplete and history/bookmark matches - and it's been there since at least iOS 6.

Worst. UX. Ever.

Well I'll be damned.

The other one in a similar vein is pulling the search results down (before typing anything) to get 'Request Desktop Site'. It took a while before I stopped having to pause to remember where that was each time I wanted it.

Before this, when iOS had separate search and URL boxes, typing in the Google search box would offer a prompt to search in the page since ... maybe v3 was it? Hence why that moved to the URL box when the boxes merged. Yes, it sucks.

It does if you use the Chrome browser.

Also you can't view the article's categories. You need desktop view for that.

I'd wager most people agree with you, despite the majority opinion you see on HN. User engagement levels have been higher on every mobile-optimised site I've worked on, when compared to mobile users looking at a desktop version.

This might be because any mobile-optimized site that tracks user engagement levels is more likely to be a good mobile site. People on HN don't say that all mobile sites are bad, just that a lot of bad ones are worse than desktop sites.

What mobile device is wikipedia designed for exactly? Its such a small and spartan design that it seems like the kind of thing you'd see on an early 2000's site when stuff like Palm and Windows Mobile came out.

Why aren't the sections already opened by default? Why aren't there any images? My phone out-performs desktops from just a few years back. I don't need this super-minimalist wikipedia. I just need something that's slightly more responsive because I don't have the horizontal space to handle all of its columns properly.

> Why aren't the sections already opened by default?

If sections are all expanded, one has to scroll an unknown distance to get to the section one is interested in. If sections were to expanded by default, it would probably be better to not make them collapsable at all and instead include in the mobile layout the table of contents found in the desktop layout. However the table of contents uses anchor links which may be less usable in a mobile context (easier to lose your sense of place, a user's desire to not click links that may load a new page for performance and/or bandwidth reasons).

I agree that an "expand all" option would be a useful addition, I didn't follow the link in another post that presumably explains why one isn't being added.

That's what anchor tags with an id tag are for, so it scrolls to the section you want. Which they use on the desktop but, wait for it, you can guess what's coming here, not on the mobile site...

I feel like I've had so many conversations of this form:

User: This doesn't work on your mobile site, why don't you just give me your desktop site because it works better?

Mobile web site dev: We can't do that on mobile because X.

User: But X is already a solved problem on the existing site.

Mobile web site dev: Sorry, but we need to do a mobile site.

How often have you been able to browse the content you want just by the section heading? They are somewhat informative, but I find it much much faster and easier to scroll through the sections skimming the text and images.

Collapsibility means requiring high-precision clicking, instead of low-precision sweeping of the finger.

I don't spend a lot of time looking at Wikipedia on my phone but I'd have to say I do like the collapsed section design. I rarely want to read an article top to bottom and having the collapsed sections makes it very quick to view just the section(s) with the most promising heading.

> a user's desire to not click links that may load a new page for performance and/or bandwidth reasons

I see your point in general, but even the average user browses Wikipedia often enough to realize they're always in-page links. If only by accident, I hit the wrong link often enough :)

Imo the Wikipedia app is much better, and addresses all those points. I think it's been getting the main development time lately, because the previous app was ancient/broken and so they tasked a team with redoing it. But now it's ahead of the mobile site, which was previously ahead. I'm not 100% sure why they actually need the app vs. just a good mobile site though.

Wikipedia mobile is probably ultimately slightly better but uncollapsing through all the sections is dreadful.

I'd really like to be able to collapse sections from the bottom of a section, rather than scrolling upwards frantically trying to find the header so I can re-collapse it.

I really hate how the mobile version removes the ability to view article categories and talk pages.

Sometimes I use the mobile version of Wikipedia just so I can read text that's pleasantly formatted with limited line widths like almost every printed or post-1990's digital text. The wide-as-possible lines, which sometimes make me resort to putting my finger on the screen to keep track of what line I'm on, are a ridiculous legacy.

And don't forget about being unable to zoom into an image when it's been made too small to be able to actually see the details.

Thankfully in andorid's chrome you can actually turn off the zoom lock for all websites in the accessibility settings.

This. I can't believe Twitter actually does that; it's uber painful to browse photos in tweets, which unfortunately I needed to do quite often recently.

I agree with you.

I think it has to do with a kind of counter-purpose development where the people who create the devices are trying to create a good experience on websites and the designers of websites keep moving the goalposts.

Perhaps it's time that web designers are subject (or subject themselves) to a similar set of human interface guidelines that app developers are subject to, for instance.

It's a shame the semantic web hasn't taken off. Yeah, it's neat what you can do with a webpage these days, but 99% of the time, "web design" today sucks to the point where I'm relieved when I end up on an old "black text, white background, underlined blue links" site.

I would love to replace web pages with an RSS reader type program that just displays content and navigation in a legible format.

But with all the fancy stuff that's being added on and on, it seems like the best we're going to get is browsers with a reading "try to unfuck the formatting" button once you've gotten to the content you want.

You should try a text-based browser like Lynx (http://lynx.isc.org/). All CSS and JavaScript is stripped away, leaving the user with unaltered HTML.

In my opinion, all sites should be usable like this. Styles and scripts should merely be enhancements, not requirements.

>In my opinion, all sites should be usable like this. Styles and scripts should merely be enhancements, not requirements.

As much as I agree, many sites are not usable like this :(

And there are aspects of CSS that I do want to keep, like making the navigation lists properly horizontal (and in some cases, nested with hovers). Without CSS, you sometimes have to scroll through several pages of expanded out header/navigation before you find the content.

The problem is that we use the internet for more than just sites, we use it for web applications now too. Making sure the site works without javascript is usually possible, but often much more work. For sites that are presenting information to me, or where I'm interacting in a minimal way, a well defined static interface is preferable. For complex applications, I would definitely prefer a more rich experience than is provided by HTML+CSS and HTTP (although with HTML5 it's not as bad as it used to be).

Definitely true. But I've noticed that web applications are usually not awful design offenders.

An unusable webapp frustrates users and drives them off, but an informational page trying to be some kind of 1920's prediction of a futuristic interactive magazine is annoying at most. I can always figure out how to read the text, so I just put up with the stupid design.

I recently realized how often web developers defending the status quo have internalized a circular reasoning regarding "what the Internet is for". So the Internet is for web applications now, so we need to have all that stupid crap in CSS and dump metric tons of JavaScript on everyone. But if you suggest that maybe we should then drop the content/layout "separation" and make CSS actually nice to work with, the same people will tell you that "web is for documents", so what we have now is good.

I'm beginning to wonder if we shouldn't split the Internet into two - one for cloud apps and another for content - and design the tech stacks accordingly.

I'm fairly sure you're just conflating two separate opinions from many, many different people, and using your personal biases to crap on that conflation, so that you can bolster a fairly weak point.

It's so odd that gopher sounds like a fresh solution to this over-proliferation of design. I wonder if there's potential for a modern version.

I guess the problem is our attention economy. As a designer your job is to hold attention, and this drives design trends so far from competitors that usability suffers.

Although we do see that people love the uniformity of the big social networks. I find Twitter's clean timeline much more helpful than visiting individual websites.

I wonder if we'll continue to see a trend of the web separated into app-level experiences & information silos. I'm thinking there's a big void in the market for something like squarespace meets tumblr.

The uniformity is definitely a big plus on sites like Facebook and Twitter. The rest of the internet feels like Myspace by comparison.

I agree. I switch to the desktop version whenever I can. And if I can't, I tend to avoid the page. But the reason is mostly different: Often I know the desktop version and offering me the mobile one means that I need to relearn where stuff is. I guess, that is different for people who go online on a mobile device, only.

Older versions of iOS had a bug where zoom levels would mess up when device orientation was changed. For a while disabling zoom was a reasonable alternative but it's not justifiable anymore

On the other points I think it's because a lot of companies are still treat their mobile UX as an afterthought, even the ones who wouldn't like to admit it. It's a lot of work to handle all the variables well and few are willing to commit the resources in the right places early enough to implement a good mobile experience without awkward technical workarounds later.

I made my legacy web pages (one almost 20 years old and including an image map) mobile-friendly by google's standards simply by adding a viewport. This had no impact on the usability of the site on a desktop, and only slightly changed the formatting (for the better) on my iPhone. I don't think that what Google is mandating here is a separate, crippled site for mobile devices.

I don't know about apple's offerings, but Chrome on Android has an option in the menu to request desktop version.

Plus, you can force-enable zoom for all sites in the accessibility settings.

I find mobile sites are often tailored towards use cases that are very narrow and specific to what the site operators believe are the reasons a person would visit their site.

This sort of thinking leads to sites highly tailored for mobile that ignores a segment of their audience.

I get instantly annoyed when I go to a site on my desktop browser and see the hamburger icon. Another huge annoyance is site with 5 break points.

I agree with all that.

One example of mobile zoom disabled is Gamasutra.

Not only zoom is disabled, but the fonts are tiny and tiresome to read.

Reply on news.ycombinator.com