My colleagues in Chicago just launched a great responsively-designed greygoose.com, and Jason Grigsby and I were wondering how they brought up the user-friendlier telephone keypad in iOS instead of the ok-but-not-great number keypad. The team dynamically set the input type to tel with Javascript, but we were wondering if there would be a better way.

After some Twitter-talk with Grigsby and Chris Coyier, I set up a demo page to see if setting pattern="[0-9]* would make a difference. Thankfully it did.

So here’s the recommended format for numeric input types:

<input type="number" pattern="[0-9]*" />

Adding pattern="[0-9]*" triggers iOS to bring up the obese-finger-friendly keypad instead of the just-alright numeric keypad riddled with punctuation. Usability wins and the crowd goes wild.

By default iOS only triggers the number-only keypad on tel inputs, but this way the input type and the keypad don’t need to be bound. Semantics win and the crowd rises to their feet in jubilation.

Also worth noting the Kindle Fire pulls up a friendlier keypad regardless of whether pattern="[0-9]* is set:

Number & Tel inputs on Amazon Kindle

Big thanks to Björn Rixman, Chris and Jason for working through this!

Related Resources:

• Dive into HTML5 Forms
• The Current State of HTML5 Forms
• Web Form Design

Mobile is the future of the web, so it’s time to start investing in some mobile devices. Testing on actual devices is now an absolutely essential part of web design. Stephanie Rieger explains that there are crucial aspects of a web experience you simply can’t realize by resizing your browser or using emulators: true site performance, device capabilities, form factor, pixel density and the impact of the network.

What devices should you get? How much is it going to set you back? Obviously you can’t test on every device under the sun, so here’s my recommendation:

iOS

iOS traffic accounts for more than half of mobile traffic, so if you don’t have your iOS bases covered, get on it.

iPhone (iOS5)

Cost: $199 w/ plan
This device is likely already in your pocket, but if you don’t own one you need to make the investment. Aso make sure to download and test on Opera Mini.

iPod touch (iOS4)

Cost: $65-100 (used 2nd Gen)
It’s incredibly important to test on older versions of iOS and on older hardware, as Stephanie recently stressed, especially considering the fact that the iPhone 3GS is still around and free. The iPod setup works really well for me as it’s not terribly expensive. It isn’t used as my main device so I don’t feel like I’m missing out leaving it un-updated.

Android phone(s) (2.1, 2.2, 2.3, 4.0)

Cost: $45-?
Get at least one Android device, but I would recommend getting a large smattering of Android devices. Look to get a variety of OS versions, sizes, processing power, resolutions, and manufacturers. I’ve had lots of issues with browsers on HTC devices (zoom issues, touch events, layout), and it’s definitely good to have at least one running the vanilla OS. In addition to the stock browsers, you gain access to these wonderful browsers:

• Opera Mobile
• Opera Mini
• Firefox Mobile
• Dolphin HD
• Dolphin Mini

Android’s growth and diversity has been tremendous, and the device capabilities range from highly capable smartphones to bargain devices. Even if you can’t afford multiple devices right now, be aware that Android isn’t just a singular device, so while your experience might test well on one Android device, you might have trouble elsewhere.

Windows Phone 7

Cost: ~$125 and up
I noticed a lot of people on Twitter post-holiday mentioning how they’ve acquired a Windows Phone to test/play with. I think the Metro UI is a solid interface and the device is a worthy investment. This year the Microsoft partnership with Nokia goes into full-swing, and could see a boost as manufacturers start experimenting with non-Android offerings.

The Mango update brought a version of Internet Explorer 9 instead of the original IE7, but the browser still don’t support javascript touch events amongst other things. It’s also worth noting that after spending some time with a real Windows Phone, web experiences that resemble iOS and Android seem oddly out of place.

WebOS device (Pre or Pixi)

Cost: $25-100
Even though WebOS’s long-term future is up in the air, the devices are dirt-cheap. I got a Palm Pixi on a daily deals site for $25 so the price is most certainly right. The smaller form factor also makes for good testing.

