Dealing with disruptive technologies from within

disruptby aroid

How Autodesk Disrupted Itself with an App – Technology Review
[Via Technology Review]

When Chris Cheung and Thomas Heermann, two middle managers at the software company Autodesk, first showed off their new iPhone drawing app, they got some skeptical looks. Why would anyone want to doodle on that tiny screen? And what could a $2.99 app matter to a company with around $2 billion in annual revenue?

[More]

This is a great example of how the app economy changes things and how adaptive companies deal with that change,

Two middle managers, charged with working on one project, are able to see the possible impact of new technology on their products. The app economy allowed them to bootstrap themselves without much investment of time, resources, or even permission from the company.

The products their small group created were big hits. The managers hoped for 100,000 downloads in a year. They got one million in 50 days.

These sorts of numbers are disruptive and mind boggling to a company with revenues in the billions. In fact, their entire PC-driven business could disappear in a few years due to this sort of economy – one where new competitors can arise so fast.

But Autodesk essentially competed with itself, now knows what is needed and could expand rapidly into this new niche.

Heermann thinks the timing of the apps may prove critical because consumer-style products are beginning to gain popularity among the corporate workforce, a phenomenon known as consumerization. That shift could spell trouble for companies that are slow to adapt. Now that Autodesk is a top-ranked app seller, says Heerman, who is now the company’s director of consumer products, “it’s almost like having the company shape up and get ready for the future.”

Disruptive technologies always start small and in niche areas. #12 million is small potatoes to a billion dollar company. But that small amount can grow and is Autodesk is snot adaptive enough, could eventually destroy Autodesk”s value.

Now, however, the disruption is happening inside and Autodesk might be resilient enough to capitalize.

Because one thing that disruptive technologies do – they destroy business models.


Blindsided by Apple – followed by a poor response

Analyst Shaw Wu: RIM ‘Blindsided’ by Kindle Fire Pricing
[Via Daring Fireball]

What exactly has RIM actually been prepared for in the last five years? Remember this one, where they thought the iPhone was impossible after Steve Jobs unveiled it?

[More]

Check out the older article from Electronista. All the big competitors, like RIM, Microsoft and toerhs, thought Apple was outright lying about the iPhone. They had all convinced themselves that a large touch screen was impossible without destroying battery life. So none of the thought very deeply about it.

That explains why Google seems to have added touch to its Android OS as an afterthought. They suffered from all three of Clarke’s Laws.

A hallmark of an adaptive, resilient company, one that can survive in the 21st century is to be able to recognize Clarke’s laws and utilize them. Obviously RIM could not and looks to fail.

Android might always be jerkier than iOS

Why Android Will Always Be Laggier Than iOS
[Via Cult of Mac]

One of the things that really stands out using an iPhone is just how smooth it feels compared to using Android. Where as Android is laggy, with a measurable interim between when you touch the screen and when the OS responds, iOS almost seems to anticipate what you want to do before your finger touches the display.

How has Apple managed this incredible feat? A better question might be: “How has Google managed to screw up Android’s multitouch so much?” According to Andrew Munn — a software engineering student and ex-Google intern — Android is so messed up that Google might never be able to match an iPhone or iPad’s performance. Ouch!

Before we begin, here’s some background. In the past, it has been said that Android’s UI is laggy compared to iOS because the UI elements weren’t hardware accelerated until Honeycomb. In other words, every time you swipe the screen on an Android phone, the CPU needs to draw every single pixel over again, and that’s not something CPUs are very good at.

That argument makes sense, except if it were true, Android would have stopped measurably lagging in touch responsiveness compared to iOS when Android 3.0 Honeycomb was released. Except guess what? Android devices are still laggy even after Honeycomb is installed on them.

[More]

The problem arises from a fundamental choice the developers of Android made years before the idea of touch even occurred to them They developed the Android to be used with a keyboard or trackball, just as every other smartphone of the time did – no touch.

When using a keyboard or other input, normal priority for the keyboarding tasks could be used. We text so slow that other background processes could take place. No need to give input a higher priority.

But rendering touch well requires a lot of the device’s power, so Apple made sure that anytime you use touch, it gets the highest priority, stopping anything that might slow down the touch interface. As stated in the article:

In other words, every time you touch your finger to your iPhone’s display, the OS literally goes crazy: “Someone’s touching us! Someone’s touching us! Stop everything else you’re doing, someone’s touching us!”

So moving anything on an iPad gives it all the resources the iPad can provide, making sure the movements are smooth.

But Google did not do this because they had to rush their operating system out to compete with Apple. They apparently did not  – or could not – rewrite the system to give touch the highest priority. So now, it gets the same amount of attention from the device as any housekeeping or app driven process.

And it may well be too late to change this without every app already out there to be rendered obsolete.

This is an example of why the well-thought out reasoning of Apple results in a great user experience versus the jury rigged, rushed efforts of their competitors.