I would not prefer to pan - if I resort to it, it's because I have to because the site design is broken.
At that point you better not have disabled zoom too, if you want me to come back to your site.
THIS! This is how I feel exactly! When you load up a site I do it is as well designed as a mobile app. Surely people don't complain about the inability to zoom in their iOS settings app, or in the clocks app. Why would my site be any different?
They have that ability (at least on iOS. Don't know about Android, but I assume it has similar settings). It's under the Accessibility options.
Why don't you allow users the ability to zoom your sites?
It's FAR better to pan and zoom around a working desktop layout than to have a broken responsive layout, so I only disable user-scaling on sites with a specifically targeted mobile experience where I can deliver a better experience by disabling user scaling than leaving it on.
Here's an example where disabling user zoom vastly improves user experience: a tool I built for myself with the purpose of allowing me to test other websites responsively at different widths while using a device with a fixed-width screen.
I.E. this tool lets me test websites at different browser widths while on a phone with a fixed-width.
http://staticresource.com/speedtest.php
Now, if I were to have had user scaling enabled do you think the experience on that site would be better?
Clearly not! But on the other hand, here's a chart with all of the values in hexadecimal plotted in a grid so I can understand and visualize the relationships between values in hexadecimal colour notation (like #1166aa). This page is an illustration, and though I do have some crude responsive styles to help it fit on narrower screens, I intentionally left user-scaling on to make a better user-experience, until/unless I decide to go in and give it a better mobile-specific experience:
http://staticresource.com/misc/grid.html
Now, if I were to have had user scaling enabled do you think the experience on that site would be better?
Clearly not! There's no right or wrong answer for every. single. website. You have to look at how it will be used, who will use it, on which hardware, and what will provide the most value to them. That decision happens case-by-case and there's always a trade-off happening.
I wonder if the group of people that can't manage to browse with user-scaling turned off on their modern, high-end mobile phones are the same who can't seem to load any website posted to HN that uses JavaScript because not everybody uses a browser with JS enabled…
Yes, your examples absolutely need zoom, or they will be totally unusable for a large number of people.
I have close to perfect sight, but big fingers, and even on my 5.5" phone the buttons in the first ones were annoyingly small.
In the second one, the text was annoying small. Again on a 5.5" phone. A lot of people wouldn't be able to read it at all without zoom.
> I wonder if the group of people that can't manage to browse with user-scaling turned off on their modern, high-end mobile phones are the same who can't seem to load any website posted to HN that uses JavaScript because not everybody uses a browser with JS enabled…
No, they are people who far to often run into designers who assumes everyone has perfect eye-sight and dainty little fingers and so thinks it's ok to disable zoom.
The only time it is acceptable to disable zoom is if you provide your own, context-aware zooming mechanism and make very, very sure it does a better job than the generic browser zoom.
As an aside, the Android I used to test this allowed me to turn on Force Zoom, and that allowed me to use the site better.
The second site (grid.html) can appear very small. I think you intended to say it should be zoomable, as I was able to zoom in and out on that one.
My point is, even when you yourself cannot conceive of a reason a user would like to zoom the site, trust me, there probably is one. In another reply, you mentioned the 300ms delay that turning on zoom control introduces. I hadn't thought of that before, and that is a good point for disabling zoom control. Maybe Apple can follow Google's lead, and give their users the option to override it. That would allow the majority of your users the faster touch-responsiveness that you're trying to give them, while still letting the rest of us have the control we'd like over our browsers.
You appear to have missed my entire point, which is that if I try to zoom, there is no reason to prevent me from doing so, as the fact that I have tried to zoom is proof your attempt at design to meet my needs failed, and zoom might make it better, and certainly won't make it worse, while denying me will make me annoyed or angry and potentially mean I can't use your site.
I can tell you with 100% certainty that you are unable to find a font-size, for example, that will satisfy everyone, as e.g. what is comfortable for me is too small to be readable for a lot of people.
Arguably, disabling zoom might even violate disabilities protections in some jurisdictions. E.g. in the UK you are required to take reasonable steps to make your site available to people with disabilities. Disabling zoom does the opposite, by making it harder to access your site for weak sighted people.
> Surely people don't complain about the inability to zoom in their iOS settings app, or in the clocks app. Why would my site be any different?
Why do you think people won't complain if they can't zoom? The first screen magnifying application I saw was ca. 1986. And that was on a home computer where font sizes etc. could be freely adjusted up to very large sizes. People still wanted the ability to zoom to make their usage easier.
I don't know about iOS, but on Android you can turn on "magnification gestures" and zoom any app everywhere by triple-tapping the screen. At least in my version.
But for e.g. the browser, assuming you've done your job properly, then zooming in a way that allows re-layout would save a lot of weak-sighted people a lot of panning that they are forced to do if they use the built in magnification since the latter doesn't have any knowledge of the page structure.
What? There's plenty of reasons to zoom even if the design is perfect.
The reasons I can think you would desire to zoom in on a legible, functional, accessible website would be for curiosity, or to see a detail closer and admire the layout. There are details like this in apps all the time and I screenshot it and zoom in on my screenshot. Those are interests (I want to see that closer) that are separate concerns from me using the app.
I'm curious what reasons you might give that would interrupt or prevent a person from using the site as intended because of their desire to zoom in without screenshotting.
Are you able to articulate 5
or more of those plentiful reasons?
1. I'm further away from the screen, because my screen is large.
2. I'm further away from the screen, because I am showing a website to a friend or colleague.
3. I'm displaying the site on a projector, and people at the back of the room say they can't see.
4. I'm viewing a website on my colleague's high-dpi display, which she uses at native resolution.
5. I'm viewing a website on my phone while being driven somewhere, and the ride's a bit bumpy so I don't want the text too small.
6. I have a comparatively low-end phone, that most people don't seem to test for; sometimes the live suggestion dropdown for a text box is obscured by my on-screen keyboard.
7. I have a comparatively high-end phone, and I'm not moving around, and I'd like to have more of the article on my screen.
8. I have a comparatively high-end phone, with a high-dpi display, and the page I'm reading just seems to have rendered everything quite small.
9. The website designer has opted for a skinny font I'm having trouble reading.
10. The website designer has decided a feature is unimportant and should be visually unimportant (maybe a link to some terms and conditions, or an EULA or something like that) but I want to be the judge of that.
11. My eyes are tired.
12. My eyes are fine, but I've had a few drinks and things aren't quite as crisp as they usually are.
TLDR: if a user in a test group says "I'm having trouble reading that text" would you say "No you're not"? Of course you wouldn't, it would be ridiculous to do that, the user has first-hand perfectly accurate information you don't have access to. And yet, when a user expresses that they're having trouble reading the text by zooming, and you disable zooming, that's exactly what you're doing.
It's possible to avoid a lot of these pitfalls with better design.
1. User far from big screen: You can zoom much faster and easier with your forearm than a pinch gesture
2. User far from screen, unusual viewing angle: how much time to you spend browsing at awkward angles versus dead-on? This seems like a small consideration that would affect some types of sites more than others. I doubt a banking website would feel the same way about this as a social media website project for example…
3. Classroom projection is decidedly not the use-case nearly any mobile website is designed to work under, unless the website is cloud-based projection software, but that's a specialty thing in itself.
4. This is why we define font sizes in PT and no PX, this isn't a mobile or responsive issue, but rather a design choice in CSS
5. Does your mobile browser include a 'reader' mode that isolates text content and provides the ability to make it more legible in these conditions?
6. Ah yes, and what's even more surprising for people is how differently Mobile Safari calculates screen dimensions between iPhone and iPad! Then the difference between how iOS and Android handle keyboards, and then the difference at how those OS's handle browser verus web-app mode. There is currently no good solution to keyboard control.
Anecdotally, we ran into an issue on Friday where an email field was autofocused and the keyboard was popping up and obscuring what you were entering. I didn't make it that way, but I did provide the solution: remove autofocus for touchscreen users: http://staticresource.com/autofocuser.html This is a way that we can have one feature for desktop users where it speeds up entry, but target mobile users separately and provide a better targeted experience for them.
<script>
// Block autofocus for touchscreen users
onload = function(){
if(('ontouchstart' in window)||(navigator.msMaxTouchPoints>0)){
var field = document.querySelectorAll('[autofocus]');
for(var i=0;i<field.length;i++) {
field[i].blur();
}
}
}
</script>
8. That's usually a problem with the difference between 'pixels' on your screen and CSS 'px' units. Defining layout in other units in CSS can avoid this problem on HiDPI displays.
9. Testing, testing, testing. I make sure to supply well-made fonts, I use a special set of CSS rules that control the rendering of text display so that the same font renders the same thickness in all browser's and OSes, and with those differences out of the way I can move forward using only weights that work (usually no lower than 400 weight unless the size being displayed is very large) and be sure that they are legible everywhere. Here's my snippet (and honestly, this cuts out SO many other common text rendering bugs):
*,
*:before,
*:after {
text-rendering: optimizeLegibility;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
font-kerning: auto;
}
11. Turn your brightness down, you only have one set of eyeballs.
12. I'm not sure panning and zooming will help you feel better when the room is spinning so fast you can't read.
I'm not dismissing these reasons, I believe many of them are small or fleeting and to change an entire project for one of these whims seems short-sighted. Other reasons listed here are 100% valid, and workaround can be found without enabling zooming.
For projects where zooming makes sense I wouldn't have it any other way, but I don't see a compelling case listed here to always have zoom enabled.
What? Isn't px a fixed multiple of pt, with an actual size that varies by platform?
CSS 3 defines pixels that way (1/96 inch, pt is 1/72 inch), but the previous definition was rather different, and had no fixed relation to either inches or ems.
But I thought the change in CSS 3 was because pretty much every actual implementation of CSS 2.1 had taken the definition, chucked it out the window, and used 1/96 inch anyway. So, I don't see how any problems could arise in practice from using px instead of pt.
Both the reasons looking for zoom, and your reasons for not providing it seem reasonable. Is there some technical barrier for not enabling zoom?
Zoom is a first-class gesture on mobile, it is the second one after scrolling that you always expect to be there. On a desktop, you generally have more desktop than you need for a window, so it is possible to resize the window to adjust the size of the viewport. Responsive sites work nicely in the case. On mobile, there is no "window" and the device's dimensions themselves are the viewport. You can reorient the device to enable changing the width, but without zoom, you are taking away any ability to change the viewport.
Maybe zoom isn't a critical feature, but it is part of how the devices work. As a result, it is an expected interaction for those on mobile. Have you ever used a piece of desktop software where you couldn't resize the window - it drives you crazy. Ignoring expected behavior is contrary to good usability.
“Safari on iOS displays webpages at a scale that works for most web content originally designed for the desktop. If these default settings don’t work for your webpages, it is highly recommended that you change the settings by configuring the viewport. You especially need to configure the viewport if you are designing webpages specifically for iOS.”
https://developer.apple.com/library/mac/documentation/AppleA...
Zooming is enabled by default on Mobile Safari as a feature to help mobile users navigate sites not designed for mobile.
Apple intentionally added many different ways to control the viewport, including the ability to disable zoom.
“Setting the viewport width should be the first task when designing web applications for iOS to avoid the user zooming in before using your application.”
So it very much sounds like Apple has added this functionality as a usability feature to help mobile users navigate sites designed without regard to their specific hardware, Apply strongly recommends setting the viewport specifically for the pages you design with iOS in mind. Also note, when looking through Apple's documentation that they refer to the gesture as 'zooming' and the feature in Mobile Safari as 'user scaling.
I get the design angle, and I don't disagree that setting the correct viewport is a good idea, but you shouldn't assume that good design and correctly setting the viewport will work for everybody. The fact remains that the zoom gesture is critical on mobile, and disabling it does not help anybody use your site.
On responsive sites, the idea behind them is that the site does its best guess of being responsive based on the size of the viewport. However, sometimes it doesn't work out, sometimes the websites behavior isn't as intended, sometimes the designer didn't test with my exact device, size, eyesight, etc. It is nice in those cases that I can make up for the site not being designed for my mobile by using the zoom feature as intended.
No that's the opposite of what I'm saying. Apple has created a usability feature called 'User Scaling' and enabled it by default for usability purposes. Apple also added the <meta> tags that control the viewport, including disabling User Scaling, and strongly urges designers & developers to do two things:
1) Design your site with iOS users and hardware in mind
2) Use the correct viewport tag that gives the best experience
> On responsive sites, the idea behind them is that the site does its best guess of being responsive based on the size of the viewport.
I'm not sure what you're trying to say here. There's not much guessing going on here, you are either able to define the viewport, or it will render the page at the widths specified in the page styles. If you have defined the viewport there is no guessing involved and it will render the same way from device to device.
> sometimes the websites behavior isn't as intended, sometimes the designer didn't test with my exact device, size, eyesight, etc.
Chances are I didn't test with your exact device, but when I style things I have a set of rules and tools that help ensure that the same content renders the same way anywhere. If I tested only against released hardware then my sites wouldn't be future-proof. I design my stuff to work on all screen sizes smaller and larger than would be in use today so it not only shows up the same everywhere, but will continue to show up the same on devices released years from today.
I also regularly test on quirky hardware like PS Vita, and anything else with a browser that I can get my hands on just to make sure there aren't any weird bugs or edge cases.
http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_n...
Here's a real-world case study: a friend had a sign up funnel and was tracking 900 different mobile devices on his site. On my main gig we have 1,300+ different devices a month! I put my responsive and mobile polish on top of his existing site and we moved the needle on signups 2% since then, and that change has lasted. Clearly, whatever I'm doing it making it easier for mobile users to get in the door with their dollars, and I have the numbers to vouch for that!
The flaw in this argument is that you are measuring across the total population, and totally ignoring that while your overall changes may help some proportion, some parts of it may actively prevent others from using the site at all.
Great for you if all you care about is the money. Not so great if you want to e.g. ensure people with disabilities have a good experience too.
I got a really good laugh at this one, a cursory glance of user-generated content online shows tons of people not only know how to screenshot their devices, but are quite adept at figuring out how to share those screenshots with each other and the world.
If your audience is just those that can screenshot, and you are willing to block out others, go ahead. But don't call yourself a designer anymore.
2. see above
3. see above
4. see above
5. see above
1. I'm old enough to need reading glasses. 2. etc.
(Yes, people do lend their devices.)
If you're not providing a better experience than a fully working desktop site, then you shouldn't attempt responsive design at all and let mobile users use a non-targeted but working site. I only shut of user-scaling on sites where the targeted mobile experience is better than a scaled fully-working desktop layout.
If you e.g. can't read it because the text is too small, the design is not perfect (for that user at that time), and zoom should not be disabled.
My point was that the moment a user is trying to zoom, for whatever reason, they have already decided that the design is not perfect for them in the present circumstances on the device they're currently using.
And so the only thing disabling zoom is going to achieve is annoying the user by artificially preventing them from trying to improve a situation they've already deemed is suboptimal.