Blackberry <6 device (Bold or Curve)

Cost: $17-200
I think these devices are very important to own. It’s a humbling experience testing on a non-Webkit Blackberry running 4.5, 4.6, 5.0. It keeps me honest as it butchers a lot JS and CSS. There’s lots of false positives and might be my biggest reminder that “support” is in no way a binary thing. It’s also a great reminder to accommodate for non-touch interfaces in your designs.

I just picked up a Blackberry Curve for $17, so the price is definitely right. And while BB 6.0+ now sports a capable Webkit browser, the majority of Blackberry subscribers are still sub 6.0 (and yes, they do use the web on these phones).

Nokia devices

Cost: $100-?
Obviously the rest of the world is different than the US so I don’t have specific recommendations as far as Nokia devices go, but don’t forget about the mobile giant and its massive reach. I use an N-95 to test on and it serves as a great “lowest common denominator” device. It supports some Javascript, has a d-pad input method, has a screen size less than 320 pixels and is a great little device despite being 5+ years old.

Nokia isn’t all old feature phones though, their N8 and N9 devices are definitely extremely capable smartphones. There’s a massive array of Nokia devices, so I’ll defer to the Riegers and their excellent and thorough breakdown of Nokia browsers.

Kindle Fire

Cost: $199
Getting a Kindle Fire for testing is absolutely a worthwhile purchase. It’s increasingly popular and is extremely affordable. The Silk browser is similar to Android 2.3 browser and the form factor is unique as it’s a larger than a mobile phone, but smaller than an iPad.

iPad

Cost: $499
Obviously not the cheapest thing in the world, but insanely popular (and super fun to own!). This device is extremely influential and we’re already seeing 7% of holiday online sales coming from iPads, just 18 months after the original iPad launch (via lukew). Tablet computing is most certainly on the rise, and the iPad2′s browser is currently one of the most capable browsers out there.

Miscellaneous Android Tablets

Cost: $250-499
The smattering of Android tablets out there are nice to have, but I wouldn’t say required to start with. If budget allows, definitely snag Motorola Xoom and/or Galaxy Tab running Honeycomb.

Considerations

• Getting a bunch of used wi-fi enabled devices is a great way to go. Not having to deal with a ton of carrier plans is of course a good thing, and once you have the wi-fi set up you’re good to go.
• Obviously having a device or three with carrier plans help for field testing. You should always tast your experiences in the real world over real connections, including 3G, EDGE and crappy free Wi-fi spots. It can be a sobering endeavor, but this is the world we live in and we should be considerate of the on-the-go aspect of mobile context.
• Check out what devices other mobile web people are testing. Here’s what devices we have at R/GA.
• The good people at Cloudfour are in the process of putting together a very thorough device testing lab in Portland. I’m excited to see the results.
• And just because emulators aren’t the real thing, that doesn’t mean they aren’t useful. Check out Max Firtman’s very thorough rundown of mobile emulators.
• Paul Irish has a nice thread collecting some relevant links
• View some of the comments on the mobile web mailing list (which is where this post originated from).

Testing on real mobile devices is now an essential part of the web creation process. You can get a pretty representational cross-section of the mobile landcape for a couple hundred bucks. Make an investment in the future of the web. People are accessing the web through the lens of their mobile phones and we need to do our best to give them great user experiences.

As it turns out, phone calls are still an amazingly effective (and human!) way to communicate. Yelp mobile users call a local business every other second thanks to prominently-placed phone numbers in their plethora of mobile apps. So yes, these mobile phones we’re all carrying around are well-equipped to facilitate some phone call goodness. Here’s some other mobile web phone call use cases:

