Nokia Is Keeping Things Interesting

Stephen Elop, CEO @ Nokia

Nokia announced today it was making Windows Phone its primary smartphone platform. If you look at the Nokia stock price you might guess that the company just made a fatal mistake.  But, that’s probably far from the case.

Gartner says Nokia currently has about 37% of the smartphone market share, and Microsoft has about 4%.  Two turkeys may not make an eagle as Google’s VP of Engineering, Vic Gundotra, quips but if Nokia can keep the numbers that high with Windows Phone, they’ll make a lot of turkey dinners for a lot of people.

Supper Is On the Table. Eat While the Food Is Hot.

My attitude toward mobile development is this: any platform, any mobile device, any market, any time. If you’ve locked yourself into a single platform you tend to get worried if your mobile platform of choice isn’t king.  I avoid that trap completely by mastering as many platforms as humanly possible.  If it computes and you can hold it in your hand or embed it, I’m interested in it.

With Nokia/Microsoft blending forces, it feels as though me and my clients just gained a few billion potential customers.  Hey – the more mobile marketplaces and platforms for me to write software for, the better.  Nokia and Microsoft in effect are going to open up more mobile software markets globally.  Nokia already has a very strong global distribution and sales network for cell phones.  And both companies have the ability to host and manage vibrant mobile software marketplaces to the world’s masses.

I know that no matter what, regardless of the platform that’s “hot”, I can literally turn around in my chair at work, look at my co-workers and know that a software product can be written for it.  I work daily side by side with crack iPhone and Windows Phone developers.  As a team we round out quite an option for people wanting to get mobile software written: Android, iPhone, Windows Phone, Blackberry, WebOS, Symbian … you name it.  Including devices that aren’t even on the market yet.  Elop and Balmer hinted at their future hardware platforms as well, but that’s another story.

A 100,000 Cooks Are About To Show Up.

In working with Nokia, Microsoft will garner the focus, over time, of more than 100,000 Nokia workers who will want to keep Windows Phone alive.  They’re going to keep the Windows Phone software marketplace alive as well.  And that’s a good thing all around.

And to Elop’s credit, he hasn’t handed the keys to the kingdom over to a Microsoft platform completely.  Nokia is going to keep its own projects like Meego and Ovi alive.  Who knows ….

we may even see a version of Qt available for Windows Phone in the near future.  Now that would be pretty cool.

Why Nokia and Microsoft, You Ask?

That was seemingly a big question revolving around today’s press conference, and David Murphy from Mobile Marketing Magazine asked just that at four minutes, eight seconds (04:08) into the presentation.  Why not Android, he simply asked.  Elop had an answer of course, but it was just as telling about Google as it was about Nokia’s hardware platform.  Elop had this to say:

If we tipped over into the Android ecosystem and there was a sense that that was the dominate ecosystem at that point, the commoditization risk was very high:  prices, profits, everything being pushed down.  Value being moved out to Google essentially which was concerning to us.  So the Microsoft option represented to us the best opportunity to build and lead and fight [emphasis his] through a new ecosystem that we take into the marketplace.  Remarkably complimentary assets that in totality is going to offer consumers tremendous choice and a great option in the marketplace.

This tells me a couple things which I was surprised about, and which Elop and Balmer reinforced at various points in the discussion.

First, Nokia simply seems to have gotten a better deal in working with Microsoft.  There were concessions made on both sides.  Yes, Nokia is going to pay licensing fees to Microsoft for the platform.  But at the same time, there seems to be an arrangement worked out where Microsoft will be also sending money back to Nokia to get access to Nokia’s hardware and software innovations.  Very interesting.

Second, “Remarkably complimentary assets” to me is a code phrase for “Nokia knows its hardware stack limits its choices of OS.”  Nokia can’t afford to choose an OS that won’t possibly work on it’s limited hardware stack.  That would be worse than anything.  I’m grasping at straws here, but it’s possible.

Turkey Dinners Are O.K.  But TurDucken Is Just Wrong.

Put the wrong OS on Nokia’s hardware (current or planned), and you’re likely to get something equivalent to turducken.  Something that technically can be made but just plain sucks.

