Viewing the web through a pocket-sized screen is a different experience than viewing it on a massive desktop screen. It deserves an experience optimized around it. Unfortunately, mobile webpages often come up short, especially when compared to their desktop counterparts. From the very beginning, I designed AfterPad specifically for mobile - The iPhone was the target size, and the iPad and computer versions were modifications to the iPhone UI.
This comes with a number of weaknesses - I'd really like to have a few more tabs on the top of the site - but it also comes with strengths. When iOS is your primary platform, you can throw away a lot of legacy "best practices", AND take advantage of some iOS-exclusive features.
Throughout the process of building AfterPad, I've found some handy tricks to make the site feel a lot more "at home" on iOS. I am not, by any means, a master web designer, but I figured I should share some of the techniques I use.
This is not a complete guide to web design, or even a complete guide to mobile web design. But it does have a few cutting-edge tricks that a lot of web designers might not be aware of.
Set your Viewport equal to device-width
This is a basic step - definitely not a cutting-edge trick - but any guide to making a mobile-friendly site wouldn't be complete without it.
Mobile Safari was designed for an era of desktop websites. Because mobile versions of websites didn't exist when the iPhone was released, Apple employed a clever trick to make standard websites look good. By default, Mobile Safari creates a fake screen that's 1024 pixels wide, renders your page inside this fake screen, and allows people to zoom in to see the full content.
This is how the iPhone displays the "full Internet" - it emulates the size of a traditional computer monitor. This makes a ton of sense for sites that are designed assuming most people's monitors are 1024 pixels wide. But for mobile themes, you need to address the real width of the iPhone screen.
The following code, in the head section of your HTML, turns off Safari's fake desktop rendering:
<meta name="viewport" content="width=device-width">
If your website is designed to emulate an app-like experience, or if it uses fixed-position elements, you can go further than this by preventing users from zooming your page.
To prevent zooming, use the following meta code, instead of the above:
<meta name="viewport" content="width-device-width, user-scalable=no">
If you decide to prevent visitors from zooming in on your site, you need to be extra careful to make your site's text readable, especially for people with vision problems. You should definitely implement the next trick:
Take Advantage of Dynamic Type
This is a new trick. Very few websites take advantage of it, which is a shame, because it's one of the most important features to ever come to Mobile Safari.
With iOS 8, iOS introduced Dynamic Type, a system-wide way for users to control text size. Not only does this provide a great way for users to personalize their reading experience, but it also acts as an accessibility control, allowing far larger text sizes for users with vision problems.
Safari traditionally didn't need this, because it was possible for users to zoom-in and magnify text they wanted to read. However, many mobile websites opt to block zooming, making for a more native-feeling experience, but one that can be difficult to read for people with vision problems.
If your mobile site blocks zooming, you should implement dynamic type. You may think you know best about text sizing, but for people with accessibility concerns, you probably don't.
To implement dynamic type, add the following rule to your CSS. It can be used site-wide, specifically for paragraph elements, or anywhere in between. This example assigns it site-wide to the body element:
Because this code must be assigned to the "font" shorthand property, it changes both the font-size AND font-family properties. Unless you want to use Apple's San Francisco font on your website, you need to add the font-family rule below the "font" rule, which overrides San Francisco with the font of your choice.
Keep in mind, if you've assigned dynamic type to a parent element, you can override it for a child element by assigning a font-size to the child element. If you use em units to define the size of child elements, they'll even scale according to the user's dynamic type setting!
Consider Using iOS-Native Fonts
I know that bundling "premium" web-fonts is popular, but they come with downsides. They take time to download. During that time, you can either display nothing - your text is blank for a second or two, then blinks in all at once - or you can display a fallback font - your text shows up using a native font, then switches awkwardly to your fancy one after the fancy one finishes downloading.
The good news is, you might not need to do either of these. The font situation on iOS is better than you think. Apple bundles several excellent fonts with iOS, and you can use them all on your website with zero performance penalty and zero license fee.
iOSFonts.com keeps track of every font available on iOS, and let's you see which fonts are supported by each version. If you happen to like any of these fonts, you don't have to any special tricks to use them: simply add the font name to your "font-family" property.
font-family: "Avenir Next", "GillSans-Light", sans-serif;
Note: if you've taken advantage of the dynamic-type feature mentioned above, you'll need to place your font-family rule below your dynamic type font rule.
Prevent Automatic Text Resizing
Mobile Safari likes to resize fonts. In the early days of iPhone web browsing, websites weren't optimized for small screens. The iPhone would show you a shrunken-down version of the desktop site, and you'd zoom-in on the part you wanted to read. To make it easier to see what you're zooming-in on, Safari would magnify the text in paragraph blocks, often making the body of an article larger than its heading.
If you're hand-tuning your site for mobile, your text should already be optimized for reading on a mobile device, and you might not even allow zooming.
To prevent Safari from automatically resizing text, add the following rule to your CSS:
Note: this rule is unrelated to whether users are allowed to zoom, and has nothing to do with dynamic type. If you allow zooming, visitors can still enlarge text by zooming in. If you've adopted iOS dynamic type, font size will still be influence by the global dynamic type iOS setting.
Use 16px font-size for Text Boxes
This is a lesser-known requirement. If your website uses a text box where visitors input text - for a search field, a forum post composition field, anything like that - set the font-size of those fields to 16px.
If you don't do this, Safari zooms in every time your visitor taps on the text field - it really wants text-input fields to be 16px, and it'll magnify things until it gets its wish. It sometimes does this even with zooming turned off, and the default viewport set to device-width.
Use the following code to make Safari stop zooming-in when visitors select a text box:
This is one of those little things that makes a big difference.
Use max-width and width Properties for Images
This is one of the quickest and most effective ways to make a mobile-optimized version of your site. It's most useful on blogs. On mobile version of most blogs, embedded pictures look best when they're the full width of the iPhone's display, possibly with a small margin. On desktops, with much wider displays, these pictures would look far too big.
There's an easy solution: instead of using the width property to control the width of your images, use max-width. Then set the width to 100%. Then, if you want to center the images, set the left and right margins to auto and the display mode to block.
The above code will make every image the full width of its container, up to a maximum of 640px wide. Any wider than that, and the image will be centered, with margins filling the difference. These are the exact values I use on my site. The same trick can be used for any element - quote blocks, videos, paragraphs of text. This is an essential tool for making a responsive mobile site.
Customize the Tap Highlight Color
You might be able to get away with customizing iOS' standard tap highlighting instead. The following code changes color of the box that appears when you long-press a link to red:
Note that the tap highlight appears over the link, meaning it must be slightly transparent, or it obscures the link.
Optimize for Safari's Reader View
Safari Reader View is a tool that allows website visitors to see just the content of an article, with none of the cruft. You might not like the idea of people stripping out all the sidebars and navigation tabs (and ads) from your site and just viewing the text, but the fact of the matter is, people do it. And if your site looks broken in this view, you're the one who looks bad. The good news is, the tricks here will likely increase your search position in Google, and should also make your site easier to read in Instapaper, Pocket, and Readability.
The most important thing you can do to make your site work correctly with Reader View is make sure your site is built on well-formed HTML. Writing good HTML is outside the scope of this article, but the basics are important.
- Don't have multiple h1 tags in a single article element.
- If you aren't using article elements, don't have multiple h1 tags at all.
If you screw these things up, Safari might not know what the title of your post is supposed to be, and it could make the mistake of assuming one of your sub-headings is the title.
Another major rule: Reader View will generally only work for articles with a minimum of around four paragraphs. Any less than that, and it doesn't usually show up.
There's one extra rule that screwed my site up for a long time: you can't wrap the content of your article in a container. Your h1, h2, or header elements MUST be in the same container as the p tags that make up your article.
The following code does not work:
<h1>My Great Article</h1>
If you write the above code, Reader View will think your article is titled "Introduction". That's because the h2 header containing the word "Introduction" is the first heading element inside the box that contains your p paragraphs - in this case, a section element.
<h1>My Great Article</h1>
The above code will probably work. Because there is an h1 element inside the same block article with all the p paragraphs, it will be assumed to be the title of the article.
Still, Reader View is a mysterious and fickle beast. Even if you take advantage of the above advice, your articles still might not work correctly. But if you don't take advantage of this advice, they almost certainly won't work. Take this advice as a starting-off point.
Allow Smooth Scrolling in Scrollable Elements
By default, Mobile Safari is designed around the idea that when you drag your finger on the page, no matter where your finger is, the entire page scrolls. This is a perfectly reasonably assumption, but sometimes it doesn't hold up. If you have a site with a separately scrollable element - say, a sideways-scrolling image box or a vertical-scrolling description view - you'll need to employ an extra trick to make scrolling work correctly.
The traditional way to make a scrolling element is by setting overflow: scroll on that element's CSS. The problem is, if you just do that in Mobile Safari, scrolling feels very wrong - there is no bounce, no acceleration, and no smoothness.
The following CSS fixes this problem:
If you add this code, scrolling in subviews will feel just as smooth as scrolling in a native app.
Don't Beg People To Install Your App
Look, I get it. You're proud of your app and you want people to use it. You know how much better it is than your website. You know how valuable it is to be installed on someone's device. You know that if you don't get a reader to install your app right away, they might forget. You know that if your site uses ads, some of your visitors are blocking those ads. None of this matters - you still shouldn't irritate visitors about installing your app.
If your website is terrible, visitors are likely to assume that your app is also terrible - why on earth would anyone install it? Would you? It's far easier to build a website than it is to build an app - if you can't even build a good website, nobody is going to install your app, no matter how much you beg them.
If you have an app, and you absolutely must tell your visitors about it (like if your site only exists to support your app), there's one way you should do it: using the official APIs provided by Apple and Google.
I'm not going to get into the details here; Apple provides a great website with more information on how to do this.
Users hate app pop-ups. Google has recently started penalizing sites that don't take advantage of the official APIs. Do the right thing here.
Killer article from Federico Viticci at MacStories: a comprehensive wish list of features we’d love to see on iOS 10 – complete with mockup pictures and video!
Seriously, I’m not even going to excerpt my favorites here. Read the whole article, it’s great.
I’d add a few feature requests of my own to the pile:
Selection that actually works. This is a longstanding issue I have. When I try to select text on a webpage, iOS pretty much makes up its own rules for what is getting selected. These rules change arbitrarily depending on how zoomed the page is. It’s been 10 years, this needs to be fixed.
Mac-style Spotlight Search. The search interface called “Spotlight” in iOS is vastly inferior to the Mac version – it only works from the home screen, it doesn’t search the same amount of content, and it only has a limited degree of quick actions.
We’re seeing progress on this front – iOS 9.2 added keyboard navigation to Spotlight results, and allowed you to launch the top result by hitting the Enter key. We have further to go. There’s no reason Command+Space search on iPad should be worse than Mac.
Safari Technology Preview. I’m convinced this is coming. Apple recently released a special version of Safari for Mac that acts like a snapshot of work-in-progress features. This app would actually make even more sense on iOS, since it would have the side benefit of allowing two versions of Safari to run side-by-side in split-screen multitasking.
Expanded Hardware Keyboard Support. There is still much low-hanging fruit to harvest before the iPad can be taken seriously as a full Mac replacement – this falls under that category. Hardware keyboards can’t be remapped in iOS right now – if you’re using a PC keyboard, the Command and Option keys are reversed. If you like setting Undo+Cut+Copy+Paste to F1+F2+F3+F4, you can’t. Forget about more advanced macros. This is easy to fix – Apple can bury these settings under Accessibility, but they should be there.
Better Command+Tab App Switching. The iPad throws up a Mac-style app switching overlay when you press command+tab on a hardware keyboard. This makes no sense – iOS already has a superior native app switching interface. Allow keyboard navigation of this interface instead of remaking the Mac version.
Trackpad Support. This is a big one. I know it has been heavily debated inside of Apple. The ground work is already in place – you can already use the virtual keyboard as a rudimentary trackpad on iPads and 3D-Touch-capable iPhones. It’s time to throw the switch on this one. Get trackpad support out there, let developers and users figure out the use case and iron out the bugs. This doesn’t come at the expense of a touchscreen, of course, but it should be there.
Full-quality HDMI Out. I don’t believe there is a technical limitation to why the iPad Pro can’t output a full, uncompressed HDMI signal from the HDMI adapter. Previous devices had to compress the video via H264 and output it to a special computer buried in the adapter. That computer then decompressed the video and output it over the HDMI connection. This was done to work around bandwidth limitations in Lightning.
The iPad Pro probably doesn’t have these limitations. At USB 3 speeds, it should be more than capable of outputting native video. This is probably a very low priority, but it should be there.
Local Backup Via Time Capsule. Apple sells a wireless base station with a built-in backup drive. The Mac can wirelessly back up to this drive, but iOS cannot. With all the horror stories about privacy and government intrusion in the news these days, a lot of people would probably pay for a good quality, transparent, local backup.
Fix Copying. Seriously Apple, this is a bad bug. When you copy something, it should copy. Always. Somewhere in the past few months, that stopped working some of the time. Fix that.
The second day of GDC is upon us. Tuesday; the calm before the storm, since the main expo floor opens on Wednesday.
I've walked the halls of the conference, listened to 5-10 talks and presentations, and checked out all the currently-available booths. Obviously much of the conference is still locked behind closed doors until Wednesday, but a few things stick out clearly from the preliminary exhibits:
VR is the Hot New Thing
Right from the start, one thing is abundantly clear here at GDC: VR is everywhere. Mobile VR, desktop VR, console VR, AR, cardboard-style VR - literally every form of VR you could imagine is on display at practically every booth.
Interestingly, the approach each parties are taking to VR and AR are wildly different from one another. We have $10 cardboard VR devices that hold your phone up to your eyes, and right next to that, we have thousand-dollar high-end rigs designed to work with PCs. There's some gimmicky stuff - one VR headset has a fan that blows air on your face while you play - but the vast majority of VR systems are gunning for mainstream popularity.
Throughout the conference, I'll be doing my best to find as much mobile-gaming-focused content as possible. Maybe I'll get lucky and find some controller-based news. But one thing is becoming increasingly clear: I'm probably not going to find much hardcore mobile-gaming-related news that doesn't incorporate VR in one form or another.
Apple is Everywhere and Nowhere.
Apple has never had an official presence at GDC, but that doesn't mean they aren't here. In my cursory glances at people's GDC badges, I've seen a lot of people with Apple on their badges.
I'm sure some of these folks are gamers who just so happen to work at Apple; Apple employees are people too, after all. But when there's smoke, there's fire. The sheer number of Apple badges I've seen suggests Apple might have sent people to at least visit the conference.
This many Apple employees have to be doing something here. Maybe just taking in the sights. Maybe just keeping an eye on the latest mobile games.
Whatever they're doing, I'm happy to see Apple with some sort of presence here. Apple has a lot of blind spots when it comes to gaming. Listening to, meeting with, and talking to some of the smartest people in the games industry can only help Apple do a better job. If enough developers gripe about how terrible the App Store is for making a sustainable living designing games, maybe it'll get through someday.
Mobile is Missing
Perhaps the most surprising aspect of this conference: the complete lack of any form of mobile gaming. I've seen between 5 and 10 completely different VR devices, and yet I haven't seen a single iPhone or iPad.
The only mobile devices of any form I've found are a few Intel tablets and smartphones, and that has more to do with Intel's desire to push for X86 smartphones and tablets than it does for an actual desire to talk about mobile gaming.
There are a few possibilities here. There's a longstanding stigma from so-called "real gamers" against mobile gaming, and perhaps this discourages indie developers from showing off the mobile versions of their games. There's also the idea that mobile is no longer the hot new thing - that's VR - so it isn't worth showing off.
There are multiple panels and conference talks about various aspects of mobile gaming, but the lines for these talks are far lower than those for VR gaming. From my perspective, this is insane. Mobile is the biggest game platform in the history of gaming, and ignoring it in favor of a technology that is at least a year out seems shortsighted.
The good news is, the actual GDC expo hasn't started yet. That comes Wednesday. Monday and Tuesday are made up of lectures, discussion panels, and lobby exhibits.
The actual expo will have more presentations from the big name companies. Sony, Microsoft - you know the big guys. It's possible that something more mobile-focused will be shown off in the exhibit hall. I'll continue to keep my eyes open.
This is my first GDC, and it seems like I picked an odd one to start with. There's a feeling in the air that VR is the next gold rush. In the next few years, this prediction will either be proven true or false. We're right on the precipice of this new media, so that's all anyone is talking about.