• E-commerce Product Inquiries – I’ve worked with a lot of e-commerce sites and people do indeed call customer service numbers to guide their purchases. Users often have questions about sizing, fit and quality. When the price is high, it’s natural to want reassurance from a human before taking the plunge on a purchase.
• E-commerce Purchases – Many people feel more comfortable going through the actual purchase process over the phone than through an e-commerce site. It’s not unusual for a purchase to start on the web and finish over the phone. It also can be more efficient to check out over the phone than stumbling through a mobile checkout form.
• New Business – If you’re a web designer, artist, photographer or business, it’s likely you have a website to generate new business. Talking over the phone is a more personal way to get to know a potential client before making a commitment, and making a call on a mobile phone can be much easier than clumsily pecking an online web form.
• Calling local businesses – I had a wonderful conversation with the owner of a locksmith company at the airport. Talk about the perfect mobile web use case! If you’ve locked your keys in your car, you’re not going to download an app, you’re going to search for a locksmith, call them up and get them there as soon as possible. Hotels, restaurants, bars and many other local businesses can all benefit from an easy to find and use phone number.
• Customer Service – Customer service numbers are intentionally buried by terrible companies (and unintentionally by those who don’t know better), but they can be crucial part of a user experience. When a FAQ page isn’t enough, or (heaven-forbid) the mobile site doesn’t provide the necessary information, users turn toward the customer service number to hopefully get the answers they need.

Making Phone Numbers Linkable

Max Firtman gives an in-depth look at how to make phone numbers clickable for mobile browsers. The most “standard” way is by using the tel: URI scheme, which looks like this:

Call Customer Service at  <a href="tel:+18005550199">1-800-555-0199</a>

This is a great way to bulletproof a phone number, even though most mobile browsers do a decent job auto-detecting phone numbers and converting them into links. iOS, Android, Opera Mini, Opera Mobile, Blackberry (even pre-6.0) all do a good job auto-detecting phone numbers in text and making them clickable. However, most mobile browsers don’t stylize these links by default (iOS and Blackberry add an underline to the generated phone links), so it’s a good idea to style tel links so they’re nice and actionable.

Chunky, actionable phone number links on Yelp and Google Local

Phone Numbers in Responsive Designs

Tel links work great in mobile browsers, but unfortunately seem to fall apart when you get to desktop browsers (iPads and other tablets cleverly ask if you want to add the number to your contact list).

Safari and other desktop browsers unfortunately don't comprehend the tel URI schema

In their excellent book Head First Mobile Web, Lyza and Jason give a server-side detection example where the user experience is enhanced based on the device’s ability to make a phone call. I concur for the most part, although I really just want desktops to do a better job launching communication apps (Skype, iChat, etc) and/or contact manager apps (I’ve done some testing on this and it works in some environments, but not in others).

The tel URI-scheme is semantic in my eyes and think it should be encouraged. I don’t want to style a <span> and hope that all browsers will automatically detect a phone number. I suppose you could disable tel links and remove actionable styles for desktop browsers using Javascript, but again I like the idea of launching desktop VoIP software (used by millions and millions of people I might add). Yes, I know there are custom URI schemes for Skype and other apps, but the point is that any app should be able to leverage the app-agnostic tel URI scheme. And tel links make sense in other emerging contexts (TVs, car dashboards, tablets, etc).

Obama’s Missed Opportunities

The reason I’m writing this post is because I had the opportunity to check out the newly-responsive Obama campaign site. I came across a giant red “Call” button while browsing the site on my phone, and naturally thought that I could make a call. Instead, it dumped me off to a non-responsive section of the site where the login screen got buried behind the virtual keyboard, rendering the section useless.

Obama's site unfortunately doesn't let users make phone calls from their mobile phones

This can be written off as a technical flaw, but I was also surprised to not see any promotion of Obama’s historically very successful text messaging campaign. Again, mobile phones are capable of sending text messages and it would make a whole lot of sense to get people opting in to the program on the devices that can actually send and receive SMS.

I’m not trying to nitpick on a single site or discredit a very nice responsive design, I’m just trying to use this as a reminder that the mobile context is much more than screen size. Mobile is a unique medium with it’s own powerful communication channels built in. We should think about how we can take advantage of the capabilities of these devices to create better experiences.

Phone Link Best Practices

Sparkbox does a great job with their contact info: omnipresent, accessible, redundant and tappable