TurDucken

Elop seems to recognize that Nokia is forced to put a new operating system on its hardware now, and I mean right now, that will function and function well.  It’s very possible that the other platforms Nokia was considering would have demanded too much performance out of Nokia’s hardware to run.  An entire software ecosystem after all, demands a lot of a mobile device.

Whenever I hear an executive at a cell phone OEM speak about fitting a complimentary OS on top of the available and planned hardware, it tells me that the executive is aware of the limitations of his company’s hardware.  That’s pretty smart and realistic.

Time will tell if all this is the right decision.  As for me, I’m just glad to have another mobile marketplace to write software for.

—-

Image sources: wikipedia, newsmild.com

Today’s Awkward Design Award: Skype

It may be new, but it can still be awkward.

The Awkward Design Award is something I arbitrarily award to companies and people who have design features in their software products that make you feel like you’re wearing underwear that’s too tight.  You might be able to live with it, but it could be better.

Nobody is spared.  If I don’t like it, you might earn the award …  whatever “it” is.  At least I’ll tell you why.  I used to call this The Bad Design Award, but that’s too harsh.  I want to encourage companies to simply re-consider some of the decisions they made.

Today’s Award Goes To …

Skype

There are many golden rules in software design that all good products adhere to, and if there were an  official list, these would be in the top ten:

1. Never save a file for a user to access later unless you tell them what directory it’s in.

2. Always allow the user the option of changing the directory where files are saved in.

3. Never ever, ever use GPS in an applicationunless you absolutely need to and you tell the user why.

Here’s why I give Skype the Tight Underwear Award:

Never save a file for a user to access later unless you tell them what directory it’s in.

When you take a video snapshot in Skype, the application saves the picture somewhere, but the directory it’s saved in is a mystery – at least in Windows Vista.  You have to hunt Skype help and peoples’ blogs for the information, and get nothing.  At least I haven’t in the case of Vista.  The point is … you shouldn’t have to hunt the blogsphere in the first place.  No, I’m not going to tell you where the files are saved saved.  I don’t know precisely.  That’s the point.

Always allow the user the option of changing the directory where files are saved in.

It’s bad enough that Skype doesn’t tell you where it saves your pictures or gives you the option of copying them to a familiar directory.  Oh no.  They have to leave out the option of letting you set the directory where you can save the pictures.

Never ever, ever use GPS in an application about a user unless you absolutely need to and you tell them why.

This reason for the bad design award applies to Skype’s mobile application.  I installed it on my Android … once … and used it … once … before I uninstalled it.  And that was only because I had to join a Skype instant messaging session while on the road.  There’s no reason in the world why Skype would need to get your GPS location to use the product.  You’re either on the network or not.  You’re either able to make a Skype call over the network or not.  I don’t want Skype or anyone else to collect information about where I make that call or write instant messages from.  None of your business thank-you-very-much.  This flies completely in the face of the security features of Skype which encrypts your messages across the network and only sends them point to point (and not through a skype server).  Who knows, perhaps the mobile application does that too.  I haven’t checked.

Image credits: thecarconnection.com

Nokia’s Precipice

February 10, 2011

Nokia stands in a tenuous spot.  One thing the company does well: make cheap cell phones for the masses.  That should never be underestimated.  It’s a very important part of the cell phone market.  The value of cheap, programmable cellular devices should never be underestimated.  Current smartphones have lots of overpriced, “value added” features as well.  That’s an opportunity Nokia is in a position to take advantage of.  A phone platform just as good as the iOS or Android that sells for half the price would shift the entire market drastically.  And to its credit, Nokia phones were well ahead of their time when they were first released years ago.  So, Nokia is no stranger to this dynamic.

Elop is right though.  Nokia stands on a precipice.  A critical one.  It has to play ball or pack up and go home.  I doubt he will have Nokia do the latter.  So, then, what to do?

They answer may lay in a simple realization: any platform Nokia adds to its current product line is a step in the right direction.  It just can’t be a half-baked attempt.  The hardware stack of Nokia’s phones has to improve too (faster processors, better networking, different form factors, etc.), and it has to be a hardware stack that Nokia can protect.  That takes true innovation these days.

