Monday, September 11, 2017

Amazon Alexa And Rewiring My Brain

I took Amazon's Whole Foods bait the other day and bought an Echo and a Dot while buying groceries (yup... weird). Here are my first impressions after about a week's worth of use.

I set Alexa up in a new space that doesn't have much ambient noise; no kiddos, no pets (barking). I'm extremely bearish on using voice computer interaction in real-world/day-to-day environments. I don't think it will ultimately work for two reasons: one, background/ambient/adjacent audio noise pervades the bulk of life, and machines can't filter it out (we're not even close on this front). two, unlike all intrusive technology to-date, audio/voice is intrusive and active enough, that socially and culturally, I think the behavioral shifts required for mass adoption are too abrasive. If you and I are hanging out having a conversation, it's one thing for me to pull out a screen and mess with it, passively paying attention to what you're saying, and quite another for me to full-stop pause our interaction with a visual or verbal cue, engage a computer (another entity really), then re-engage with you. It's awful... you can try it today with Siri.

That's another post though. Onto Alexa.

I went with Alexa over Google Home because the number of Alexa integrations dwarfs Google's, and I'm all about integrations. Voice recognition feels as good as Google's though.

Getting things setup was really simple, and I appreciated the delayed software update approach. Of course there's a s/w update (there always is w/ IoT devices), but there's nothing worse than being forced into one immediately upon setting something up for the first time. Nice touch Amazon... I hope all devices move to this delayed-initial-update approach.

The way you add capabilities/integrations to Alexa is done by adding what they call Skills. Just think "extensions" or "integrations."

One of the Skills I added required inputting an API token over voice. That was interesting. Imagine verbally telling a computer "A56D8F2298OG9234SHE." The instructions suggested I used the NATO Phonetic Alphabet, so I went and learned that, and then "input" my token. It took a few tries, but I got it in there. This particular Skill required some other settings configuration, so I went on to say things like "SET UNITS Imperial." Configuring software using voice is just wild.

I added my car manufacturer's Skill, and I can interact with my car via Alexa now. This has been useful actually. Instead of firing up the iOS app for my car, I can just say things like "Alexa, ask to lock my car" and "Alexa, ask to start climate control." etc.

Home automation stuff is fun too. "Alexa, lock the front door." "Alexa, turn on the kettle." "Alexa, turn on the Phonograph." (those first two Skills made possible by Wink, and the latter by Logitech Harmony).

I am weary of pulling out my mobile device to do all of my home automation stuff. In general I'm just sick of screens and remotes, so starting to do things via voice is a welcome reprieve. This brings me to the more interesting part of this post.

My Brain
The degree to which my brain has been wired for visual/reading input, and kinesthetic (keyboard/touch-screen) output is more significant than I realized, and pushing myself to use voice has provided the contrast to really perceive it.

With Voice, there is no multitasking; everything is serial. There are no other open tabs to use as background/reference as you do your task. With Voice, you have to have all the information in your head, before engaging. So much of our online/computerized world today allows us to simply copy/paste (metaphorically speaking) our way through life.

Alexa is causing me to use memory in ways I haven't had to in a long time. It also caused me to learn the NATO Phonetic Alphabet so I could better speak to the computer.

Curious to see where this all goes.

Thursday, August 17, 2017

The Three Mobile Notification Tiers

Mobile device notifications have probably become the primary UI I use to engage with my mobile device. I'm constantly amazed at how poorly mobile app developers implement them. Here's an awesome post by Stan Otrovskiy (iOS engineer at AMEX) that gets into how to do the right thing when a user actually selects a notification; great read.

I wanted to get some high-level thoughts down on paper around the three notification constructs nearly all mobile OSes support. Use them wisely.


SMS (aka "text") notifications are presented by the OS and are generally end-user configurable. These reach the device whether or not data is enabled or disabled, and by definition involve server and mobile-device communication. In a connected-device world, SMS notifications are often considered the most reliable form of notifying the user of something because they run on a different carrier protocol and aren't as subject to the general horrors of "data connection" unavailability. Be careful though, if your users are going to use your application while on a commercial airplane flying at 30k'+, SMS doesn't work. In general though, SMS finds a way to get through when data/IP based messages simply can't. The downside to SMS is that it's archaic and poor in terms of features and functionality. On iOS (I don't recall about Android), these notifications do NOT require the end user to initially grant permission for use.


The various mobile platforms (e.g. iOS, Android) provide OS-level notification frameworks. These frameworks allow an application to present OS notifications. The quickest way to understand these as an end-user is to go into iOS Settings->Notifications, where you can see the various types of ways to notify/alert the user to something. If your mobile app has a backend component that wants to engage with the user with a notification (e.g. "Your Uber is arriving."), the user's mobile service needs to a) support data and b) have data enabled on their device. In this case, as should be obvious, the user CANNOT be in airplane mode, otherwise there's no way for corresponding IP packets to get to the OS. These notifications generally require user permission on a per-app basis.


