Defense Against the Dark Arts (of iMessage Configuration)

Ever since upgrading to iOS 6, I’ve had a problem. The glorious promise of iMessage with its seamless integration of SMS/MMS and Apple’s messaging services between iPad, iPhone and Mac has mostly worked, with one infuriating, deal-breaking exception.

Texts to my phone number go to my iPad and not to my iPhone.

Look, all of this integrated messaging is cool. Being able to have text messages show up not only on my phone but on my other devices is awesome. But they have to at least show up on my phone or the whole thing is a failure.

I’ve researched the problem and found some people with somewhat similar issues, lots of stuff involving jailbroken iPhones (which mine is not), etc. but no clear answers to my exact problem. Several people in forums suggested shutting off iMessage on the various devices, deleting accounts, full-blown factory restore, you name it. All of which were either things I tried and found didn’t work, or wasn’t willing to try due to the amount of time and tedious work involved.

iMessage SettingsSo I began experimenting. There was one distinct problem I could see in settings. On both iOS devices and my Mac, the Messages app was showing both my phone number and email address. But in some cases one was grayed out. Infuriatingly, on my iPad and Mac, the phone number was grayed out and checked, and on the iPhone the phone number was grayed out and not checked. I could easily add or remove the connection of my email address to any of the devices, but my phone number was stubbornly locked into my iPad only. (Or, well, my iPad and my Mac… I guess. Honestly I hardly ever use Messages on my Mac so I haven’t really paid attention.)

I wish I could give a clear account of what came next, but I started tapping various buttons and clicking various boxes with such a fury that it all became a blur. What I do remember is that I clicked the checkbox next to my email on my Mac, which un-grayed the phone number. I was then able to uncheck the phone number, and the email now became grayed out.

So, if I understand correctly, the way iMessage settings work, at least one receiving phone number/email address must be checked at all times, so if only one is checked, it’s also grayed out so you can’t uncheck it. Then, if you check the other one, you may be able to uncheck the first.

That wasn’t working on my iPhone, however. Strangely though (at least as I recall from the aforementioned blur), when I repeated the process from my Mac on my iPad, then took a look at my phone, it was already switched to having the phone number checked and grayed out.

So then I began running some tests. This is where things get muddy, and since all of this just happened a few minutes ago, I still may not have a complete solution. I tried sending a text to my phone number from SLP’s iPhone. Never got it. Then I tried sending a text to my phone number from my iPad and it went to my phone within seconds. Cool. Then I tried sending a text to my email address from SLP’s iPhone, and it immediately showed up on all three of my devices.

Everything then is working as expected except that I did not get the text from SLP’s iPhone to my phone number at all, on any device. It’s hard to say what that’s all about. Are things working now? I don’t know.

Here’s another weird thing to throw into the mix. SLP and I share an iTunes Store account, but we have separate iCloud accounts. I also have a separate iCloud account apart from the iTunes Store account. The iTunes Store account uses my “real” email address, and I have a separate me.com email address I use on iCloud. So that’s all kind of a big mess, yes I know. Anyway, whenever I made these various changes to my configurations, the iOS devices would pop up alerts regarding the change. These alerts also appeared on SLP’s iPhone, even though her Messages settings don’t have any of my account info associated with them.

The bottom line here, for me, is that Apple really has not dealt with the reality of multiple users on the same device, multiple family members sharing an iTunes Store account but needing their own iCloud accounts, etc. They may be trying to deal with it all, but they’re trying to integrate too many things that had developed for too long as independent products. And they’re not having as much success at it as they think they are.

This post began as many others here do, as an attempt to share my solution to an Apple conundrum. Unfortunately in this case I just can’t quite make sense of what’s happening, and it seems to be one of those dark-clouds-on-the-horizon portents of more trouble to come with Apple’s tendency for its ambitions to exceed its capabilities in the realm of networked services.

I just want it to work. Isn’t that the Apple promise?

Follow up: Just after posting this I had our neighbor — who also has an iPhone but of course does not share our iTunes/iCloud accounts — send a text to my phone number, and I got it. So the problem seems mostly resolved. But let’s leave it at this: if you share your iTunes Store account with another family member and you both have iPhones, you might need to send your text to each other’s email addresses instead of phone numbers, if you’re running into the same problems I’ve been having.