Simply adopting a brand like Windows Mobile to run on old hardware obviously won’t do. That would be a disingenuous way to satisfy certain stakeholders with a nice sounding story.  It wouldn’t pass due diligence tests as a sound decision in the mobile software engineering and product design communities anyway.

As a long time engineer who has worked in this industry since the pre-birth of the Internet, I can say this: Nokia has to take the attitude of any platform, any software ecosystem, any time.  Continue to innovate the hardware stack, be creative, and tune those platforms and software ecosystems to run better on that hardware than any other product offering.

Why do I think that? I actually interviewed at Nokia a few years ago.  I knew the science and the work of the position I interviewed for but I didn’t get the job … simply because I didn’t know enough about the internals of the Nokia platform.  That can only mean one thing.  Nokia’s management has corralled its engineering talent into a myopic immobile work force.  I’ve met some of those engineers at conferences, and they are smart.  But, does Nokia have the management willpower and culture to cut it’s engineers and researchers loose to innovate freely?

Fortunately Elop has recognized that Nokia does face a management and corporate cultural challenge more so than an engineering challenge.  The Wall Street Journal today said it best (p. B5) when it quoted a telecom recruiter:

To truly revive Nokia’s market clout, Mr. Elop should hire smart, creative executives “who understand what it means to disrupt” the norm …

Android, iPhone, and to a lesser degree Microsoft’s mobile platform are the norm.  WebOS has a fighting chance.  That’s the norm today.  Disrupt it.

Notice that none of the press lately, including the Wall Street Journal has talked about the engineers.  Obviously, Elop is setting the stage for change, and Nokia overall doesn’t have “an engineering problem.”  Nokia has the engineering talent and the cash to do what Apple and Google has done many times over.  That talent can simultaneously embrace multiple platforms and take a leadership position through innovation.  Or, they can completely re-invent mobile platforms in unique ways that are open.  Or they could do both.  There’s nothing restricting Nokia to build an open platform as an answer to Android … one that doesn’t suffer from the threat of lawsuits waged by companies like Oracle.

That’s one hallmark of successful smart phone OEMs in the market today … the ability to give engineers the leeway to take bits of hardware and do something with it that’s innovative – the ability and culture to invent new technologies that give us what we don’t already have and take things into new directions.  Another trait of successful smartphone OEMs: the business savvy to get those innovative products into the retail outlets that are the mobile carriers.

Don’t forget, it was the iPhone’s innovative touch screen, a focus on hardware/software quality assurances, and software ecosystem that helped propel that phone to the dominant position it has today.  It was The Beatles of the phone world.  It bridged cultures.  And, it was the deal with AT&T that gave the phone a fighting chance to get into the hands of consumers.

Nokia faces some critical choices in these regards.  Does Nokia create new hardware technologies that make the feature phones more powerful and reliable?  Or, does it try to cram more and more features onto a resource limited hardware stack and risk it all under-performing?  Can it make profitable deals with carriers at the same time?

Nokia will be fine if it makes wild creative decisions, takes chances, involves creative genius from outside the company, and pushes its innovations to market quickly.

Copyright reminder: all contents of this blog may not be reproduced in any form.  This blog particular blog entry: Copyright 2011 by the author.

Android Screen Density Inaccuracies

