Why Gruber may be wrong re: “Smartphone Mojo”

John Gruber wrote a rebuttal of sorts to a piece in The Nation about the iPhone “losing its Mojo” against the ever-growing wave of Android devices.

Gruber did point out (correctly, in my view) that the iPhone does attract the more valuable segment of customers, and so they can still do well with a smaller share of the market because they have the customers that matter.

One comparison I found a bit less convincing was when he talked about how iPhone “was never the smartphone market share leader” being behind Symbian and BlackBerry (while still having a superior ecosystem to the companies with larger shares of the pie).

I don’t think that is relevant to Apple’s situation vis-a-vis Android. See, BlackBerry and Symbian were not at all into the whole “ecosystem” thing. Symbian (pre-Qt) and BlackBerry (pre-BB10) developer platforms were technically rough and a headache to develop for. The powers that be behind Symbian and BlackBerry OS weren’t working furiously to match their market size to a developer platform from a technical or business perspective. The difference between Apple building a superior ecosystem with smaller market share then (vs Symbian and BlackBerry OS) and now (vs Android) is that Google has done (and continues to do) spectacular work in recognizing the importance of a developer ecosystem and building the technical and business supports for that ecosystem.

Apple has never been in a situation in which a competitor held considerably larger market share and put just as much effort into its developer platform/ecosystem as Apple did.

Well, that’s not entirely true. Apple did face a competitor like that before. It was called Windows.

image credit: FTD.de

Apple didn’t do so well when a competitor combined a real ecosystem effort with bigger market share. Nearly killed ‘em, actually…

About these ads

Instagate: Put up or Shut Up

Okay, technical elites. You’re the ones who are the most upset over Instagram’s policy changes. You’re also the most technically able to build new things, and wield influence over others (so you say, anyway) to change how we do things.

Well, you self-styled leaders, it’s time to lead. How about you actually stop using Instagram and start using something else? Put up and do something, or shut up and bow your heads down in servitude/while aiming your iPhone at your food to take another picture of it

Metro++ | Is that text clickable or not?

In what will hopefully be the first of many “Metro++” blog posts on improving the Metro experience, I wanted to focus on discoverability of functionality. One of the weaknesses in Metro as it now exists is that the emphasis on typography instead of chrome means that it isn’t always clear when any particular piece of text is meant to be clickable and do something, and when it is meant to simply be read. This has two negative consequences:

  1. Users will miss functionality by not knowing some text chunks are clickable, which is a Bad Thing
  2. Once they grasp that some text is clickable, they will try poking (or if using Metro with a mouse, clicking) all over all the time to discover the Metro app’s functionality by trial and error—which at least works, but isn’t particularly elegant, and would be seen as a downgrade compared to iOS and Android which better delineate between clickable text elements and non-clickable elements by making the former more button-like

Case-in-point. I only accidentally discovered that header was clickable

Now, how can Microsoft (or an OEM with some significant rights to customize the OS) solve this problem?

  1. Redesign the entire OS. No.
  2. Delineate between clickable and non-clickable text with additional graphical elements. In the Metro UI guidelines, MS shows how to make a clear distinction between graphical elements that serve as buttons and those that don’t: Put them in a circle or a box. A circle/oval would be impossible and look out of place. A rectangle around actionable text would work, but add a lot of clutter, especially if there is a lot of actionable text. So…No, but getting warmer.

What it would look like to button-ize everything: a cluttered mess

I think the solution is right under our nose…or somewhere between the nose and the screen. I am of course referring to smell-based computing the hover!

Crafting Hover

Hover (or onMouseOver) rose to prominence in the early-ish days of the WWW as a mass phenomenon. HTTP websites were a new concept for millions of people accessing the Web for the first time, and much as in Metro today, there was some confusion in what text was clickable (this can still be witnessed today by watching your parents trying to navigate the Internet). This was solved in two ways:

  1. When the cursor was on top of something actionable it turned into a pointer finger
  2. When the cursor was on top of a UI element (such as a nav menu) that was actionable, the element would change color or to another graphic thanks to the power of this newfangled thing called JavaScript

Of course both of those relied on a cursor, which doesn’t exist in a touch interface. Can we make an equivalent of this “I’m here, but not clicking on it” function in a touch screen?

YES WE CAN*

*with the help of some clever capacitive technology

Capacitive touch screens work by sensing a disturbance in The Force the electrical field around the screen, not just at the immediate glass surface. It is actually entirely possible to sense a finger wandering around above the screen without actually touching it, as Sony recently demonstrated with “floating touch” in their Xperia Sola. And so it is possible to have mouseOver effects in the Metro interface! When the finger is near a clickable block of text, that text could highlight itself in a number of ways, but I think 2 good ones would be:

1. Underline, a la IE in the late 90s

OPTION 1: Underline on mouseover

2. A glowing effect around the actionable text

Option 2: Glowing effect on hover

