Tag Archives: Apple

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…

Bracing for the HD web

Joshua Johnson has an excellent new post over on Design Shack called Ready or Not, Here Comes HD Web Design, discussing adapting your web design techniques for the imminent HD revolution, being led by the new iPad.

I’ve been adapting my designs for the Retina Display on the iPhone 4/4S for a while now, but it’s easy enough to build a responsive web design that just shrinks down large desktop website images to half their size for display on a tiny iPhone screen. Making an essentially desktop-sized display support high-resolution graphics is a whole other story, and even though I knew (or presumed, along with the rest of the world) that a Retina iPad was coming, I think some small part of me was still in denial about what it would mean for web design.

Well, that future is here. Sure, most of the world is not browsing the web on a Retina Display iPad. But if you think the HD revolution ends there, think again. It’s just getting started. I’m about to enter the implementation phase on a handful of big web projects over the next month. Accommodating the new iPad’s display is going to be one of my top tasks.

I’ve been thinking for the past month or so that I was going to need to address this, and I’ve made the decision that, moving forward, on any site that has responsive web design as a component (which will probably be all sites I do), full-size “Retina Display” graphics are essential.

I posted a comment on Joshua Johnson’s post, where I noted that “Retina” (or, to avoid using Apple’s marketing term, “HD web”) graphics don’t really need to be 326 pixels per inch (ppi), the iPhone 4/4S’s resolution, or even 264 ppi, the new iPad’s resolution.

The standard practice with web images has always been to render them at 72 ppi, but the fact is, browsers don’t care what resolution an image is set to. A pixel is a pixel, and web images get displayed at the screen’s native resolution (unless, of course, you resize the image dynamically in the browser using HTML dimension attributes or CSS). The Retina Display approach Apple uses is to simply double the resolution (quadrupling the number of pixels). Web images by default get “pixel-doubled” in this scenario, displaying at the same relative size as they would if the iPad still had a low-res display, but appearing pixilated or blurry as a result.

You don’t need to render your images at 264 ppi for display on the new iPad. In fact, you can leave the resolution at 72 ppi, because the browser still doesn’t care. (Well, maybe it does; I haven’t actually had an opportunity to test it, but I strongly suspect the answer is no.) You just need to make the pixel dimensions of the image twice what they were before. In fact, even if you do change the resolution, you still need to double the dimensions. That’s the key.

After mulling all of this over for the past week, I’ve decided I’m going to have to get a new iPad (what a hardship, I know). I could technically do this work without it, but I think it’s important to be able to see what I’m producing, if for no other reason than to remind myself how important it is.

This is going to be an ongoing process, and because web design (or, more accurately, web design implementation — I usually work with designers who produce the initial UI in Illustrator or Photoshop) is only one part of my job, I can’t give it my undivided attention. But it’s something I am preparing now to immerse myself in as fully as possible. From now on, this is just how I do things. And with that in mind, there are some key points to consider:

1. Some images are more important to represent high-res than others. Logos, absolutely, 100%. Design elements that are on all pages (backgrounds, borders, navigation) come next. One-off photos are not as critical, but probably still are if they’re on the home page. But consider the next point as well.

2. Bandwidth is a concern. I’ve been somewhat dismissive of this up to now, as I’ve been focusing on high-res logos for the iPhone’s Retina Display — it can just take the regular web images and show them at half size to achieve high-res — but if you’re suddenly talking about downloading 4 or 5 high-res photos for a home page slideshow, it’s going to be a problem. Making users with standard resolution download unnecessarily large images is bad; making iPad users eat up their 4G data plan downloading your perfect-looking photos is bad too. Most of the attention paid to bandwidth in this discussion that I’ve seen so far has focused on the former, but both need to be addressed.

3. CSS and SVG. Joshua Johnson talks about this in his post. If we can render elements using CSS instead of images (things like curved corners, gradients, shadows, etc.), we should do that. More complex vector graphics can be displayed in SVG. All modern browsers now (finally) support SVG. Up to now it’s been a cool but essentially useless technology, due to lack of widespread support. But IE8 and earlier don’t support SVG, so if those browsers matter (and unfortunately they probably still do), you need a backup plan.

It is an exciting time to be working in web design and development. More and more, the challenges center around adapting your techniques to take advantage of cool new features and capabilities, not accommodating the limitations of crap browsers. But they’re still challenges, and we’re just beginning to discover their depth, along with their solutions.

Update: Over at Daring Fireball, John Gruber just linked to Duncan Davidson’s post detailing an issue with WebKit (the rendering engine inside Safari) automatically scaling down images above a certain size, specifically over 2 megapixels. Looks like sending huge, high-res images to the new iPad might present even more challenges than the ones I’d been considering.

