Water, food and smartphone

There is water, food and smartphone. Those are the only three things that have (or soon will have) 1:1 penetration for the world’s population. It makes stuff like tablets and watches look like piddly little businesses, even though those are huge businesses by any other standard. Apple alone sells millions of units which generate billions in revenue every quarter.

There will likely never be another smartphone. Its reach and scale are impossible to replicate. But it doesn’t mean there isn’t 20-50 multi-billion dollar “niches” out there that companies like Apple, Samsung, and Xiaomi can profit from, and the combination of those “smartphone ancillary” products combined might be as much revenue as the smartphone by itself.

Keeping Portland Weird

I was downtown for one meeting (NW24th and Quimby) and had another at NW14th and Everett so I decided to walk.
While walking up the street on 23rd is coming at me a completely naked man with a hand-written sign around his neck. I thought maybe the sign would indicate why he’s walking around naked, some political statement, something, but the sign was in pencil and I couldn’t read it from a distance. And of course I don’t want to stare at this naked guy trying to read this sign. So I keep glancing and can finally read it as he comes by: “I lost my pet.”
Ah, Portland.

Web! Native! Both?

I once had a professor who insisted that writing software was 70% planning and 30% implementation. I thought he was crazy at the time. 18 years later I completely understand where he was coming from.

Nolan Lawson kicked off another round of discussions about using web technologies exclusively to build native apps (and a follow-up here). The native app people always come down on the side of no way. They rightly point to the fact that web apps don’t feel like native apps. The animations between views aren’t as smooth, the look-and-feel can never be native enough, and the “write-once, run-everywhere” approach just means really mediocre applications everywhere. Learn to write native code!

The web-centric developers point to the complexities of learning web, iOS, Android, Windows and Mac program. Learning any one language well is hard enough. Learning five well enough to write performant apps and maintain those apps is nearly impossible. Besides it is the web that made Mac relevant. We already have write-once, run-everywhere. It’s called a web browser. Why should we go back to coding like its 1995?

These arguments, however, ignore a third way: the hybrid app. The hybrid app is where some of the application uses web technology and some use native code. We use embedded web views wrapped within native code to present the application to the customer.

Apple already does this in some of their apps today. The Mail app uses web views to show email. It is also rumored that iMessage uses web views to show individual message bubbles. iBooks may use web views as well. Third-party apps, especially reader applications, RSS apps and apps like Flipboard and read-it-later applications use web views in this way as well. The entire app isn’t HTML and the entire app isn’t native.

The key to this approach is understanding clearly what makes each of the various technologies superior and then use each of those technologies appropriately to build a superior experience. Just like in the days when developers would use Assembly to write really CPU-intensive aspects of their apps, web technologies can be used to do what they are best at: rendering and formatting text, especially when combined with other medias. Have you ever tried showing an image along with a block of formatted text in iOS or Android? How about a bulleted list with text around it? It’s possible but it isn’t easy. HTML makes that simple, even giving us the ability to edit that text and return the output to the native app.

HTML fails miserably at animation¹, though, and it is nearly impossible to make HTML look like Android or iOS. Don’t use it for that. Learning the basics of navigation, list management and animation techniques in any native platform, though, takes a much smaller amount of time and doesn’t require nearly the skill set.

This is why planning is so important. When we started working on Equals we broke the product down into small pieces, deciding how to accomplish each piece, thinking ahead to both how the app would work on the web and also how it would be presented on native platforms.

We used Equals’ technology to develop our first mobile app: DEWALT Mobile Pro for Android. I had never written an Android app before this. (powerOne for Android was developed by a third-party.) True to my word, DEWALT Mobile Pro is a hybrid app: it uses all native Android code to present the list, calculator and various dialogs, and uses HTML technology to present the template itself, which combines various elements — images, links, text, and some input keypads — in a single page.