• Make contact information (regardless of context) easy to find – Make it easy for users/potential customers to find your phone number, email address and physical address.
• Global contact info is a good idea – Including contact info in the header or footer of every page makes it easy for users to get in touch no matter what part of the flow they happen to be in.
• Make phone numbers tap-friendly – Don’t leave it to the browser to auto-style your phone numbers. Style your phone buttons to be touch-friendly and make it obvious that the numbers are actionable.
• Expose phone numbers and email addresses – A big chunky “Call Us” button might seem like a strong call to action, but it’s as generic as “Click Here!” Spell out your phone number to make it dirt simple to read. While you’re at it, make sure an email address is exposed as well (I advocate against web-form-only approaches just because I’d rather write you an email in my native email client than a web form). Also, users may just want to copy the text to send to a friend in an email or SMS.
• Don’t make phone numbers images – This should go without saying, but…
• Redundancy isn’t a bad thing – Putting contact information in multiple places makes it easier to find. The fine people at Sparkbox include their contact information 3 times on their homepage without being overbearing.

This post at surface level is quite simple: be mindful of telephone numbers on web pages. But it’s really meant to keep up thinking about the mobile context as much more than just a small screen. When we create mobile sites: whether they be dedicated, responsive or other, we should be extremely considerate of all the opportunities and constraints the mobile medium provides.

A few things usually happen when I bring up the existence of mobile devices/browsers that aren’t iOS and Android. First, people give me a blank stare. Then they respond, “Well…fuck them”. (I’m not just being cheeky here, this sentiment has been expressed to me on multiple occasions.)

As more connected devices enter the landscape, it’s important to discuss how we as web creators are going to deal with the sheer number of devices, browsers, operating systems, and form factors. Moving forward we need to consider the difference between support and optimization.

The Problem

Here’s the problem. It’s already a challenge to properly test on the major desktop browsers: three versions of IE, Firefox, Chrome, Safari and Opera. Now we’ve got a giant list of mobile browsers on our hands, including:

• iOS
• Android
• Blackberry Webkit
• IE Mobile
• Opera Mobile
• Opera Mini
• Firefox Mobile
• Silk
• Ovi
• pre-6.0 Blackberry browsers
• WebOS Webkit
• Nokia Webkit
• Netfront
• UCWeb
• Dolfin
• and more!

(thanks PPK)

And this isn’t even getting into the different OS versions, emerging tablet versions and carrier bastardizations. Your reaction? Get right out of town. Go on, scram.

The Knee-jerk Reaction

You look at a list like that and know right away you’re in a world of hurt if you try to take on this challenge. So you do the logical thing and take a look at your analytics, realize that the vast majority of mobile traffic comes from iOS and a smattering of Android devices, then set out to make function and look great on them (typically “great” on iOS, “OK” on Android).

Clients give you full support and they can’t wait for their “iPhone site” to be ready. They get even more excited to learn that the “iPhone site” will work on Android too!

You learn in the process that it’s actually really fun to make stuff for iOS and Android, and start pushing the envelope, making things more app-like, adding some scrolls, adding some swipes here and there. Bells. Whistles. Life is good.

But why can’t I help but feel like there’s something wrong here?

Honey, I Broke the Internet

The fact of the matter is that people do indeed use these other mobile browsers. Despite being not as sexy and user-friendly as the top-shelf browsers, people rely on these mobile devices to learn, search, explore, shop, and more. Hell, for an increasing number of people, that little screen is their lens to the modern world.

The power of the web is its ubiquity. It is the web’s superpower, and its omnipresence is what sets it apart from native platforms. “Native vs Web” is total bullshit because the web can reach any device that has a browser, and native apps can’t. It’s The Web. Worldwide. You know, dub-dub-dubs and all that.

The minute we start giving the middle finger to these other platforms, devices and browsers is the minute where the concept of The Web starts to erode. Because now it’s not about universal access to information, knowledge and interactivity. It’s about catering to the best of breed and leaving everyone else in the cold. All of a sudden, the “native vs web” argument is no longer bullshit. It becomes more an apples-to-apples comparison, where web experiences only work on the platforms that happen to provide thousands of gorgeous native apps.