I still don’t have that new iPad, so we’ll see what happens when I get it. (Tomorrow?)

Update #2 (March 25, 2012): A few more days have passed, and more has been learned on this topic. Duncan Davidson has a follow-up post that further explores the issue and a tentative path forward.

P.S. I did get that new iPad, and Duncan’s demo of an 1800-pixel JPEG on the iPad’s Retina Display is truly impressive. But what I find really interesting about it is that the 1800-pixel version of the photo looks better than the 900-pixel version even on a regular computer display… because, as I’ve observed, WebKit downscales images better than Photoshop does.

What could Apple buy with $100 billion?

In less than an hour, Apple is holding a conference call with the press to announce plans for its vast stockpile of cash, currently approaching $100 billion. What could they do with all of that money?

The most likely (and boring) suggestion is that they’ll start paying dividends to their shareholders. Bolder predictions include buying one of the cellular carriers (can you imagine Apple owning AT&T?) or possibly even Google. (OK, I don’t think I’ve actually seen that one, but I think they could do it.) Or, if they were Dr. Evil, they could hold the entire world ransom.

But let’s have a little fun, shall we? Here are some other things they could buy with $100 billion:

  • A large supreme pizza for every person on earth
  • A new stadium or arena for every team in the NFL, MLB, NBA and NHL
  • The entire GDP of Morocco
  • 500,000,000 iPod touches (“iPods touch”?)
  • Over 41,000 of the most expensive car on earth
  • 6,200,000 of the most popular car

Or, they could just give every person in America $320.93. Or pay off 0.64% of the national debt.

Mountain Lion. Clever?

Apple just announced the next version of (Mac) OS X: Mountain Lion. And they did so in an rather unusual fashion. Grubes has the scoop:

The recurring theme: Apple is fighting against cruft — inconsistencies and oddities that have accumulated over the years, which made sense at one point but no longer — like managing to-dos in iCal (because CalDAV was being used to sync them to a server) or notes in Mail (because IMAP was the syncing back-end). The changes and additions in Mountain Lion are in a consistent vein: making things simpler and more obvious, closer to how things should be rather than simply how they always have been.

But a lot of the chatter (chirping?) on Twitter concerns the name:

I “get” what Apple’s doing with the name. Mountain Lion (10.8, presumably) is to Lion (10.7) as Snow Leopard (10.6) was to Leopard (10.5): a refinement, a continuation of the same direction in OS X’s evolution as the version that preceded it.

But it is rather odd, if you think about the actual cat names involved, especially since a mountain lion is essentially the same thing as a cougar, also known as a puma or… a panther, which Apple already used as the “big cat” codename for Mac OS X 10.3 way back in 2003.

Beyond that, Lion always seemed like something Apple was building up to… the “king of the jungle.” That version 10.7 was named Lion seemed to suggest the “big cat” lineage, version 10.x of Apple’s Mac OS, and perhaps even the “X” (which is pronounced “ten” after all) was done. And here we have… Mountain Lion? A decisive step backwards in the awesomeness of the big cats. Heck, mountain lions have even been spotted here in Minnesota for crying out loud!

So… anyway… I think the point is: Apple is not taking this whole “big cat” thing too seriously, and neither should we. Mountain Lion looks pretty great. I can’t wait to try it out!

Update: After some research, it turns out Apple already used Puma, too, for 10.1. But as I recall, they didn’t start using the big cat codenames in marketing until 10.2, Jaguar. And I still have the Jaguar mousepad on my desk to prove it!

Apple’s skeuomorphism reconsidered

I was just looking at the much maligned skeuomorphic interface on iCal in Lion, and trying to decide why it doesn’t really bother me that much. I think I figured it out.

It’s inconsistent with other windows, but the objects on a real desk don’t all look alike. I’ve observed novice computer users, even today, struggle to differentiate windows on a standard computer desktop. They can’t tell which window is active; they can’t tell windows apart; they don’t know the difference between different applications or whether a given app is still running without any windows open or not.

In short: a lot of people still don’t understand the GUI, and never will. And, kind of like I wrote yesterday about Kevin and Robert California, whose fault is that? The user’s, or the interface designer’s?

iCal may look out of place, but there’s no mistaking it in the jumble of overlapping windows, just like there’s no mistaking a particular physical book in a big pile on a cluttered desk.

The arguments for or against skeuomorphism are completely different on iOS, of course, where there’s only ever one app on the screen at a time. But I think the HIG zealots and Magritte maybe need to get over themselves a bit, even if iCal makes all of us want to tear those little bits of paper off.