Android OS brought a cutting edge approach to mobile development: handle differences in device hardware by standardizing pixel sizes at the application layer.  If you’ve ever worked on Blackberry devices you will know how much of a problem it can be without such a concept in a mobile OS.  Apple avoided this problem all together by only releasing one phone model at a time (as opposed to opening it up the platform to any manufacturer.

The idea is this.  Developers and graphics designers can rely on defining graphics for Android using one of four standard pixel density sizes:

  • low density (LDPI): 120 DPI
  • medium density (MDPI): 160 DPI
  • high density (HDPI): 240 DPI
  • extra high density (XHDPI): 320 dpi

This means that regardless of what device you target, you can start graphic asset design on an Android by specifying asset sizes in inches.  From there, you can figure out how many pixels each graphic asset needs for the screen density of the phone you’re targeting (note: density is not the same as screen size – that’s another discussion).

This is particularly important, because as every mobile graphics designer ultimately realizes, using native pixel size in your graphics specifications will result is wild results on the screen when the assets are displayed.  A graphic of 160 x 160 native pixels will look one way on a particular screen, bigger on a lower density screen, and smaller on a higher density screen.  Throw in the mix the fact that many phones’ physical screen sizes differ by fractions of an inch and you quickly see your nice screen designs morph into a nightmare.

But, for all the good standardized screen densities do, OEMs still don’t follow the letter of the law when it comes to API behavior.  Debbie Hackborn recently explained this on a posting over at the Google Android Developer group:

How to get screen density in pixels-per-inch or equivalent

In short, she explains that many Android phones don’t accurately provide the number of pixels per inch.  She goes on to explain that a device is more likely to have a screen density that is higher than it’s real DPI measurement rather than lower.

Here is her first posting on the matter (Jan 12, 2011 – see link above):

The density and densityDpi is an abstract density bucket the device manufacturer has decided makes sense for their UI to run in.  This is what is used to evaluate things like “dp” units and select and scale bitmaps from resources.

The xdpi and ydpi are supposed to be the real DPI of the screen…  though as you’ve seen, many devices don’t set it correctly. 😦  This is our fault, it isn’t actually used anywhere in the platform, so people don’t realize they have a bad value, and we haven’t had a CTS test to try to make sure it is sane (it’s not clear how that test should work).  Worse, we shipping the original Droid with a graphics driver that reports the wrong value here… in fact that reported that same damnable 96.

Unfortunately, I don’t have a good solution if you want to get the real exactly screen dots per inch.  One thing you could do is compare xdpi/ydpi with densityDpi and if they are significantly far apart, assume the values are bad and just fall back on densityDpi as an approximation.  Be careful on this, because a correctly working device may have densityDpi fairly different than the real dpi — for example the Samsung TAB uses high density even though its screen’s really density is a fair amount lower than 240.


Dianne Hackborn
Android framework engineer

And her second posting in the same thread, and with it we see a concrete example by another poster (his quotes marked with ‘> ‘):

Well a device is more likely to have a density that is higher than its real dpi rather than lower; making it higher makes things UI larger and thus more readable and usable, while making it smaller quickly makes the UI so small that it doesn’t work.  I wouldn’t want to go any lower than what you’d see on say the G1, which is 180dpi and uses the mdpi (160) density. At any rate, the whole point of density is that it is not directly tied to the real screen dpi.  It is quantized, so that there are a limited number of densities applications need to deal with.  Manufacturers have some flexibility in picking it based on the feel they want for their device.  In the case of Samsung, they wanted a larger more easily touched UI.  Others may want the same thing, for example to make it easier for people who have poor eyesight to use their device or whatever other reason.

> I’ve [another poster] also just looked at my AC100 (Tegra 250), and it reports xdpi =
> 160, yet the correct value should be about 120.
>  As you say, this seems to be completely broken, and the Tegra example
> shows that 96 cannot be used as a sentinel for a wrong value.

Well fortunately that one isn’t a compatible device so won’t have Market. :} Out of curiosity, what are you trying to do?  I know you said you are trying to display a ruler, but what exactly do you want it to be used for?  Just for people to hold stuff up to it to measure?

One of the reasons the devices haven’t been good in this regard is because after introducing these APIs, we have never actually found a single place in the standard UI where they should be used, so nobody realizes they are shipping with bad values.  *sigh*

Dianne Hackborn
Android framework engineer

What does this mean to those of us working on Android phones?  Even if you adhere to the standardized pixel dimensions identified in the Google Documentation (see http://developer.android.com/guide/practices/screens_support.html), you’re likely to see small variances in graphic asset sizes when they are displayed.

This makes pixel perfect alignment of screen shots during the Quality Assurance (QA) phase of application development difficult.  While most implementations of the Android OS will display the same graphic exactly the same size, there’s always a possibility that many wont.

The solution I advocate: when doing quality checks, always allow for this variance from phone to phone.  Don’t waste time trying to make things 100% perfect when it comes to asset sizes.