Moreover, it’s just short-sighted. If you substitute the words “IE” and “Netscape” for “iOS” and “Android”, you’ll see what I mean. Are we going to start seeing “Best viewed on iPhone” animated GIFs popping up on site footers? What happens when the landscape changes yet again next year? We need to stop simply reacting to the landscape of today and start thinking…you guessed it….future friendly.

Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven’t imagined yet—will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won’t hold up.

The future landscape is going to be crazier than that list of current mobile browsers. We won’t just have to deal with mobile phones, but also tablets, TVs, displays, car dashboards, watches and a whole lot of stuff we haven’t even dreamed up of yet. Starting to deal with this crazy landscape today is like boot camp for the insanity we’ll have to deal with tomorrow.

The C Word

So back to the problem at hand. Unless you want to hole yourself up in a cabin for the foreseeable future, you’re not going to be able to optimize your web experience for every single browser. What I’m really asking for here is consideration.

You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.

For example, there’s a lot of different Blackberry versions and there’s not enough time in the day to get it looking rock solid on every version. Blackberry OS 4.5 (RIM’s current least common denominator) butchers a lot of basic CSS. You even have to set explicit widths to floated elements for them to register. Goofy stuff, says I. We can’t really help 4.5′s problems and it’s probably not worth bending over backwards to smooth out every layout issue, just as most of us no longer feel the urge to go back and deal with IE6′s woes. But by being cognizant of the page weight and not sending down 20 scripts the phone can’t even use, we’ve just given the poor user a better experience than 98% of other sites they encounter.

And are there cases where what you’re doing simply isn’t possible on most devices? Of course. Nobody’s saying you can’t do that either. Just do it gracefully, and let people know their device can’t handle the sheer power of your web app. Be nice.

What To Do?

Progressive enhancement becomes an important strategy in order to deal with today and tomorrow’s diverse landscape. Start with a strong, semantic foundation, layer on styles smartly and add in unobtrusive Javascript to build up the experience. This allows us to reach more places while still delivering powerful experiences to iOS, Android and other more capable future browsers. It’s laying the foundation which we can then build upon.

And here’s some things you can do right now to be more considerate:

• Check out your site on the Opera Mini Simulator. How’s it looking and working?
• Download several Blackberry simulators. I recommend getting at least one 4.5, 4.6, 5.0, and +6.0 emulator. A few words of warning:
  1. simulators are good but don’t compare to the real deal. (Try beating up the nearest day trader to gain access to a live Blackberry)
  2. Blackberry simulators are Windows only
  3. Blackberry simulators are a bit clunky.
• Get yourself an Android device. In addition to the default Android browser, you can download Opera Mobile, Firefox Mobile, Opera Mini and Dolphin
• Jason Grigsby recommends ninja-mode: going to carrier stores and firing up your experience on as many phones as possible. Quick, dirty, and effective.
• Invest in some devices. You probably already have an iPhone or perhaps an Android. Get as many real devices as you can. I got a Palm Pixi for $25 on a daily deals site. These devices are worthy investments.
• Check out @firt’s rather extensive list of mobile emulators
• Make the most out of Modernizr and conditionally load resources based on the browser capabilities.
• Change your mentality. Instead of getting hostile whenever you encounter yet another device or browser, think of it as an opportunity to reach more users.
• Keep in mind that next year’s devices will be different yet again. Don’t get hung up too much on specifics and prepare your experience to adapt to tomorrow’s landscape.

Hope for the Web

“There is a difference between support and optimization” is a line I use regularly at work. For time and budget reasons, we can’t make the best experience ever for every connected device, but we have a responsibility to provide a decent experience to those who wish to interact with our products and services. As we move into the future, it’s going to be harder and harder to account for the plethora of connected devices, so we need to be construct our experiences with more consideration. In the magical world of web design we sometimes have to cut corners. Let’s make sure The Web’s superpower isn’t one of the corners we cut.