Responsive Web Design: A Practical Approach (Part One… Again)

With exactly three posts here all summer, the last being nearly two months ago, it might be reasonable to assume this blog had been abandoned. Wrong! I have simply been so busy, building so many responsive websites, that I haven’t had time to gather my thoughts to share in anything longer than 140-character bursts.

“‘Responsive’ websites?” you say, and I hear the internal quotation marks in your voice. Yes. If you don’t know what responsive web design is… well, let’s be honest. You found this post, if you found it at all, when you googled “responsive web design” so I suspect you have at least a passing familiarity with the term. So let’s get started.

(Actually, before we get started, a quick note: astute observers may… um… observe that I wrote a seemingly identical post to this one back in June. And yes, that’s right. But after a summer immersed in this stuff, rather than continuing from there with “part two” it felt better to start over from the beginning with a more in-depth introduction.)

Getting Started, or, rather: How I Got Started

I’ve owned an iPhone for about 4 1/2 years now, and one of the first things I noticed shortly after it became the hottest thing around was that everyone was suddenly creating mobile websites. There were even services created just to help you convert your website into a mobile website. But it was always a separate experience (usually with a domain name that started with m.) and invariably an inferior one.

A lot of websites still do that, and it still sucks. It’s two separate websites, which is bad for users — often content doesn’t make it to the mobile site, and when that happens there’s no easy way to get to it on the desktop version — and it’s bad for site owners — double (or more) the work.

But about a year ago I started to notice a new approach, one that didn’t require two separate websites, and one that, owing partly to how quickly it caught on with the superstars of web design, usually yielded much better looking results: responsive web design (which I will henceforth lazily refer to as RWD). RWD uses CSS3 media queries to detect the window/screen size the page is displayed on, and changes the layout of the page to suit the screen. On the fly. Same page. Same CSS.

So there is no mobile site, no desktop site. There’s just the site. And it looks great on any screen.

In theory.

Of course, this solution is not perfect. But it is better in so many ways — standards compliant, future-proof, user-friendly, easy to maintain — that it is clearly the optimal solution for mobile websites today.

Getting Started (you, this time)

Before you delve into RWD, there are a couple of things you need to know: 1) HTML5 and 2) CSS3. More specifically, you need to embrace the concept of semantic HTML fully, as a well-structured HTML document is essential to the responsive approach.

I assume if you’re thinking about RWD, you’ve long since abandoned table-based layouts, and you probably don’t even remember the <font> tag existed, right? Right. But for RWD to work well you need full separation of your visual design from your document structure.

My personal preference is to take this to an extreme: I never even use <img> tags except in body content. All visual elements of the layout are contained in my CSS, even logos, and I avoid using images wherever possible. By taking full advantage of the visual effects offered by CSS3, and accepting “graceful degradation” in older browsers (or, in reverse, “progressive enhancement” in newer ones) — a topic we’ll get to in a bit — you can create a lean, well-structured site that is ripe for the responsive treatment.

Building Blocks

Nothing starts from nothing. (Whoa, that’s heavy.) And certainly a responsive website doesn’t (or generally shouldn’t) start from scratch. There are three building blocks that I now include in every site I build out:

reset.css

Created by CSS guru Eric Meyer, reset.css is a handy little file that removes all styling, which can vary between browsers, from all HTML elements, allowing you to “reset” the design and start with a clean slate. Just remember that it means you’re going to have to redefine everything — I guarantee your CSS file will eventually contain strong { font-weight: bold; } and em { font-style: italic; } but that’s the price you pay for complete control.

html5shiv.js

Developed (or at least maintained and expanded upon) by Remy Sharp, the purpose of html5shiv.js is to enable support for new HTML5 elements in older, but still widely used, non-HTML5 browsers like Internet Explorer 8 and earlier. You don’t have to use the new tags like <article> and <nav> to do RWD, but it’s fun, and feels like the future.

jQuery

