A Great Product is Necessary – but not Sufficient – for Success

Yesterday, I posited that great marketing is simply great storytelling.

And great stories all begin with an interesting subject to frame a compelling narrative around.

In marketing, that subject is your product (for simplicity’s sake, I’m purposefully conflating products and services, to being simply the “thing” that you’re trying to influence an audience to buy – or buy into).

And while a solid and innovative product is the very beginning of crafting a compelling campaign, it is not sufficient for the success of that product in the marketplace. In fact, I would claim that great products fail almost entirely because their creators didn’t tell their “story” in a way that hit home with their audience… or they told it at a time when their audience wasn’t ready to hear that particular story.

Let’s look at some illustrative brand examples: mobile devices.

The current mobile marketplace is dominated by Samsung (Android) and Apple (iOS). But they were by no means the first companies to market “smart” mobile devices. Who were? Palm, Research in Motion (RIM, neé Blackberry), and Microsoft (in the case of Microsoft, nearly seventeen years ago)!

So – why did Palm, Blackberry, and Microsoft fail to win – or in case of Palm and Blackberry, fail to keep – hearts and minds, while Apple and Samsung (Android) now rule the world?

In the case of Microsoft, they never made the cogent case for why Microsoft CE (their first mobile smart OS) was something that consumers needed to buy. Arguably, the nascent mobile web wasn’t ready ten years ago – from a design and UX standpoint – to make CE an attractive portal for readable web sites. So in a sense, it was a combination of Microsoft not successfully pitching why the devices were needed, and the mobile web not being ready to support a new wave of mobile consumers.

In the cases of both Palm and Blackberry, you have two early market dominators who enjoyed a near monopoly – for a time – but squandered their positioning through poor leadership, lack of innovation, and the inability of each company to successfully innovate and change their product narratives, when new challengers entered their respective markets.

As a result, Palm is history (for all intents and purposes), and Blackberry is a mere shadow of its former self, all in the span of a handful of years.

So – why did Apple and Samsung (Android) succeed (ed: so far), while these other brands stumbled so badly? Because they had a larger story to tell, that was more than simply describing the specs of their product.

Apple was able to leverage a huge installed base of users in an existing ecosystem (with their captive credit card numbers in tow), tethered to their iTunes music store. They were able to tell a story of “everything just works” (true or no – it was a simple and compelling tagline).

Samsung was able to leverage the massive popularity of Android, while touting innovation over their main competitor Apple, playing heavily upon a narrative that iOS is very cool – for your parents. And, they arguably have a successful narrative around doing things “years ahead” of Apple (the phablet form factor, near field communications (NFC), contact sharing, etc.).

There are other recent examples in the mobile space, demonstrating how strong brands can fail, lacking a compelling product narrative – like Nokia; a brand that dominated the “feature phone” handset space globally, that has now virtually ceased to exist as a separate mobile brand, in no small part to idiotic “storytelling“, via their CEO, Stephen Elop, in his “Burning Platform” memo.

These examples all demonstrate that great products can fail, and fail hard – either to take root, as was the case with Windows CE, or to keep marketshare, as was the case with Palm, RIM, and Nokia – because of the lack of a compelling narrative promoting and maintaining their brands.

And, they demonstrate how a strong product stories can elevate what could have been “also ran” products, into the next generation market leaders, which is no mean feat; ask Microsoft, trying to claw their way back into mobile relevance with a very good product (Windows Phone), a superior camera (best in breed, in my opinion) – but a decidedly muddled marketing story.

We’re about to see a similar battle engaged anew, with the announcement of the new Apple Watch. Will Apple be able to create a strong enough narrative as to why their new product is more compelling than the Samsung Gear, the Moto 360, or the Pebble, to possibly create a new market leader?

If past is prologue, I wouldn’t count them out.

Tomorrow, I’ll discuss how a brand’s voice is essential to telling a great marketing story.

When Your Baby Is The Ugly One

This scenario plays itself out repeatedly:

Company A releases a great new mobile app. Initially, it runs on only mobile OS X.

