On The Poisonous Thinking of Dot-Com Products

Joe McCann

A wise friend and colleague of mine said sometime last year that there is a "changing of the guards" taking place in the dot-com and pre-dot-com era technology companies with, fresh, young blood taking the helm at key positions. I wholeheartedly agree with this assertion, but what does that have to do with the title of this post.

Well, many bright and intelligent folks in the dot-com/PC era have been highly successful on leveraging the web as not only a deployment channel but also as a product shelf, meaning, one can very easily add a new feature to a current product or create a new website/app (product) altogether and immediately see the impact by deploying to one's servers and measuring ROI with various metrics (pageviews, cookie tracking, etc.).

Those days are gone.

Why? Have a look at the desktop/PC-computing device sales over the past couple of years (photo courtesy of asymco.com).

Mobile versus PC device shipments.

The market share of PCs versus mobile devices now sits at 50/50. This happened in an astonishingly rapid rate (less than three years). The success of the PC's reign as the dominant computing platform is quickly coming to an end with the rise of mobile and casual computing devices (casual computing devices include tablets such as the iPad) and therefore one's strategy on how to create new products and features (and from a business standpoint additional revenue streams) must also change...and fast.

But I Just Want To Add A New Feature...

The antiquated way (meaning a mere 10+ years ago) of unlocking new value on say an ecommerce site would be to add something like a one-click to purchase button, which can immediately be deployed and impact millions of users. Since your users all need to access your one-click offering through your website, you are very much in control of the context in which the user is in and the deployment channel for your one-click button.

This simply does not apply today.

Why? Well, let's think about this. Let's say you have a niche online ecommerce website, like fab.com, where people can access your wares through the traditional dot-com web channel - your website! But now, you want to add a new capability like "pinning" products to one's Pinterest page. You can add this feature very easily on your desktop/PC-friendly website, and even to your mobile-web friendly website, but how do you add it to your Android application? Your iPhone application? Your iPad application? Your Blackberry application? Your Android tablet application? Do you see a pattern?

What are the deltas between the web version and the aformentioned apps? First, the underlying technology is not simply HTML, CSS and JavaScript for a standard website or web application - no, we are now touching on technologies like Objective-C, the programming language for iOS, and Java the programming language for Android. Blackberry apps are written using J2ME (including proprietary RIM libraries). These need to be compiled into an executable application - this is not the web.

The programming idiosyncrasies for each respecitve platform is one of the most significant differences in how things are changing in the mobile and casual computing space versus the desktop/PC counterpart, but the biggest difference is the deployment channel, or more accruately deployment channels.

Right now, if you want to add that "pinning" feature mentioned above you can't simply deploy it to you site and presto chango it shows up on your iPad application. No, you must add it to your current codebase for your iPad application, compile it, upload it to your developer account on iTunes, submit it for review to Apple, wait, and wait, and wait some more, until it is either approved (or denied) and then users who have the app installed must update their version of the application. And this is only one deployment channel!

The presto chango deployment of the web is gone.

But The Mobile Web...

Lately, there has been a significant amount of cheerleading around a "mobile first approach to design and one's technological strategy overall, but sadly, when folks talk about "mobile-first" they are really saying "mobile web first". Let me say this as succinctly as possible:

Having a mobile web strategy is only one half of the equation for a cohesive mobile strategy.

The other half? Native application development.

Have a look at the latest Flurry Analytics data below; it shows native app usage is actually higher than mobile web usage (photo courtesy of Flurry Analytics).

Mobile app usage higher than mobile web.

Thinking that simply using the mobile web to fix the cross-platform and deployment issues mentioned above is foolish (and if you're an architect or technical strategist is worthy of getting fired, in my opinion) given the trend in native application usage versus mobile browser usage. Only focusing one part of the equation (the minority at this point) leaves a massive gap for the other.

That being said, I am and have been a huge proponent of the using the web as the closest thing to a universal platform (for development and deployment). However, one must not be so stubborn that one is unwilling to change one's position on their technical strategy when the data itself suggests otherwise (not to mention feedback from paying clients).

But What About Hybrid Apps...

Hybrid apps (native + HTML5/browser instance), another contentious misnomer, do provide a potential stopgap for some of the aforementioned issues, namely the deployment part, but do not fully skirt the issue of development. One may certainly use something like phonegap to assist on the development sides of things, but there is still a compilation step and the initial deployment of the application still falls under the aforementioned deployment channel problem.

Facebook has actually been somewhat successful with a hybrid-app approach with their HTML5 framework Sparta; however, if you browsed the S-1 Facebook recently filed, you'll notice that mobile is one of their biggest risks (namely, not having direct control over the platforms they are on - Apple and Google-backed platforms). Facebook recognizes the deployment channels issue as a business risk not to mention less than stellar browsers (due to a lack of native device APIs) and "near native" but not 100% native user experiences. Mobile will be one of Facebook's biggest revenue growth areas in the coming years so watching their moves from an architectural level may shed some light on a cohesive strategy you can employ.

Next Steps?

With where we stand currently in computing overall, the shift leaning heavily toward a mobile or casual computing standard, it is important for the thought leaders and the industry leaders to continue to do just that: lead. Thinking in the dot-com space, or for that matter, the desktop web space, and attempting to shoehorn the methodologies that worked over the past 10 or so years in that space, into a modern technical strategy will almost certainly set one up for failure. The clients/devices are different. The context is different. The engagement is different. The technologies are different. The deployment channels are different.

Absolute ideologies and dogma have no place in such a rapidly evolving computing landscape. Being flexible, nimble, and open to change will put one, and one's products and services, in a position to be successful. For the time being, that means having a comprehensive, multi-channel experience across various platforms - not just the web. Plan accordingly.