There are a handful of popular JavaScript libraries out there whose goals are generally to 1) standardize inconsistent JavaScript across browsers, and 2) make working with the DOM easier, so you can do cool, standards-compliant, cross-browser compatible animations and interactivity with just a line or two of code. jQuery is arguably the most popular of these, and is my personal favorite. Again, this is not strictly required for RWD, but I use it all the time, and often in ways that enhance the capabilities of my responsive layouts. (One specific example: it’s great as a foundation for resizing complex elements like slideshows… of course, for that matter, it’s great for making the slideshows in the first place.)

Finding Your Break(ing) Point(s)

The grand vision of pure RWD is a fully fluid layout that scales dynamically to any screen size, and a grand vision it is indeed. But we are living in an imperfect world, with many factors to consider.

In my case, I typically work with outside designers. Designers who appreciate and support RWD but are not immersed in its intricacies like I am. And I don’t want them to have to be. So as a hybrid developer-designer, I make use of my somewhat unusual but not especially unique skill set to handle the responsive adaptations for them. They just deliver a “regular” web design to me, I build that out, and then I adapt and scale and shift things around as needed for the smaller screen sizes, doing my best to stay true to the spirit of the original design.

There are two keys to making this approach work:

  1. Get the designs in Illustrator format, not Photoshop. (No, seriously. You’ll find out why in a bit.)
  2. Be prepared to start thinking about break points and accept that a perfectly fluid layout is not in your immediate future.

To understand break points, you need to understand common screen dimensions. You also need to understand the importance of margins to an aesthetically pleasing layout.

For years the target screen size for web design has been 1024×768 which, delightfully, is also the effective resolution of the iPad. (Yes, the newer iPads have a high-resolution “Retina Display” which is 2048×1536, but CSS pixel measurements are “pixel-doubled” on these displays, so you don’t really need to think about high-res too much, except when it comes to images, and we’ll discuss that in a minute.)

So, we can (still) start with 1024×768. But that doesn’t mean your design should be 1024 pixels wide. You need margins, both for stuff like window “chrome” (borders, scrollbars, etc.) and also just to give your content a little breathing room. A commonly accepted standard width to use for web designs is 960 pixels, and I still stick with that.

This can sometimes cause some confusion for designers who are used to the fixed palette of a printed page. Your content can/should go all the way to the edges of that 960-pixel layout, and you still need to think about what comes outside of that area. So it’s good when you’re designing to think of foreground and background. Have an arbitrarily huge background canvas, with a 960-pixel-wide by whatever-pixel-tall box floating top-center over it, where your foreground content will go.

But I digress. We start with 960. That’s our maximum break point. (OK, if your audience is primarily looking at the site on 30-inch displays, you might want to consider an additional larger break point at 1200 or so.) Then we move down from there. I like to think of it like this:

Device/Screen Type Screen Width Content Width #wrapper CSS
Large computer displays (optional) 1280 and up 1200 margin: 0 auto;
width: 1200px;
Computer/iPad (landscape) 1024 960 margin: 0 auto;
width: 960px;
iPad (portrait) 768 720 margin: 0 auto;
width: 720px;
Small tablets/phones Varies Fluid margin: 0 auto;
width: 90%;

The “small tablets/phones” layouts typically collapse to a single column and are the only truly fluid layouts I use; the larger break points go to fixed widths, which makes for easier scaling of columnar content.

Note that I typically follow the convention of placing everything inside my <body> tags inside a <div id="wrapper"> tag, which allows me to apply CSS to the overall page body and separate CSS to the foreground content (what’s inside the “wrapper”).

Occasionally I will split “small tablets/phones” into two separate break points, with small tablets somewhere between 500 and 640 pixels. I may also change the content widths somewhat to suit the specifics of the design.

Mobile-First Sounds Great, but Let’s Be Honest: It’s Really IE8-First

Earlier in the year, Luke Wroblewski took the idea of RWD a step further with his inspired vision for Mobile-First web design. Initially I wholeheartedly embraced mobile-first, but I’ve since reconsidered.

What is mobile-first? It’s RWD, but instead of starting from the desktop layout and using CSS3 media queries to adjust the layout to smaller screens, it starts from the small screens and works its way up. The main benefit of this approach is that it allows you to prevent mobile devices from loading unnecessary assets (images, etc.) that they won’t actually use.