Users of mobile OS Y decry how epic this FAIL is on the part of Company A, how clueless they are, and how they are totally missing the boat and losing their business.

Wash. Rinse. Repeat.

Trust me – companies don’t go out of their way to NOT service their customers and consumers.

These decisions are based upon market share, money on hand, time to market, and availability of manpower to build product.

In short, it’s business.

For the most part, this script usually translates as: Company A releases an iPhone app, initially. Users of Android, Blackberry, Palm, etc. are unhappy that they are being slighted. They think the company doesn’t value them.

In fact, the company is probably coping with a small set of developers, looking to get the biggest initial bang for their constrained development resources, and has every intention of getting their product on these other platforms, as time, resources, and money permit.

Apple’s ability to allow consumers to discover new applications is superior to what Android and Blackberry offer. I’m sorry. It just is. You can’t browse the Android Market or the Blackberry App World from your laptop to discover apps. You can with the App Store. Therefore, the chances for new consumers to discover, disseminate, and advertise your new app are greatly multiplied by releasing an iOS version, first.

Again, this is a business decision, not a straight-up fan boy love affair.

Yeah – it totally blows to have to wait for something the other cool kids are playing with now (hear that Twitter? Still waiting on “new” Twitter. Le sigh).

This is how I, as a cross platform developer, look at these platforms when trying to design and develop a new commercial product. I’m keeping “religion” (i.e., the relative merits of open source vs. closed source) out of this discussion in the main, aside from mentioning availability of sample code:

Apple:

Pros: Has maximum reach, best application discovery, best user experience with regard to UI and overall integration, highest quality store; customers spend actual money here. Best UI design tool of any of the mobile smartphone environments (Interface Builder) . Easiest to system test code, because you only have 3 basic iPhone models.

Cons: Strict curation can be an impediment to delivery. Wait times for approval have gotten better, but definitely adds friction to the process.

Android:

Pros: Easiest to ship, fastest growing smartphone OS. Lots of open source examples. No curation to get your app in the market, which means revisions and bug fixes happen in “internet time.” The ability to customize AVMs for creating device simulator configurations is the most flexible across all OS SDKs.

Cons: Horrible UI design tool. No application discovery, aside from third party websites. No curation in Android Market means anything goes. System testing is a nightmare, because you have a cross product of dozens of combinations of hardware and OSes that realistically won’t be fully exercised by small developers. The user experience across carriers is inconsistent – anyone who have ever implemented an application on Android that has to use the camera can attest to the variability in operation, quality, and performance. Fragmentation really doesn’t capture how fast this is getting worse rather than better (see: Verizon and Amazon creating their own market, see: carriers installing root kits to frustrate rooting, see: application filtering by carrier).

Blackberry:

Pros: Huge installed base of devices. Market leader in penetration inside of enterprises. Secure. Dozens of software simulators available for testing.

Cons: Worst SDK of any smartphone OS. SDK runs only on Windows (technology release now available for Mac OS X, but no simulators and it works only for directly attached OS 6 devices, which is one: the 9800 Torch). No UI tools, period. Worst developer community of any smartphone OS (no disrespect to the many fine BB developers I have met the past couple of years. But in the main, most of these guys – and they are guys – are usually company drones that I for the life of me can’t seem to find any actual apps that they have written. Prolly cause there’s only 9,000 apps in Blackberry App World, and unless you have a Blackberry Phone with a data plan, you’d never see ’em anyway). Multiple OSes, hardware form factors make unit and system testing impractical for rapid releases. Browser – with the exception of the latest OS 6 release – is the absolute worst of any smartphone. Research in Motion also doesn’t seem to really care about software, except for only the sense that it is needed to operate the hardware. They’re a hardware company first and foremost, and it shows in spades.

Your mileage may vary.

But since the majority of application release scenarios we see play out in the marketplace are iPhone First, Android Second, Blackberry when we get around to it, I don’t think my take differs from those actually doing cross platform development, rather than those opining about it.

