danbricklin.com/log

Starting November 10, 2015
Voice and Command Line User Interfaces, My talk on TED.com, The Frankston Challenge, Long time no blog
10Nov15
2015_11_10.htm
               Older >
Sunday, January 28, 2018 
Voice and Command Line User Interfaces [link]
I have been seeing the increasing popularity of voice-controlled "smart speakers" like the Amazon Alexa series, including heavy use among many of my close relatives and even their very young children. Attending a Gartner conference, I watched analyst Jason Wong gave a presentation about "voice first" apps, showing an example from Rhino Fleet Tracking and explaining Amazon's recently announced "Alexa for Business" offering. This was something that could be used for internal business applications, not just for personal home use. Hmm. Internal business use if my area of interest as CTO at Alpha Software.

By the time I reached the airport for the ride home, I had checked out some of the Alexa documentation and saw that it would be pretty easy to hook up Alexa to query a database to explore this area. After a little work back home, I found that connecting to the REST API of our new Alpha TransForm mobile forms data capture system would be even easier. I soon had a demo and made a short minute and a half video "Simple business app with Alexa":

Video on YouTube
I then got to discuss the video with a variety of analysts and others and think about this area a lot. One thing I was struck with was the similarities between the Alexa-style voice input and traditional Command Line Interfaces (CLI). CLI, first popularized in the computer world back in the 1960's or so and continuing today in Linux, Windows, etc., has always appealed to many professional developers despite the advent of GUI and touch-based interfaces. There is something special there. Perhaps voice and CLI share some attributes that would explain the rapid rise of its popularity in smart speakers. I decided to write an essay exploring this.

The essay I came up with is "Revenge of the CLI: A transformation through voice and AI". It's in the Writings section.

Wednesday, January 11, 2017 
My talk on TED.com [link]
I'm excited that a TEDx Talk I gave last November has been posted as a TED.com video. The talk is a short retelling of the VisiCalc origin story. It's a much-condensed version of a talk I've been giving for many years, updated and enhanced. I'm very happy with how it came out.


TEDxBeaconStreet, where I gave the talk, is part of the TEDx program. It is an independently-organized TED-like event, named after "...Boston’s longest street, uniting towns and cities, neighborhoods and businesses, schools and families along the way." After they are given, TED picks up some of the talks at TEDx events and posts video from those talks on TED.com.

As I've often done in the past, I wrote an essay for the Writings Section of my website chronicling the process I went through to turn my long, rambling slide show into a tight, 12-minute TEDx-style talk. Viewers of the video may find the essay of interest. It was really interesting how helpful experience with crafting understandable, 140-character tweets on Twitter were for writing a smooth, short talk. I also found the ease and non-obtrusiveness of using popular recording devices (specifically, a GoPro Hero Session and the Voice Recorder app on my iPhone) for capturing feedback when practicing in front of others to be important.

Read "The story behind my TEDx Talk" in the Writings Section.

Tuesday, November 10, 2015 
The Frankston Challenge [link]
This morning I went for a normal check up with a healthcare provider I hadn't visited in a few years. The receptionist handed me a clipboard with paper forms to fill out to "catch up" -- nothing pre-filled out. Luckily, I was given a very sharp pen -- the fields were often way too small (when you live in "Newton Highlands" you need a lot of room for "City"). When I got to the section on "Pharmacy" I remembered that that office had sent a prescription a previous time to the wrong location (same street and company, wrong city and address). To make sure this time, I needed the address and phone number. I took out my cell phone to look it up. One bar. Very slow and dropped connectivity. I found the address but gave up on the phone number. I saw across the room a little sign with "WiFi" written on it. I guess I could have gotten up and followed the info to connect to their wireless router, if I trusted it, but I was too lazy. I left the field blank.

This was a reminder of what I call "The Frankston Challenge". As Bob Frankston has written repeatedly over the years, we need to have ambient connectivity that works everywhere without a prior relationship or human intervention to get past sign-in screens. (For example, see: Understanding Ambient Connectivity.) Yes, there was Internet connectivity where I was (in a normal office building in a major suburb on a busy street right near I-95/Rt 128), but it wasn't good enough or easy enough to answer a simple question quickly. For the laptops that the doctors and nurses used it was no problem -- they had already keyed in the special codes. For a new mobile device walking into the office, it was trouble like waiting for an old dialup modem to connect or nothing.

In the world of the Internet of Mobile Things (IoMT) you want to be able to just connect. Mobile Things include smartphones, tablets, wearables, automobiles, and so many coming things. They move with (or on) you, or on their own. The connectivity environment around them changes. The Frankston Challenge is very real for them today.

For example, you can't, as Bob points out, require a pacemaker or wearable reporting info to doctors and other systems to be pre-authorized with wireless carriers and WiFi access points everywhere the person might go. You don't want to have to pull out a keyboard (and maybe a credit card) to authorize connectivity when you feel tightness in your chest.

This problem won't be solved overnight. Bob has been working constantly to bring this to people's attention. For me, though, I'm in the world of making systems for business people to build apps that run on tablets and phones that move around with the users. We can't wait. This means that we won't have reliable connectivity everywhere, even where you would expect it. We have to build our systems to tolerate loss of connectivity. A consultant may be visiting a client's retail site or factory, or a repair person out in the field fixing a pump or transformer. The apps they run that replace the paper clipboard with something better and more tied into the flow of their tasks must be able to run offline.

We at Alpha Software have been working steadily to make disconnection-capable apps easier to build so that can be the default configuration. This is especially true for data capture applications. Not necessarily ignoring connectivity when available, but not becoming useless when it isn't.

A final irony. The office building where my doctor worked was the same one were my old company, Software Arts, had rented some space back in the early 1980s. It was across a parking lot from our main building. We used a centralized computer for timesharing to run our whole business. We had a very early Ethernet system installed to give "high-speed" connectivity to the terminals on everyone's desk. There was coax cable everywhere. (This was very early in the history of Ethernet and the IBM XT was just coming out.) To connect the "remote" office hundreds of feet away, we had a trench dug under the parking lot (and then paved over) to run cable to that other building. We had high-speed connectivity there. Today I parked within a few feet of that trench. Connectivity was still a challenge over 30 years later.
 
Long time no blog [link]
It's been a long time since I posted here on my blog. I've written a couple of essays that appeared on the main Bricklin.com web site, and I've tweeted a lot (as @DanB), and even did some podcasting as part of the Adventures in Alpha Land podcast series, but not much here. My day job at Alpha Software has continued to keep me very busy with other things.

You may have missed my Alpha WatchBench app for Apple Watch. See "How Alpha WatchBench Came About" on my main web site.
Archive   Home              Older
© Copyright 1999-2018 by Daniel Bricklin
All Rights Reserved.

See disclaimer on home page.