There’s a major downside to mobile-first, however, at least in my experience trying to implement it: there are still a lot of people using Internet Explorer 8 (and earlier), which does not support CSS3 media queries. So unless you create an IE-specific stylesheet (using conditional comments), IE8 and earlier users will be stuck with a strange variation on the phone version of your site.

So after building a few mobile-first RWD sites, I have abandoned that approach, and gone with what could be called an IE8-first approach. I am not really building to IE8. I work primarily on a Mac, and I preview my work in Chrome while I’m developing. But what I mean is I’ve gone back to that standard 1024×768 screen as the baseline for my CSS, with CSS3 media queries for the smaller screen sizes (as well as for print and high-resolution displays, the latter of which is next up).

Getting Retinal

Remember earlier when I said your designs should be in Illustrator rather than Photoshop? Here’s why: high resolution. Sure, you can change resolution in Photoshop too, but… wait, you’re not still slicing-and-dicing, are you? By working with discrete objects in Illustrator, resolution-independent and, when possible, vector-based, you have the maximum flexibility when you render these objects out as 24-bit PNGs with alpha channel transparency. (You are doing that too, right?)

Starting with the iPhone 4, Apple introduced the “Retina Display” which is their marketing term for, basically, screens with pixels too small for you to see. The goal is to achieve a level of resolution on an LCD screen that rivals print. The exact pixels-per-inch varies from screen to screen, and is not really too significant. The key point is that above a certain pixel density threshold, CSS treats all pixel-based measurements as pixel-doubled. As I noted above, although the current iPad screen resolution is 2048×1536, its effective pixel size in CSS is still 1024×768. There is a practical reason for this (if CSS stuck with the actual pixels, all web pages would appear absurdly tiny on such a screen). But there’s also a practical downside: most images on most web pages are now being scaled up in the browser to these pixel-doubled dimensions, resulting in a blurry appearance.

But here’s something really cool: you can specify the display dimensions of an image in CSS, and the browser will scale the image down on-the-fly. This has been the bane of many web developers’ existence for years, where people who didn’t know better would upload a very large, high resolution photo and scale it down in the page, resulting in ridiculous download times as the image slowly drew in on the page.

Used effectively, however, this characteristic provides an extremely easy way to make images high-resolution on displays that support it. By using CSS to scale the dimensions of an image to 1/2 its actual pixel size, the image will display in full resolution on screens that support this.

Of course, doubled dimensions mean quadrupled pixels, and depending on the details of JPEG or PNG compression, the high-resolution images may be more than four times the file size of their standard-resolution equivalents. So it’s nice to, again, use CSS3 media queries to only deliver these high-resolution replacement images to screens that can display them properly. (This will be demonstrated in the full example code below.)

You Say Graceful Degradation, I Say Progressive Enhancement

The matter of graceful degradation and/or progressive enhancement (depending on how you look at it) is tangential to RWD, but it’s something you’re likely to be dealing with as you build a responsive website.

Not all browsers support all CSS3 capabilities, but that doesn’t mean you shouldn’t use them. I’m especially fond of box-shadow and border-radius, and in working with RWD you’ll probably get quite familiar with background-size as well. Remember that most of these newer capabilities will probably need to include vendor prefixes (like -moz- and -webkit-) as well. It’s cumbersome, and will probably be as painful to clean up as <blink> tags in a few years, but for now it’s the way to get things done.

The biggest challenge with progressive enhancement may well be convincing site stakeholders that it’s OK for the site to look (subtly) different in different browsers. Then again, if you’re doing RWD, that should be a given.

So, What Does This Actually Look Like?

As I’ve iterated my RWD approach this summer, I’ve inched closer and closer to a standard template I can use to start a new website. I feel it’s not quite there yet, but my basic CSS file structure is standardized enough that I can share it here. In a subsequent post, I hope to provide a zip download containing a full template file set for creating a new responsive website.

Here’s a rough example of what my typical CSS file looks like. Again, personal preferences dominate here: I like to write my CSS from scratch, and I typically organize it into three sections: standard HTML (basic tags), CSS classes (anything starting with a period), and DOM elements (anything starting with a hash mark).

The idea is that we’re going from general to specific. Within the standard HTML and CSS classes I alphabetize everything, so it’s easier to find things to change them as I go. Within the DOM elements I try to keep everything in the order it actually appears in the HTML structure. (I also alphabetize the properties within each element definition… but that’s just because I’m anal retentive.)