Nobody likes to have their baby called ugly.

But when it is, it is.

Debugging for the New Blackberry 9800

Hopefully, a helpful hint:

Use the Blackberry SDK version of the 9800 simulator, and not the one that you can download separately from the Blackberry website.

The SDK simulator seems to work fairly well; the separate download version tends to lock up when trying to access embedded web controls.

This may be a very temporary thing. But for now, I can say at least anecdotally this has been my experience.

Playing a Sound File in a Blackberry Java App

Without a lot of undo fuss, here’s one way to play a sound file in a Blackberry Java app:

Class cl = null;
try {
cl = Class.forName("com.mycompany.myapp.MyAppMainClass");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
if (cl!=null) {
InputStream is = cl.getResourceAsStream("/someSoundFile.mp3");
try {
Player player = Manager.createPlayer(is, "audio/mpeg");
player.realize();
player.prefetch();
player.start();
is.close();
} catch (IOException e) {
e.printStackTrace();
} catch (MediaException e) {
e.printStackTrace();
}
}

I usually create a package under the res (resource) package, name it sounds, and plop my sound files there.
Easy Peasy.

Hiding Blackberry Background Processes

If you’ve ever developed a Blackberry app that has an Alternate Entry Point and runs in the background, you’re familiar with this typical scenario in your main application class (or something very much like it):

public static void main(String args[]) {

if (args.length>0 && args[0].equals("autostartup"))

{

MyApp app = new MyApp();

app.registerPushApplication();

app.enterEventDispatcher();

}

else

{

new MyApp().showGUI();

}

}


But wait a minute… how come I can ** still ** see my application’s autostart instance in the “Switch Applications” dialog?!?

This isn’t what I wanted.

Here’s the additional “secret sauce” you need:

First, declare a private global boolean in your main application class. I call mine (usually) _acceptsForeground and set it to false initially.

Next, in your main application class handle the UIApplication.acceptsForeground callback and code it like this:


protected boolean acceptsForeground() {

return _acceptsForeground;

}

Finally, in your showGUI() method (or whatever you call your analogous implementation) you need to add the following two (2) lines of code at the beginning of the method:

_acceptsForeground = true;

UiApplication.getUiApplication.requestForeground();


And that’s that. No longer will your application’s autostart instance appear in your task switcher.

The Alternative to the Blackberry Battery Pull

Tired of yanking your Blackberry battery out when things go wonky?

Fear not, friends.

I have a tip.

There is a Blackberry equivalent to the Windows Ctrl-Alt-Delete three-finger salute.

Press the Alt, Right-Shift, and Del keys and hold them down.

It’s the little things, right?

A nice little BES / BIS “gotcha”

A funny thing happened while testing today.

Well. It really wasn’t that funny.

Just strange.

I was testing a new Blackberry app to run solely over BIS and / or solely over BES.

And all hell started breaking loose.

JSON wouldn’t parse. Calls broke. Dogs and cats lied down next to each other.

After a little digging, I discovered that when an app makes calls over BIS or BES, there’s a good chance the data you get back will be a mixed stream of UTF-16 and UTF-8 data.

Not just a good chance. In my case, it ALWAYS returned mixed data.

Talk about your basic cluster smuck.

The fix turned out to be simple enough. I just had to set x-rim-transcode-content in my HTTP headers to none and voila! Problem solved. Nothing but good ol’ pure UTF-8.

I can’t imagine how many people out there are having this problem.  But I hope this little “heads up” can save someone a little grief.

Blackberry BrowserFieldListener downloadProgress

The downloadProgress event for BrowserFieldListener never fires.

Let me repeat.

The downloadProgress event for BrowserFieldListener never fires.

So, this is causing me to put together a dirty hack. And it will work.

But once again, spending development time to fix documented Blackberry “features” that simply don’t work.

Like isFocus.

And now, downloadProgress.

The Blackberry NullField

If you’ve ever perused the Blackberry Java documentation on a Friday evening (and who here hasn’t?), you may have come across the NullField.

NullField is a field that has no dimension, can’t be set in any meaningful way, and you can’t see it on the screen.

What the hell good is it for?

Well. This.

One of the annoying things you may have noticed when declaring a long LabelField (say, longer than the height of the screen) followed by some element that can take the focus (a TextEditField or a ButtonField), the user doesn’t get a chance to see the top of the LabelField.

Worse, they can’t scroll up and see it.

Some people resolve this by making the LabelField a RichTextField (so that it can accept the focus and can scroll).

Ah. But this is what NullField was designed for.

So that you could stick a NullField at the very front of a screen that would never be able to get the focus, and start there with the focus.

NullField is not the perfect solution. For example, scrolling is not smooth from visible focusable elements to hidden focusable elements. But at least you can set focus at the beginning (or the end) of long screens that otherwise have no elements that can be focused.

I can’t really understand why one can’t simply scroll all of a screen that is painted, regardless of whether the elements can have focus.

I know, right?

You just can’t.

So just use NullField and stop griping about the Blackberry SDK. Again.

Constructive Criticism – What I would do if I were Jim Balsillie

Blackberry is in the news – a lot – these days.

And not for many good reasons, aside from the fact that they own 40% of the smartphone market as measured in handsets deployed.

But, after losing some 14% market share over the past 9 months to Apple iPhone and Google Android devices, it’s clear something has to be done to staunch the flow of departing customers.

In no particular order, and from a decidedly how-it’s-put-together bent, is my take on what is needed:

• The browser must be improved. It is the single-most reason people move from the device to something else – making Blackberry devices good for phone calls and email only; because beyond that, the internet experience is nothing but painful.
• In addition to secure communications – the number one reason businesses give for staying with Blackberry – they should have a consumer offering that does not require a PhD. in mobile communications to configure and maintain. A working, out of the box, Blackberry? Shudder the thought. Try explaining BES, BIS, WAP, WAP2, Direct/TCP, WiFi, and (soon) WiMax to your mom or Aunt Tilly. THAT’S what having a Blackberry today requires.
• Pick a form factor going forward and stick with it. The marketing at this point is a nightmare. What’s the difference between the Tour, the Storm, the Pearl, the Curve, and the Bold? If you know the differences, you’ve got way the hell too much time on your hands.

From a development standpoint, I’ve already mentioned the fact that their current browser is not up to snuff (in fact, it’s pretty terrible, even the 5.0 rendering). But additionally, I would recommend the following:

• If you’re claiming to be J2ME, really be J2ME. There’s nothing more frustrating that trying to use code from other J2ME projects and try to use it on your Blackberry, only to discover that everyone else’s Java is NOT Blackberry’s Java.
• Support Apache Http for consumer applications. Not everyone needs to operate in the UAE (hey – even you guys don’t have to worry about this anymore!). In fact, the vast majority of people don’t need tunnel communications to checkin to Foursquare. You guys need a super easy way to connect to backend web services that need no super secret handshake.
• Upgrading the UI library across the board. At present: No UI design tools, you can’t enable and disable controls without deleting them, and the properties that ARE there for setting UI operation don’t work as documented (I’m looking at you, isFocus()).
• Allowing filtering on the debug console. Right now, I have to ignore the noise of all the Blackberry Debug logic as well as my own when trying to output trace information… rendering System.out.println almost useless.
• Charging $200 for ten app submissions to Blackberry Marketplace… are you trying to keep apps out? Mission accomplished. Make the number of submissions to your app store free. The problem isn’t that too many people are trying to waste your time submitting apps – it’s that too few are even bothering.
• Reduce the number of form factors going forward. No WAY is a developer gonna own every handset model representative of each form factor when there exists a cross-product matrix of dozens of  hardware-to-OS combinations. Not if they want to deliver a product in our lifetime.

I’ve got several more, but I’m trying to stay constructive in my recommendations.

In honesty, I believe it’s already game over for Blackberry. They aren’t going to change and everyone else is in a boat race pulling ahead in innovation.