Skip to main content

Platform Innovation


With the introduction of the iPhone 5, one new feature has more people abuzz than any other: the new adapter.  Instead of the traditional 30-pin dock connector that has become ubiquitous in everything from consumer electronics to luxury cars, Apple has opted to introduce a new, proprietary 8-bin connector dubbed "Lightning".  I think that I speak for most of us Apple product owners when I say that as soon as this was announced, you did a mental tally of all of the devices and cables that would eventually have to be replaced, and I wasn't too happy with the resulting number.

Yes, it will be a pain to replace all of my cables and devices that use the older connector, but we'll all complain about, get angry, and eventually over time, forget about it.  Like the CD drive.  Or floppy drive.  Or the replaceable battery.
My point here is not to get into a "who innovates more" argument, but rather highlight a type of innovation that is very much organic to Apple and its overall strategy: platform innovation.  Apple is more than willing to take the bold step of admitting (or what some may consider dictating) when a feature or product has seen better days, and simply eliminate that feature entirely.  

Let's start with the floppy disk.  With the original Mac, Apple bucked the industry and chose a newer, smaller format for it's floppy disk.  In this case, different was good, as it had a higher capacity and was much more durable that it's 5 1/4" counterpart.  It took a few years, but eventually, Macs and PCs alike both standardized on the 3 1/2" floppy as their standard drive.

Despite Apple's introduction of the 3 1/2" drive, it was also the format's assassin, as as they eliminated any floppy drive on the original iMac.  At the time, this seemed like a dangerous move, as a lot of software was still distributed via floppy disks, and almost all documents were saved on them if they needed to be moved to another workstation.  But over time, all other manufacturers followed suit, and now you'd be hard-pressed to find any PC or Mac with a floppy drive.

Next, consider OS X.  Initially, any older Mac application writen for System 8 or 9 would run in an emulator dubbed Rosetta.  This was great and even necessary, as initially there were few native applications built for OS X, and Apple needed to ensure compatibility.  But at some point - and I can't remember the specific release - Apple said no more emulation.  Many of us grumbled that we'd have to re-purchase the same software for the newer OS, but we all did, and I think that OS X is better for having eliminated this type of legacy support.

Apple also killed the removable battery - first in the iPhone, and later in the MacBook line.  This decision allowed for larger, more expensive batteries that would in theory give you more usage time.  I do believe that the verdict is still out on this one, as Apple's competitors use this as a weakness to this day, as few others have adopted this strategy.

This brings us to the new dock connector.  Of course, its too early to tell what will happen as a result of this.  My prediction - given past history - is nothing.  Once the 3rd party market starts cranking out $5 adaptors, this perceived pain will vanish, and we'll forget about any impact that this decision has made.  Apple will, once again, benefit from being able to determine if and when something is no longer useful, and force that decision upon its customers, for better, worse, or nothing at all.

This strategy can be applied to how we develop applications, too.  There will come a time when an old technology or feature or even method simply does not apply anymore.  The pain of removing the outdated component is always perceived to be high, but the relief of a better alternate approach over time will benefit everyone.  

Implementing a platform innovation is never easy, and often they are done in the wrong places.  But when they are done properly and in the right places, we all benefit in the long run. 

Comments

Buzz Killington said…
On a PC at least they went toward USB which is standard. Every other phone manufacturer uses micro-USB now except Apple.

They are giving all their customers a giant EFF U, but everyone eats it up. If they were switching to a standard connector, that would be one thing - but to another proprietary one?

You drew the parallel to software, but there is a reason that VBScript never took off and that's b/c it only works on IE. Javascript is universal, hence its appeal. Waiting for the same thing to happen with all of these "Apple only" things - hoping eventually people wake up to it!
Scott said…
Buzz,

Ironically, Apple pioneered USB as well. :)

They have reasons for the avoidance of micro-USB, namely that it won't deliver enough power for the iPad to charge. With their connector, they can not only deliver the required power, but also provide a faster charge time. They look at this as a benefit for the consumer and weigh that as more important than adhering to a standard that does not meet their needs. I would bet that the vast majority does not care about which standards Apple chooses to adhere to as much as they care about being able to charge their devices as quickly as possible.

VBScript is a good example, but that's out of what we can control. What I was referring to was something within the domain that we as developers can influence - be it an older system that should be upgraded, or some process that was implemented years ago that is no longer relevant.

We can't all make the same impact as Apple does with our choices, but within our organizations & communities, we can make things better.

- Scott -
30 Pin connector as well as Apex (aka Marvel) almost introduced at the same time to the world and Apple replaced 30 pin connector to "Lightening". How about Oracle :)
Scott said…
Balaji,

I think that software is a little more adaptable than hardware. :)

- Scott -

Popular posts from this blog

Custom Export to CSV

It's been a while since I've updated my blog. I've been quite busy lately, and just have not had the time that I used to. We're expecting our 1st child in just a few short weeks now, so most of my free time has been spent learning Lamaze breathing, making the weekly run to Babies R Us, and relocating my office from the larger room upstairs to the smaller one downstairs - which I do happen to like MUCH more than I had anticipated. I have everything I need within a short walk - a bathroom, beer fridge, and 52" HD TV. I only need to go upstairs to eat and sleep now, but alas, this will all change soon... Recently, I was asked if you could change the way Export to CSV in ApEx works. The short answer is, of course, no. But it's not too difficult to "roll your own" CSV export procedure. Why would you want to do this? Well, the customer's requirement was to manipulate some data when the Export link was clicked, and then export it to CSV in a forma

Refreshing PL/SQL Regions in APEX

If you've been using APEX long enough, you've probably used a PL/SQL Region to render some sort of HTML that the APEX built-in components simply can't handle. Perhaps a complex chart or region that has a lot of custom content and/or layout. While best practices may be to use an APEX component, or if not, build a plugin, we all know that sometimes reality doesn't give us that kind of time or flexibility. While the PL/SQL Region is quite powerful, it still lacks a key feature: the ability to be refreshed by a Dynamic Action. This is true even in APEX 5. Fortunately, there's a simple workaround that only requires a small change to your code: change your procedure to a function and call it from a Classic Report region. In changing your procedure to a function, you'll likely only need to make one type of change: converting and htp.prn calls to instead populate and return a variable at the end of the function. Most, if not all of the rest of the code can rem

Logging APEX Report Downloads

A customer recently asked how APEX could track who clicked “download” from an Interactive Grid.  After some quick searching of the logs, I realized that APEX simply does not record this type of activity, aside from a simple page view type of “AJAX” entry.  This was not specific enough, and of course, led to the next question - can we prevent users from downloading data from a grid entirely? I knew that any Javascript-based solution would fall short of their security requirements, since it is trivial to reconstruct the URL pattern required to initiate a download, even if the Javascript had removed the option from the menu.  Thus, I had to consider a PL/SQL-based approach - one that could not be bypassed by a malicious end user. To solve this problem, I turned to APEX’s Initialization PL/SQL Code parameter.  Any PL/SQL code entered in this region will be executed before any other APEX-related process.  Thus, it is literally the first place that a developer can interact with an APEX p