Sample CSS File

/* IMPORT */

@import url('reset.css');

/* STANDARD HTML */

body {
  font-size: 100%;
  line-height: 1.5em;
}

/* CSS CLASSES */

.column {
  float: left;
  margin: 0 5% 1.5em 0;
  width: 45%;
}

/* DOM ELEMENTS */

#wrapper {
  margin: 0 auto;
  width: 960px;
}

#logo {
  background: transparent url('img/logo.png') center center no-repeat;
  -moz-background-size: 250px 100px;
  -webkit-background-size: 250px 100px;
  background-size: 250px 100px;
  height: 100px;
  width: 250px;
}

/* CSS3 MEDIA QUERIES */

/* PRINT */
@media print {

  * {
    background: transparent !important;
    color: black !important;
    text-shadow: none !important;
    filter: none !important;
    -ms-filter: none !important;
  }
  @page { margin: 0.5cm; }
  h1, h2, h3, p { orphans: 3; widows: 3; }
  h1, h2, h3 { page-break-after: avoid; }
  pre, blockquote { border: 1px solid #999; page-break-inside: avoid; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  a, a:visited { color: #444 !important; text-decoration: underline; }
  a[href]:after { content: " (" attr(href) ")"; }
  a[href^="javascript:"]:after, a[href^="#"]:after { content: ""; }
  img { max-width: 100% !important; page-break-inside: avoid; }
  thead { display: table-header-group; }
  tr { page-break-inside: avoid; }

}

/* LARGE TABLETS (UNDER 1024 PIXELS) */
@media screen and (max-width: 1023px) {

  #wrapper {
    width: 720px;
  }

}

/* SMALL TABLETS/PHONES (UNDER 768 PIXELS) */
@media screen and (max-width: 757px) {

  #wrapper {
    width: 90%;
  }

}

/* HIGH-RESOLUTION DISPLAYS */
@media only screen and (-moz-min-device-pixel-ratio: 1.5),
    only screen and (-o-min-device-pixel-ratio: 3/2),
    only screen and (-webkit-min-device-pixel-ratio: 1.5),
    only screen and (min-devicepixel-ratio: 1.5),
    only screen and (min-resolution: 1.5dppx)
{

  #logo {
    background-image: url('img/logo_x2.png');
  }

}

The Test Suite

Of course, all of this work means nothing until we’ve seen what it actually looks like in the web browsers on these different devices. To that end, a decent test suite is essential.

One cool trick about RWD, which is not only useful to dazzle clients when pitching a RWD approach to their websites, but is also helpful for quick testing as you go, is that the responsive approach works simply by making your browser window smaller on a computer. So you can shrink the window down and approximate what the site will look like on a tablet or a phone without actually having one in your hand at all times.

But before you go live, you do need to test it for real on different devices, just like you need to test in different browsers. The table below shows my test suite. It’s not comprehensive, but it’s practical, and it all fits in one small messenger bag.

Device Operating System Browser(s)
MacBook Air Mac OS X Mountain Lion Chrome (latest)
Firefox (latest)
Safari (latest)
MacBook Air
with Boot Camp
Windows 7 Internet Explorer 9
Chrome (latest)
Firefox (latest)
MacBook Air
with Parallels Desktop
Windows XP
(3 separate virtual machines)
Internet Explorer 8
Internet Explorer 7
Internet Explorer 6
Firefox 3.6
Note: I only offer my clients very limited support for IE6.
iPad (Retina Display) iOS 6 Mobile Safari (latest)
Chrome (latest)
iPhone (Retina Display) iOS 6 Mobile Safari (latest)
Chrome (latest)
Samsung Galaxy Player 4
(high-resolution)
Android 2.3 Android web browser

Give Me Something I Can Print!

You may have noticed in the full example CSS above that I included CSS3 media queries for print. The need for decent print output will vary by project — different sites’ audiences may be more or less inclined to print out pages. In general I think of printing out web pages a bit like I think about… well, honestly, I can’t even think of a good analogy. You just shouldn’t do it. But sometimes it has to happen. I won’t be exploring the infuriating nuances of print CSS here, other than to say that if you do need to support printing, the code provided in this sample is a good place to start. (Sadly, although I use it regularly, I neglected to make note of its source. If you know where it’s from, please let me know in the comments.)