These are notifications that live purely within your application. If your app is a game, perhaps you throw dialogs that say things like "you just won 100 coins" or whatnot. In-App notifications don't abide by any OS-configured rules such as "don't display on lock screen" because they live entirely within the application itself, and are only relevant/visible when the user has the application in the foreground. Of course, you can reflect some, or mirror all, in-app notifications to their OS-level notification counterparts.


At the root of all notifications is gaining the user's trust to send them along in the first place. Regardless of their OS-level notification settings (whether they're liberal and permit all notifications to be as loud and visible as they want to be at all hours, or whether they're conservative and disable all notifications all the time), you have to be wary of being too pushy with your notifications. Over-notifying, or notifying the user of something they don't care about, violates trust. While you may want to engage the user for one reason or another, considering when to do so is important. Users disengage from noisy apps. As time permits, give your users lots of control over the types of notifications they receive. Default settings win, but power-users will eventually want to control all the nooks and crannies of their interaction with your app.

When you're considering conveying a piece of information to a user, it's important to understand the matrix of various notification settings and operating environments your users are likely going to be in. For example, if your application is for rock-concert or major sports event attendees, they don't have data connections available due to cell tower network saturation, nor are they likely to hear or feel notifications/vibrations of any type. Thus, perhaps your only notifications will be In-App when you're guaranteed to have the user's attention.

The best notification/engagement schemes are quickly foiled by a user who has turned on Airplane Mode to save battery life. Make sure you're providing value to the user in all notification settings scenarios, or ensure you know your user-base's settings support what you want to do with notifications.

Tuesday, August 15, 2017

That Was So Stressful!

I just successfully used . I got it on the second try. Here's my text.

I would love to see the world's editor windows support this feature by default. I wonder what everything would look and feel like if we all wrote this way. Same goes for writing code :). that would be powerful.

I'm definitely stressing as I can see the bar across the top creeping along and it seems I'm only one-fifth of the way through this exercise.

So much gets lost when we edit over and over again and stall our thought process to perfect verbiage and such. Consciousness seems to get lost in it all. Our true selves become masked.

Interesting, I find myself typing garbage and deleting it to buy myself small bits of time when my mind goes blank.

Almost halfway there! This will be fascinating if I can get to the end. Can you feel my stress ticking up :).

So much of the world is concerned with consuming content instead of creating it. I wish we could/would all spend more time creating. That said, creating doesn't necessarily mean creating and editing over and over and over again. This is why I emphasize my photography work as "in-camera." It ensures that I don't spend a bunch of hours in front of a computer editing my photographs. It forces me to compose shots just "so" and ensures I get the settings right up-front, instead of tweaking and editing later.

I think the world would be a better place if, in general, we didn't edit everything. Of course, I'm a huge fan of the 24-hr rule which says we must wait 24 hrs or "sleep on it" before sending/saying something that could be done in the heat of the moment. That always has served me, and others well, but I wonder how you weave that into a tool/feature like this.

I'm almost done. I'm near the end. Please don't brain glitch and miss this. I twould suck to get this far and lose it all. But this has been a fun adventure. I hope others will try it. my palms are literally sweating as I type this.

I need to calm down as I can see the stress ki

Monday, June 5, 2017


I can finally talk about this product and company!

CARMERA is building a marketplace for real-time, in-depth (3D), street-level environment information. Autonomous vehicles and smart city efforts have insatiable appetites for this kind of data, and collecting it is expensive and hard. CARMERA brings it to market in a scalable, affordable, manner, so industry can focus on solutions that leverage the data, instead of the collection/creation of it. If this sounds a bit analogous to my previous effort in the social data space, Gnip, Inc., it should.

Much of the inspiration for this idea came from Ro's (co-founder/CEO) experience in the public social data industry while working at Disqus. Disqus and Gnip (my previous firm) worked together to build a marketplace for vast amounts of discussion data, by pairing the supply and demand sides of the ecosystem. Delivering real-time, high-throughput, reliable, full-fidelity, was our collective mantra, and CARMERA's doing this with street-data.

In order for new industries to flourish, they need to be able to focus on their specific value-adds, instead of putting time, energy, and money into acquiring the underlying data they need to fuel their efforts. CARMERA does for real-time, street vision data, what Gnip did/does for real-time, public social data.

One of the cool things about their approach is that they leverage existing commercial vehicle fleets to do the "crawling" of the the road networks, instead of owning and paying for a massive fleet of vehicles themselves (they do have some vehicles). They partner with fleets, slap their homegrown sensor packs on the vehicles, and collect/analyze the data. They then turn around a provide that data, and associated intelligence, to the market.

The CARMERA team is what makes this possible of course. Ro Gupta (previous Disqus fame) and Justin Day (previous CTO of MakerBot) co-founded the effort. Ethan Sorrelgreen (previously Amazon Maps + Apple Maps Eng Lead) drives Product. Engineering is comprised of former MakerBot, Google, Inrix, Microsoft/Bing Maps, and MetaVR crew.

Below is some cool eye-candy around what the platform can do.

I'm an investor/advisor.

3D Point Map of the West Village on Manhattan.
Feature detection.

Fleet Partner Vehicle with sensor packs on roof. 

One of CARMERA's cars.