Any of these would address this discoverability shortcoming in Metro, and also look pretty darn cool and futuristic, which helps sell devices at retail, and adds another layer of sophistication in human-device interaction that would make iOS and Android look a bit dull by comparison. Also in Metro, an added bonus is the ability to have graceful degradation from Touch to Mouse, since the onHover signals can just as well apply to MouseOvers. So, that’s what I’d like to see. Get to it, Microsoft!

Metro++

Metro++

I love Metro. It’s clean, fast, refreshingly different, and beautiful. But that doesn’t mean it is perfect. I hope to write some blog posts on how I would improve Metro, and the Windows (and Windows Phone) experience.

In full disclosure, I am an employee of Nokia, the premier partner of Microsoft when it comes to Windows Phone. While I have the privilege of working with many teams on many exciting projects throughout the company, I do not work with our design teams, and if there is any suggestion I make that happens to be in a future Nokia product, it is a pure coincidence (although if Marko Ahtisaari/Peter Skillman/Kevin Shields want to drop me a line they are welcome to ping me on Lync J )    

 

A Modest Proposal: Google, Take My Money

Hey Google.

How are you? I’m doing fine (but then again you probably knew that already from all the data you’ve collected on me).

That’s what I wanted to talk to you about, actually.

Google, as you continue to make it easier for us to be tracked all over the Internet (and harder for us to opt out), it seems to be dawning on more and more people (though I would say far from a critical mass by any stretch) that the Google we all know and love is steadily creeping away from its original mission of simply being the world’s best search engine.

I’m not going to ascribe this to some sort of evil intent as others seem to be all too happy to do. I get (and rather love) capitalism, and understand you need to make money to continue existing. I understand that it costs money to build and run your awesome Internet services (I for one am particularly dependent on Gmail, contacts and calendars—all of which work swimmingly with my Nokia Lumia, thanks for that btw).

Right now the only currency I can use to pay for most Google services is myself—my eyeballs and my data, which are worth a certain monetary amount to you. Let’s eliminate the middle-man (advertisers) and let me give that money directly to you. In exchange for a monthly or annual fee, you will give me the Google services I know and love with no ads, and no tracking tools behind them. You can detect my device’s useragent to ensure an optimal experience, and my location if I choose to share it with you, but everything else about me remains my business and nobody else’s. I get a better service—cleaner, and without the analytics gobbletygook that is now pushing the size of a typical web page up to 1 MB, probably a good deal faster too.

Meanwhile, you get the same money you would have gotten—and possibly more if you charged a premium over what you would have made on ads (I don’t know if you make $100 a year on me now, but I’ve been known to pay that much for .Mac/MobileMe, and those didn’t even work).

Moreover, it’s not as if this were an unprecedented idea; it’s precisely how a growing number of apps work. For the typical Zynga game, there is usually the option of a free, ad-supported version and a paid, ad-free one. Apps give us a choice of pay or ads, why can’t Google? I know plenty (if not the majority) of your users don’t want to pay, and are happy to deal with ads to get Google services for free. But you should offer the option satisfy your power users. Think of it as the Android Nexus version of Google writ large.

Make Nexus premium brand across all of Google's properties.

The longer you don’t do this, the more likely it becomes that a competitor will—be it a nimble young upstart, an old wealthy nemesis, or newer and even wealthier nemeses will (or perhaps an old struggling nemesis looking for a Hail Mary?)

In short: Google, you deserve to be paid for your services. I just wish you’d take alternative forms of payment besides my eyeballs and my personal information.

Oh, and Facebook: Same goes for you.

Moving on to The Next Billion

I have made the decision to move to Nokia, effective December 19.

While I fully support Meg’s announcement to make webOS an open source project, and am tremendously excited for the future of webOS, I was given an opportunity at Nokia that I couldn’t turn down where I think I can have a significant impact.

Nokia sells more phones to more people than any company on Earth, and their corporate mission of connecting the Next Billion resonates with me personally. When I spent 2 years working in India I witnessed firsthand the power of mobile technology to transform how people from all parts of the socioeconomic spectrum worked, played, and lived–on Nokia devices more than any other. This is what gave my professional life direction, what inspired me to move to Silicon Valley and dedicate myself to mobile technology in the first place, and the opportunity to be a part of the company that started it all for me is simply too exciting to pass up. I am honored and excited that Nokia has invited me to join in their journey of connecting the world’s billions.

2011 was a year of challenges for those of us at HP, and I worked with some that taught me a lot about overcoming adversity and working under pressure. I want to thank all of them for taking me under their wing and teaching me and making my time there so memorable. The webOS community of developers, hackers, and superfans is truly like nothing else. Even though I am trading my Pre3 for a Lumia 800, webOS will always have a special place in my heart.

Now if you’ll excuse me, I have a billion people to connect…

Reading between the lines

Present Google intern (and future Windows Phone intern) Andrew Munn did us lay people a favor today when he revealed some insights into why Android phones are laggy (spoiler alert: bad engineering decisions).

But what’s interesting is that it also gives (still) more confirmation that Android was a copycat effort:

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry.

Translation: we started by aiming to copy BlackBerry.

The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

Translation: we pivoted from copying the BlackBerry to copying the iPhone.