Where Do We Go Now?

OK Axl, hang on. I know I’ve dumped a lot on you here to think about, without necessarily providing enough specifics. But that’s kind of the point: in order to do this right, you really need to learn it for yourself and gain the experience of building RWD sites directly. This is what has been working for me but my approach is certainly neither the only nor the best way, I’m sure.

My hope is to follow up this post with a “Part Two” entry this time around, where I get into more of the specifics of an actual example website. In the meantime, experiment and discover! And be sure to check out the entire A Book Apart series, as they provide the conceptual and detailed knowledge needed to get started with this exciting new approach to web design.

State of browser/OS/device usage on Underdog of Perfection, June 2012

I just had a look at my Google Analytics stats for this site. I made some interesting observations.

First, I saw iOS, iPhone and iPad showing up as separate devices. I wondered if iOS was a composite of both, but I realized Google was actually counting them separately. Looking at the daily stats it was clear that they made this switch on May 29, where before that date iPhone and iPad were being reported, and afterward it was just iOS. I’m not sure why they did that, but I am sure there was a very deliberate reason behind it.

Anyway, uncovering this switch was not relevant to my data observations, so I changed the date range to only encompass dates after the switch, June 1 to 20.

Here’s what I found:

True, I am a Mac user, and have for a long time favored Safari (although I recently switched my default browser to Chrome). But I don’t really spend that much time admiring my own work here on the blog. (Yes… not that much time.) So I don’t think my own activity skews the data here too much.

Do I then think this reflects the Internet as a whole? Absolutely not. I’ve learned over time that most of the people visiting my blog are stumbling upon specific posts based on a Google search, and these are almost always posts that are about diagnosing and fixing particular Mac-related problems. So, Safari’s dominance is logical (especially if Mobile Safari for iOS is lumped in here, which I have to assume is the case).

It’s nice to see Internet Explorer under 10%. And that’s all versions of Internet Explorer. But… what the heck is RockMelt? Yes, I am asking the two of you who use it.

Yes, even despite my blatant and unrepentant Apple bias, Windows still slightly edges out Mac in the stats. Interesting, then, that Safari is the most popular browser, since I suspect there are even fewer Windows Safari users than there are RockMelt users. But of course, we’re back to iOS. If you combine Mac and iOS, the total is well above that for Windows, and explains Safari’s #1 spot on the browser list.

Among mobile operating systems, iOS demonstrates a Windows-in-the-late-’90s level dominance. This despite the fact that Android famously holds greater market share in the US. Yes, my content will naturally skew my stats Apple-ward, but this data also, I think, reinforces the idea that iOS users actually use the web a lot more than Android users do.

BlackBerry and Nokia… how cute. Where’s Windows Phone?

And finally, we have mobile screen resolution. Now that Google doesn’t separate iPhone and iPad anymore, this is pretty much the way to distinguish between them in the stats. These resolutions are not the actual resolution of the screens but the pixel-doubled effective resolution used in the web browsers on Retina Display devices. 320×480 is the iPhone (even though the iPhone 4 and 4S have 640×960 screens), and 768×1024 is the iPad (even though the new iPad has a 1536×2048 display).

0x0? Really?

What I think is most significant here though is not the iPhone/iPad split at all, interesting as it is. It’s the fact that once you get past those, there’s no standard whatsoever on Android. That’s something to remember for those of us working on Responsive Web Design.

The real reason Android is (and has always been) in trouble

Over on Daring Fireball, John Gruber links to a Business Insider piece by Jay Yarow, called “Android Is Suddenly in a Lot of Trouble.”

Gruber responds:

It’s not that Android is suddenly in a lot of trouble — it’s that a lot of people are suddenly realizing that Android has been in trouble all along.

Exactly. But he doesn’t go on to mention why it’s been in trouble all along (though as I recall, he has in the past). I’ve seen plenty of reports, like this one from comScore that iPhones use WiFi networks significantly more than Android phones in the U.S. and U.K. This is one way of measuring the qualitative differences in how people use iPhones compared to how they use Android phones. You could also talk about app revenue, for instance.