It took less than three months to write the entire application, including learning how to develop for Android. In comparison, it took six months to develop powerOne for iPhone back in 2008. The difference, frankly, was the amount of time I needed to invest in native code that shows and allows data input into the templates.

By utilizing a combination of HTML5 and native code I believe I was able to attain a superior presentation of the templates while, at the same time, maintaining a native look-and-feel for the application. We can shout “native!” “web!” but in the end we should use the technologies — or, more appropriately, the combination of technologies — that make the best applications. Sometimes that’s native code, sometimes it’s web code, and sometimes it’s both.

¹ I am specifically referring to animation that acts like native code. Making a spinner spin isn’t a big deal anywhere. But transitioning from one view to another never reacts well in HTML. If you do any animations, I can highly recommend Greensock’s GSAP technology. It is amazing, and the recommended animation engine by Google for their Material Design stuff.

Amazon Dash may be the most amazing and ridiculous thing I’ve ever seen


Amazon announced a new thingamajig called Dash Button last week. The idea is you put the whats-it, which is branded for some recurring purchase item, near that item and every time you need a new one, you just click the button. One of the examples was Tide. Put the dingus in the laundry room and, when you run low on Tide, click the button and two days later, you’ll have a new box on your doorstep courtesy of Amazon.

This is brilliant. It is the combination of cheap technology, ubiquitous wifi and Amazon at its best, making it brain-dead-easy to buy more of whatever you need. In some ways this is Amazon at its finest, mixing technological innovation with shopping, two of America’s favorite pastimes. I might even consider this the ultimate in direct advertising: a constant reminder to buy Tide with no intermediary between pressing the button and getting your fix. Pavlov, anyone?

But it seems so 2005 to me. Is buying a new box of Tide really so painful today that I need a doohickey in my laundry room? And how many of these thingies am I going to have in my house? Ten on my refrigerator, one each for Lucerne milk and another for Dole mixed juice and another for my Philadelphia cream cheese and another for … it just goes on and on and on? I already have a ubiquitous, always connected device with me all the time for ordering stuff, though. It’s called a smartphone. Wouldn’t an app that lists my common household items with a simple Buy button be so much simpler?

I get it. This is a first stop — and maybe the most tangible so far — involving the Internet of Things. But it seems like this is a weak stopgap to a much more interesting future. In a couple of years, after all, there will be a sensor at the bottom of that Tide box that can sense how much detergent is still in the box. When it hits its target amount the Tide container is smart enough to send a notification to my smart watch: “Tide low. Order more?” with a simple “Buy Now” button awaiting your command. Having another whatchamacallit is definitely not what I need.

So many things can be like this in our lives. My car can notify me when I need an oil change, my coffee machine can notify me to order more coffee, and it is all possible with ubiqutious technology and cheap sensors. This future is fascinating, but I don’t think it is going to look like a big branded whatsit attached to my washing machine.

The trade-offs of changing people’s lives

I’m going to say it: I want to have influence. I want to change people’s lives. I want to help people learn and work more efficiently than they ever have before. I want to leave my mark on the world.

We’ve had over 2 million downloads of our powerOne products on iOS and Android now over almost 8 years. Believe it or not this is far behind the pace we set for ourselves in the earlier part of the decade on Palm OS and Windows Mobile, where we had close to 15 million downloads over 5 years. 2 million, 15 million, though, is only a (good) start. There are over 1 billion people carrying around an iOS or Android smartphone, which means only 0.2%, roughly, even know about us.

The hardest part about building a business is getting people to know about the product. It is clear that charging for apps keeps people from using your products. But if we don’t charge for our software — that’s charge real, sustainable subscriptions, not these ridiculous $1 or $5 one-time price points — means we can’t afford to be in business.

Without funding it feels like we only get to pick one: 1) scale and have influence, paying for our families to live through some other means, or  2) charge a subscription, limit our influence ambitions but have the potential to make sustainable revenues near-term. I don’t want to pick but I can’t find a middle ground. I want my cake (influence) and eat it too (revenues).