The Outside Scoop: Thoughts on Android Wear and a possible iWatch

The big news in tech today is Google’s announcement of Android Wear, a version of their Android OS specifically optimized for “wearables” like watches.

The tech media is erupting with ridiculously titled blog posts that refer to this as Google’s “answer” to the iWatch, a product that Apple has not announced, nor even acknowledged working on.

Surprisingly, for the first time I actually found one of these wearables mildly interesting, the Moto 360. But I am still skeptical of wearables in general, smart watches in particular, and especially the idea that Apple is working on one. But I’ve learned from my past mistakes, when I was convinced Apple was neither working on a smartphone in late 2006 nor a tablet in late 2009. So, in my world at least, my adamant belief that Apple is not developing a watch should probably be my biggest clue that they are.

So where is Apple’s “iWatch”? Aren’t all of these competitors eating Apple’s lunch (before it’s even cooked)? Perhaps. But consider this:

Remember the original iPod. It came into a market that already existed (but sucked), and delivered a radically superior user experience, and was a huge hit. Remember the iPhone. Once again, it came into a market that already existed (but sucked) and totally revolutionized it.

The thing is… a smart watch market doesn’t really exist (or didn’t when rumors of an “iWatch” first started to circulate). It almost seems like Apple got the wheels of the rumor mill turning deliberately, to goad their competition into creating the market, thinking they were beating Apple to the punch but in fact creating the exact environment of suck Apple needs to release a product into.

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).

0×0? 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…

What sort of person buys an Android phone?

This post will not be as sardonic and Apple-fanboi-smug as the title suggests… I promise. Well, maybe.

As a long-term Apple obsessive, there was never any question that I would fall into the iPhone camp, even when there was no real competition (and, seriously, there was no real competition until Android 2 and Windows Phone 7). But still, I wonder: what makes a person who is fresh to the world of smartphones choose Android over iPhone? This article on Macworld (reprinted… er, re”printed”… from Network World) raised the issue for me again. While it’s talking about a survey that shows most owners of “dumb” phones (a.k.a. “feature phones”) plan to replace them with another “dumb” phone, the author herself is an Android user, and the whole article skews in that direction.

Respondents to the survey cited high costs of data plans and the adequate capabilities of their feature phones as primary reasons not to switch, but then there’s this:

Others said they weren’t tech smart enough to have a smartphone, believing the apps and setup too complicated.

That really got me thinking, because it sounds like those users were imagining an Android phone in their future, not an iPhone. After all, one of the biggest selling points for iOS devices of all kinds (iPod touch, iPhone, iPad) is their ease of use, and specifically, the ease of purchasing, installing and using apps.

Much has been made of spurious comparisons between the iPhone/Android rivalry of today and the Mac/Windows rivalry of the ’90s. I don’t really find the comparison that relevant. While there are certainly some similarities between the “open” Android and the “open” Windows versus the “closed,” Apple-owned iOS and Mac OS, there are too many differences, both between Android and Windows, and between the Apple of the ’90s and the Apple of today: the specific nature of the licensing of Android compared to that of Windows, Apple’s status today as the world’s largest technology company and most iconic brand compared to its “niche player” status in the ’90s, etc.

So, I don’t really see Android as analogous to Windows in making the argument that history is destined to repeat itself and iOS will fall into a small — if highly profitable — niche. Apple’s in a much different place than it was when the desktop wars were raging, and Android presents a much different type of competition.

And yet, there are still some factors that remain relevant in the comparison, which I’ll get to in a minute. First, let’s consider the reasons a person upgrading from a feature phone to a smartphone would choose Android over iOS:

Carrier availability. More than anything else, the argument I’ve heard from people choosing Android phones over the iPhone was that the iPhone wasn’t available on their carrier of choice — usually their current carrier, and usually, specifically, Verizon. For the most part, people seem to like their carriers, and only switch if they’re having problems. And, from what I’ve heard, the only network that’s really had a lot of problems in recent years was, ironically, the only one that carried the iPhone in the US: AT&T.

There’s no question that the iPhone brought customers to AT&T, and little question that the iPhone is the only reason AT&T is still #2 in the US. Anecdotally, I myself switched to AT&T (from T-Mobile, which I was quite happy with) specifically to use the iPhone.

Now that the iPhone is coming to Verizon in a couple of weeks, it will be interesting to see how this changes things. But I am sure there are still customers who are loyal to Sprint or T-Mobile (or other carriers) who will choose an Android phone to avoid switching to either AT&T or Verizon. (And then of course there are the AT&T iPhone users who plan to switch to Verizon as soon as their contracts are up. But that’s for another post.)