All of these measurements and analysis revolve around one clear conclusion, especially when one considers how people end up walking out of a store with either an iPhone or an Android phone. Carriers are pushing Android because they can control the experience more. They’re giving away Android phones as stock upgrade models when customers’ contracts come up. People who don’t even care about owning a “smartphone” are bringing home Android phones because that’s just what the sales rep at the store recommended.

Android is in trouble because a lot of its users (the majority? the vast majority?) are just using it as a phone. It’s a commodity. A lot of the people buying it don’t really know or care what it is, and will never actively use its full potential. It’s just a phone. It may be capable of much more, but if it’s not being used for more, what difference does that make?

People who go into a store wanting to purchase a smartphone predominantly choose the iPhone. Not all of them, of course. Tech-savvy people do choose other smartphone platforms, including Android, especially those who want to tinker with the system. But the rest take whatever they are told to buy by their carriers’ sales reps.

This is the biggest reason Android tablets haven’t taken off, and it’s been discussed too. There’s a built-in market for the apathetic purchase of an Android smartphone. But no one (well, I hope) is walking into a cellular carrier’s store and saying “I want a tablet. What tablet do you recommend?” People who want a tablet don’t just want a tablet; overwhelmingly they want an iPad. Most people who don’t want an iPad don’t want a tablet at all. (Almost) everybody needs a phone.

The problem for the carriers, and the reason they’ve been promoting Android, has typically been that Apple retains too much control (from the carriers’ perspective) over the iPhone. That’s not likely to change, but with Windows Phone, suddenly the carriers have other options. Microsoft is definitely keeping a tighter rein on Windows Phone than Google does with Android, but with Windows Phone, the carriers still have options they don’t get with the iPhone. (Not that this lack of control has prevented them from selling millions of the things.)

If Verizon is serious about pushing Windows Phone (along with the fact that they still sell huge numbers of iPhones), then we’ll soon begin to see just how Android was, as Gruber says, in trouble all along. The success it has achieved to date was largely dependent upon carriers pushing it on unsuspecting or indifferent customers. If they stop doing that…

In UX we trust: Netflix as a case study in how good search isn’t good enough

Last night, prompted by a Dan Benjamin tweet, I felt inclined to watch one of my favorite ’80s movies, Fletch. I own Fletch on DVD (two versions, in fact), but I didn’t feel like busting them out. I wanted to watch it on my iPhone in bed, so I decided to check the iTunes Store and Netflix.

Unsurprisingly, iTunes did have it, but only for purchase, not for rental. And I’m not inclined to pay $14.99 to buy a digital copy of a movie I already own twice over on disc. While on iTunes, I saw a recommendation for The Sting. Intrigued, since I have never seen it (gasp!), I considered it as a possible alternative, and was pleased to see iTunes had it as a $3.99 rental. But before dropping four bucks on it I decided to check its availability on Netflix.

I checked the iTunes Store first, because I have learned to assume Netflix won’t have what I want available for instant streaming. Or, more accurately, I have learned not to trust that Netflix will have what I want.

And that’s where the problem lies: I don’t trust Netflix. It’s not that I think they’re up to anything nefarious (it’s not the same as the distrust I have these days for Google, for instance). And it’s not even entirely that I have become jaded by past experience discovering just how woefully limited their selection of streaming content is.

It’s that I don’t trust their interface to really show me what’s available.

Why not? They have a search box, after all. I can just search for what I want. To the best of my knowledge, the search box works pretty well. If they have something, it comes up. If they don’t, it doesn’t.

As usual, I couldn’t keep my frustration to myself, so I took it to Twitter:

So, again, why don’t I trust Netflix? I’ve been pondering that question all morning, and I think I have it figured out. It’s because good search, alone, isn’t good enough. Search is open-ended. It’s also kind of like standing outside a locked door and whispering through the keyhole to someone inside. You know there’s a lot of stuff inside the room. You even know that the room probably holds things you want. But you can’t see for yourself what’s inside, and the person on the other side of the door is only answering yes-or-no questions.

Of course, Netflix does offer more than search. But on mobile devices like the iPhone and iPad, it doesn’t offer a whole lot more. Sure, it has recommendations. And you can browse by genre. But I don’t really give a crap about their “recommendations.” That’s the person behind the door, offering a little bit more information, but it’s far from flinging the door wide open. And browsing by genre is great, if you know what genre the movie is in. If it even fits a genre. (I honestly don’t know what genre I’d find The Sting in. Is it a comedy? Drama? Action? I don’t know enough about the film to find it by genre.) And once you’ve selected a genre, you’re dumped into an experience not unlike rummaging through the cutout bin at a record store. (And if you’re too young to understand that analogy, get off my lawn.)

I took a few screenshots on both the iPhone and iPad, as well as on the Netflix website on my computer, to demonstrate what I’m talking about.

First, search results:

Well, that’s lovely. No results. OK. Did I spell it wrong? Is it case-sensitive? Am I hallucinating and this movie never even existed? Is anybody out there?

OK, well… hmm. What should I do now? Maybe I should browse comedies.

Really… that’s where we start? Can I fine-tune my selection a bit? Sort them into some kind of meaningful order? No, why would I want to do that. I’ll just flip through all of these aimlessly until I find something I can tolerate for the next two hours… I mean no, wait. Help me find what I’m looking for, dammit!

Well, OK. I’ve used enough apps between the iPhone and iPad to understand that the experience is often stripped down on the iPhone due to the smaller screen. That’s understandable. What about if I do the same search on the iPad?

You’re joking, right?

Let’s back up a step and see what Netflix presents to the user when they first enter the “Comedies” genre:

Well… um… that’s… a little better… I guess… than the iPhone experience. This is actually pretty close to what you get when you visit Netflix on the Apple TV, as well, and is somewhat of an improvement — aesthetically, at least — over the old version of Netflix for iPad. But still… it’s just that person behind the door, or the cutout bin.

Open the damn door and let me see for myself what’s in there.

Not that I think this is an adequate solution, let me say that right away, but I decided as a last resort to see if the desktop web interface for Netflix offered a superior experience. Here, where Netflix acknowledges that DVDs do, in fact, exist, the results are a bit better:

Thank you for at least acknowledging that the movie I asked about exists. Thank you for telling me that it’s not available for instant viewing but is available on DVD. Would it be so hard to do that on the mobile apps? I recognize that DVDs are useless on an iPhone or iPad, but simply providing this information reassures the user that their search worked. Now I can move on with my life.

What about browsing? Will you finally just open the door and let me see what’s in the room? At long last, sir, will you please just do that?

Yes!

You may note here that not only am I (after a few extra clicks) able to get a simple, alphabetized list, I am even able to browse subgenres! Who knew such wonders existed?

Sadly, browsing by title within a subgenre is probably the best way to get at what may be an ulterior motive behind the limited browsing interface Netflix presents in its mobile apps, as expressed in my tweet last night: their selection of streaming movies kind of sucks. There are plenty of reasons for this, and I’m not going to criticize Netflix for the challenges involved in working out licensing deals to stream thousands of movies for a very small, flat monthly fee. Netflix is a pretty amazing thing, when you look at what cable TV was like when I was a kid. (What am I saying? Look at what cable TV is like right now!)

Ultimately, though, whether or not Netflix is deliberately hiding its poor selection behind a mediocre browsing interface, it still has a mediocre browsing interface. Who cares? you say. Just search for what you’re looking for. Have you been reading this at all? I reply. Search, no matter how good it is, by itself is not good enough. Users need to be able to get their bearings, see what’s inside the room. We need an understanding of the scope of information we’re dealing with in order to make a meaningful search, and to make sense of the results we’re given, when we can’t find what we’re looking for.

So, a couple of final thoughts on how all of this ranting translates into a meaningful lesson in UX (user experience):

1. Don’t just rely on having a search box as an excuse not to organize and display your content in an easy-to-browse way.

2. Give meaningful feedback when a search fails. Don’t just tell the user “no results.” That’s obvious. Help them out. Give suggestions for alternate searches. And if there’s anything relevant in your database about the user’s search terms, even if it’s not directly available to them in their current context, at least let them know as much.

P.S. As it turns out, Netflix has neither Fletch nor The Sting available for instant viewing. I ended up not watching anything last night, and played around with this synthesizer app instead.