Android is “open.” I say “open” in quotes because there has been plenty of discussion (just google “Android open site:daringfireball.net” for a taste; here: I did it for you) about how Android’s open licensing really just means it’s open for carriers to load up with crapware that can’t be uninstalled; or open to exploitation by hackers, viruses and privacy-invading stealth apps. But I’ll acknowledge that it is, also, open — to some extent — in the way its champions mean: users are not inside a “walled garden” as they are with Apple’s iOS. You can install apps freely, bypassing any officially sanctioned “app store”*, and you can tweak the system to your heart’s — or at least your carrier’s heart’s — content. But most users do not want to tweak their systems. They want something that just works, that they don’t have to think about, and that they are not afraid they’ll break. Which leads to…

Recommendations from “tech experts.” In other words, non-techie people asking their techie friends or relatives which phones they should buy. And here’s where we get into the territory where I see relevant analogies to the Mac vs. Windows era of the ’90s. Imagine a person who doesn’t know anything about smartphones but who is interested in entering this slightly daunting new world of technology. They have a friend or relative who they perceive as a tech expert — the person they’d call 15 years ago for help hooking up the free Lexmark printer that came with their new Gateway PC. Which they bought because they asked the same tech expert what kind of computer they should get. Today, that tech expert may be the main reason this person ends up with an Android phone.

The point here is: “tech experts” have different needs and different goals with technology devices than “average” users. They’re not afraid of getting “under the hood” of the system — in fact they want to do that — and they have little understanding or patience for people who don’t get technology. (Trust me, aside from my preference for Apple products, I’m there myself.) But both because of a general disdain for whichever technology they don’t use, along with a very real understanding that in making this recommendation they’re, willing or not, committing themselves to providing ongoing support, the tech experts are most likely to recommend whatever platform they’re most familiar with.

This is one of the reasons so many tech novices bought Windows computers the first time around, and I can see a very real possibility that this will be a factor in the growth of the Android platform, especially among new and technically inexperienced smartphone buyers.

But there are definitely some differences. First, I think Android represents an even more technologically remote territory for novices than did Windows in the ’90s. It’s more like the DMZ between Windows and desktop Linux. And aside from the staunchest supporters, few reclusive, bearded übergeeks are still trying to convince their grandmothers to run Linux on their home PCs. Second, technology isn’t as intimidating as it used to be. Computer use is far more widespread now, and getting into a smartphone after already learning (or, well, sort of learning) to use a computer is comparatively simple.

And finally, we come back to Apple. Apple is not in the position it was in back in the ’90s. For one, Mac market share has grown considerably, especially in the US, along with the growth of Apple as a general consumer technology brand. The success of first the iPod, and more recently the iPhone and iPad, has translated into success for the Mac. (Check Horace Dediu’s asymco blog if you need numbers and graphs to back that up.) Most importantly, more “tech experts” are now using the Mac than ever before. Part of this is because at its core, Mac OS X is Unix-based, just like Linux**. Which is a big part of why desktop Linux is doomed (again, a topic for another post). And as more “tech experts” become familiar with the Apple ecosystem, they embrace iOS devices along with the Mac, and they recommend iPhones to their friends and relatives who ask them for help.

So… where does that leave Android? I see all three of the above rationales for choosing Android over iPhone as diminishing in importance… some much more rapidly than others. I especially see the effects of #1 and #3 diminishing together, especially once the iPhone comes to Verizon next month. I’ll say it more explicitly, with extra emphasis: I expect Android to take a huge hit once the Verizon iPhone becomes available. I’d go so far as to predict that within a matter of months — certainly before the end of 2011 — the number of Verizon iPhone users will be as much as 10 times the number of Verizon Android users. Compound this (likely) huge and sudden impact with the ongoing effect of #3, and it paints a pretty clear picture for me. I think Verizon’s iPhone commercial says it all. The iPhone on Verizon is what people have really been anticipating all along, not an “iPhone killer” Android phone from Verizon. Verizon knows it.

Of course, all of this doesn’t mean Android will go away, nor should it. Ongoing competition from a strong alternative like Android is (probably) essential to keep Apple on top of their game. But I see two main (and increasingly marginal) reasons people will continue to choose Android over iPhone: either they are on Sprint or T-Mobile and don’t want to change, or because they are hardcore tinkerers who will never be satisfied with the kind of controlled operating environment Apple offers. But for everyone else, the choice is about to become a whole lot more obvious.

As Marco Arment insightfully observed, the primary choice has been iPhone vs. (Android on) Verizon. Now users will have more options, with iPhone and Android (and Windows Phone 7) available on both AT&T and Verizon. But I think the choice is mainly going to become AT&T vs. Verizon, with the implication being that it’s (probably) the iPhone on either network. And since Apple has ensured that the carriers can’t significantly differentiate the same device with apps or features, the way they do with other manufacturers’ phones, it’s really all going to come down to the network. AT&T is probably going to take almost as big of a hit as I anticipate Android taking.

That too is a topic for another post.


* Registered trademark by Apple pending.

** Yes, reclusive-bearded-übergeeks, I know neither Mac OS X nor Linux is technically Unix. But the difference is irrelevant to everyone but us.