- Category: Miscellaneous
The whole "There's an app for that" was fun for a while, but now it's time for us to be able to do things without needing an app. A good example of an early implementation of this is with Google Now where it automatically figures out that I've parked my car and gives me directions back to it. With no action on my part. Here's an example:
The phone new it was connected to my car as I was driving, it also knows where my home is and that I'm not at it. So it figures that I probably want to be able to get back to my car once I need to go home and simply takes care of that for me.
That's awesome, useful technology that requires no action on my part. That's smart computing if you ask me.
- Category: Miscellaneous
For years I've wanted to be able to use voice to interact with the systems around me. I want to be able to talk to my computer as I'm working and in the house I want to be able to interact with everything in my house as I do things. I'm spoiled, I guess, by all of the Science Fiction books and stories I've read throughout the years.
I first got interested in this when I heard about Wildfire, a virtual assistant that ran within your computer. What was interesting about Wildfire (as I understand it) was that it was essentially a PC on a card that sat inside your PC and processed all voice inputs then acted on them. It was expensive and essentially required that you had two PC's, one inside the other.
I've waited and waited and waited for a system that I could just… interact with. I tried Dragon Naturally Speaking (didn't work for me) and constantly watched the industry for my perfect solution.
Much later, we got Google Now and Siri, both very capable voice interaction systems. They're awesome and very useful, but this isn't something I want on my mobile device, I want it in my surroundings – everywhere. Anyway, with these smartphone-controlled systems, they work great and save me a lot of hassle when I need to get something done and I'm tied up.
The problem is that I have to dig my phone out of my pocket to use it and that's not always possible. I carry my phone with me when I'm away from the house, but generally it's on my desk during the day (while I'm working) and still there when I go 'home' at the end of the day. I'm old, I didn't grow up keeping my phone with me at all times. Also, having worked at BlackBerry and being constantly connected taught me that I should put it down every night and ignore anything on it until the morning. I laugh when people call my mobile at night instead of just using my home number – not likely to catch me on the mobile at night unless I'm out of the house.
Another aspect of this is that I ultimately needed something that anyone in my family could use at any time. My wife doesn't carry her phone around with her when she's in the house either, and we have two children that don't have mobile phones, so we needed something that went with the house, not a person.
Anyway, this is a post about the Amazon Echo so I'd better get to it, right?
Last November, Amazon announced the Amazon Echo – a voice interactive system that sits on a counter or desk and waits to act upon your every command. Simply say "Alexa" (or "Echo") and she'll respond and try to deliver an answer to any question you give her or act upon any command she understands. I LOVED the idea and immediately (like 30 minutes after the announcement) requested access.
I waited. And continued to wait. I waited a really long time (more than a month) and never heard anything back from them. Disappointed.
About a month later, I had some family in town and mentioned the Echo to my brother. He immediately hopped online and requested his Echo. I assumed, wrongly, that since I got on the list day-one, that I'd get my Echo WAY before he did, so I didn't worry about letting him in on my little Echo secret.
Wrong! He got his Echo about a week or so later. Ugh!
Apparently, much to my chagrin, Amazon RANDOMLY selected the people who got the early Echos. I'm not sure they told me that when I requested mine, but who reads those disclaimers anyway, right? So, unlike most any get your new product process and most any product ordering scenario, Amazon didn't deal with requests on a FIFO basis, they simply randomly pulled names out and sent them their Echo's.
This was really frustrating. I wanted something like the Echo for so long and I was finally going to get my chance, but there was pretty much no way for me to get one. Sigh.
I started surveying my friends and found out that many other people got theirs – most having requested theirs after I requested mine.
So, like any able bodied American, I started complaining. I emailed Amazon Customer Service and was politely told that it was a random selection process. Frustrating. I started tweeting about it, making as public of a scene as I could without tarnishing my name to much and within about a week or so, Amazon sent me an email with information that would 'allow' me to order an Echo. I plunked down my order as fast as I could only to learn that my Echo wouldn't ship for months. Everybody else requested theirs, got an email allowing them to order very quickly then got their Echo in no time. For me, I had to wait months for an invite then another set of months to actually receive it.
Not really handled very well by Amazon.
Anyway, I finally got my Echo and I LOVE it. I'll write more about it here when I get a chance.
As much as I'm complaining about Amazon, I understand why they did what they wanted. I'm pretty sure they made me wait to get an Echo simply because I requested one as soon as I learned about it. When testing mass market devices like this, you want some early adopters, of course, but what you really want is a wide sampling of users – and sending Echos to the thousands of first-day orderers would not help them get a sampling of non-technical folks. They had to let word of mouth get interest generated for the everyday people, so they could have a better test.
- Category: Miscellaneous
As you may have heard, my position at SAP was eliminated back in March. Out of the options I had before me, I accepted a position at Forrester Research as a Principal Analyst in the Application Development & Delivery area. I'll be one of three folks on the team focusing on mobile development plus I'll stick my nose into other areas of AD&D as I get comfortable.
My new position will have an impact on what I will be able to publish here. Anything related Forrester's business will be published in formal papers or posted to my Forrester Analyst Blog (I'll post a link here once I get it setup). I will be able to talk a bit here about the tools and frameworks I'm playing with. I'll also be able to cover some technical topics here that are too deep for the traditional analyst fare. We'll see what happens; I want to continue to write here, but I need to be sure it's the right content.
- Category: Miscellaneous
I've been having a conversation lately with a former colleague about voice control of physical devices. As I mentioned yesterday, I purchased an Amazon Echo and just love the way it's transformed my kitchen. My family is playing music, setting timers, checking the weather and adding fun and interesting things to the shopping list.
I'm struggling a bit because I want to be able to control another device in my house using the Echo. My former colleague works for the company that makes that other device and I've been trying to understand their plans for either integration with the Echo or direct voice recognition in their device.
I initially thought that I wanted the Echo to control everything, but then I realized that I will probably only have an Echo in my kitchen and I have other products all throughout the house that I want to be able to talk to (thermostats, streaming music players, lights, locks and so on). While I really don't want different voice control systems to learn the syntax for, I realize that there's likely not going to be a way to have a single source of control unless I do put an Echo in every room. At $199 each, that would be a challenge.
Anyway, during these conversations with my former colleague, it became clear that there are privacy some concerns about the Echo. In my mind, the Echo is sitting there idly listening for its command word, and only then does it wake up and listen to what else you've said. It's possible that the Echo is listening to everything we say, but is that really something that's important to Amazon?
The amount of data being processed and uploaded to Amazon would be staggering. Now, they could be listening for key phrases, keywords as it were, and sending them up, but again, that could be a seriously large amount of data as well.
I think of bigger concern is that someone could hack the Echo and then start listening to everything we say. The government would be a good candidate for that as would anyone in the industrial espionage area, but is this really something we need to actually worry about? I think the answer to that is both no and yes.
No, I don't think Amazon is listening to everything we say. Well, that's not correct, the Echo IS listening to everything we say, but it's not 'using' any of it until after it hears someone say 'Alexa.' However, I really don't have any concrete proof of that – it's only what I figured out myself as I thought about how the Echo works. I don't think we need to worry about this as I trust Amazon to do the right thing. However, I should probably assume nothing and actually find out what they do so that I can be better prepared.
Yes, I think we should worry about this. Just because you're paranoid doesn't mean someone's not out to get you. We already have voice control in Google Now and Siri and my 8-year old automobile has a voice control module although the car is not Internet connected. However, we are about to start putting voice control devices all throughout the house and eventually everywhere else.
I've read a few books about the NSA and what Edward Snowden did, so I'd be surprised if the Government didn't start listening to that stuff as well (looking for keywords of course, then digging deeper). Again, I'm not paranoid, but I do believe in having reasonable expectations. If the NSA is really looking at all of our Facebook and Twitter posts, and listening to our phone calls, then how much of a stretch is it to imagine them hacking into our houses and listening through these voice-control devices?
- Category: Miscellaneous
We have an Amazon Echo and I love it. It was a pretty frustrating process getting one, but that's for another post.
Today I thought that Mother's Day was tomorrow. My wife informed me that it's not tomorrow, it's next week. Dodged a bullet there. I've been experimenting with the Echo, trying to understand what she understands and what she doesn't. Did you know you can get her to stop playing music by telling her 'Shutup b#tch'? That surprised me, but at the same time, didn't. Anyway, I asked her when Mother's Day was and she told me it was the second Sunday in May. I didn't know that, so it was nice to have that detail. I really wanted the date, so I asked her "What date is the second Sunday in May". She didn't understand my query for some reason. As you can see, I didn't ask her what I really wanted to know, so my fault for her getting it wrong. What I really wanted to know was the date for Mother's Day, perhaps I should have asked her that.
I was looking at the echo app a little while later and noticed that the app was showing me what she heard and asking whether she got it right. What she heard was "What is the second Sunday in Maine?" Close, but wrong. I indicated in the app that she got it wrong and once I did that, a pop-up, well, popped-up asking if I wanted to provide more feedback, so I said yes and entered what I was trying to search for in the input field. When I clicked Submit (or whatever it was) apparently it sent an email to Amazon with my feedback.
Cool stuff, get me to help them tune her algorithm. It's Google Voice all over again.
What happened next is where it got…weird. A few minutes later, I get a call from an Amazon Echo support person wanting to talk with me about my issue. That's cool; not what I expected, but cool.
As I started to talk to the guy, he said he couldn't talk to me until I confirmed the answers to some security questions. What? You called me and you want ME to confirm the answers to some security questions? Nope, no way – refuse to do it.
It's a closed loop, from the Amazon Echo app to Amazon support all the way back to me. What value is there in me proving that I'm who I say I am? You called me, right? I don't have an issue when I call them and they need my security questions answered in order for me to prove I'm me. But when you call me, I really don't feel inclined to confirm to you I'm who I say I am.
You called the number you have for me in your system and I answered. I'm not trying to make any purchases or change anything on the account, you're merely calling me about some feedback I provided you on the accuracy of the Amazon Echo's text recognition algorithms. No need for security questions in this case.
Anyway, just on principal, I refused to answer the security questions and explained why (that it was simply a matter of principal and I generally refuse to do stupid things unless I have no other choice). After I hung up, I thought about something. Answering the security questions IS a security issue – what if my email from the Echo app was intercepted (I can't understand why Amazon would use email for this and not a secure HTTPS connection through the app) and the phone call was a Phishing attempt to get my answers to my security questions so they can use them to impersonate me? Nope, not doing it.
What do you think? Am I crazy? Stupid?
- Category: Miscellaneous
It seems like I'm becoming more of an app guy lately. It was an interesting realization for me as it's surprising that I've been in mobile for 10 years, but just now seem to be getting into apps.
Of course, spending some time thinking about it, it's not surprising.
My entry into mobile was through BlackBerry; I was a Technical Manager, Applications – meaning that I helped customers understand how they could build apps for the BlackBerry platform. I was a developer supporting developers and, at the time, not much was available for consumers, it was all enterprise apps. Since enterprise required having access to back-end enterprise data, and I didn't use any enterprise apps at the time, not much was available to me.
Next I headed over to BoxTone (now part of Good Technologies) and was focusing on BlackBerry server performance and BlackBerry device performance. Not many apps for me to rely upon. That and I was a BlackBerry guy as the world abandoned BlackBerry, so even less interest in apps.
At AT&T, I was part of a sales team selling mobile application platforms. These were Mobile Enterprise Application Platforms (MEAP) and Mobile Consumer Application Platforms (MCAP) which was all eventually renamed to Mobile Application Development Platforms (MADP). In my focus on platforms, I knew how to build apps for the Antenna, Pyxis (now Verivo) and Kony platforms, but was so busy with development stuff, that I really didn't use a lot of apps. That and working for a carrier, I was constantly switching phones; switching between BlackBerry, Android, iOS and Windows phones – there was really no way for me to use a big app catalog with my device in flux.
At this point, I started using and writing about Apache Cordova and Adobe PhoneGap and therefore had a ton of sample hybrid apps on my devices, but none of them helped me much in my day to day activities.
Next was SAP and I was fortunate enough to be a product manager for part of a mobile development SDK and again focused on helping enterprises build their mobile apps. For a while, I stayed on BlackBerry, but eventually switched to Android. I started using more and more Android apps, but ultimately I stopped traveling so had less need for apps as I moved around.
During my transition from SAP, I started having trouble with my Android phone, so I activated a Windows Phone device that Microsoft was kind enough to give me as I worked on my last book. I struggled a bit with the device since some of the apps I found to be critical (like the Sonos app and the Amazon Echo app) weren't available on Windows Phone. Time to switch back to Android.
I'm getting ready to make a BIG career change and because the company I'll be working with supports a bring your own device (BYOD) environment, I had to buy my very first smartphone (the first one I ever paid for) and my second iPad. I've been reading some books lately on mobile apps and I started researching more apps and loading them on my device. I think the quality and quantity of apps available to consumers is great. I think the separate app for each activity or relationship is a flawed approach, but I'm enjoying getting all of these apps and making them a part of my daily routine.
Already, I'm finding myself spending more and more time with the following apps:
- Sonos: controlling the music that surrounds me
- Pandora: when I want to listen to music when I only have my tablet or smartphone near
- Zinio: Unfortunately, a few of the publications I read are ONLY available in electronic format; I HATE that.
- Flipboard: I LOVE flipboard, that's how I get all my news now
- Banking and Credit card apps: direct deposit is way overdue.
- Google Drive and apps
I used to hate the zinio app, but it's gotten better although it's still flawed in a great many ways, at least it works most of the time (which is an improvement).
There's a bunch more, but you see my point. So many aspects of my day are enhanced through the information provided by these apps. Notice that I'm not playing games – too much other stuff to do.
- Category: Mobile Development
My latest book, Apache Cordova 4 Programming (www.cordova4programming.com), is now available in stores. This is my 7th book overall and my 4th book on Apache Cordova/Adobe PhoneGap.
The book is written for mobile developers who want to learn about Apache Cordova 4. If you’re brand new to Cordova, then this book will be just what you need to get started. If you’re experienced with an older version of Cordova, this book can act as a refresher plus will show you in detail how to use all of the new stuff that’s in Cordova 4. You will need to have at least some experience with mobile development to directly benefit from this book. The target audience could be existing web developers who want to get into mobile development, but much of the needed native mobile development background just isn’t in here. Sorry!
What you’ll find in the book:
- Lots of detailed information about Apache Cordova, what it does, how it works and how to use the available tools and APIs
- Lots of examples and code; for even more code, be sure to check out my Apache Cordova API Cookbook (www.cordovacookbook.com)
What you won’t find in this book:
- Mobile web development and mobile development topics; this is a book about Apache Cordova, not mobile development
- Expressions or phrases in languages other than English (I hate it when authors include expressions from Latin or French)
- Obscure references to pop- culture topics (although there is an overt reference to Douglas Adams’ Hitchhiker’s Guide to the Galaxy and one obscure reference to Monty Python)
- Pictures of my children or my pets
This book is not a book for experienced Cordova 4 developers – if you consider yourself an experienced Cordova 4 developer, then you probably should not buy this book.
Herein I tried to provide complete coverage of Apache Cordova 4; covering enough detail that readers will leave with a complete understanding of what Cordova is, what it does, how it works and how to use it for their mobile application projects. There’s a whole lot more to Cordova, many advance topics and more detailed coverage of the Cordova APIs which is covered in the Cordova documentation or in blogs.
This book started many years ago as a book called PhoneGap Essentials (www.phonegapessentials.com); the book was all about PhoneGap 2.0 and was published right about the time the project name changed to Apache Cordova. The book weighed in at about 300 pages long. The book’s first 150 pages covered the available tools and everything a developer needed to know to configure a development environment then create, write, build and test PhoneGap applications. The second half of the book provided a detailed deep dive into each of the (at the time) PhoneGap APIs. The cool part of this second half was that it included, for each API, at least one complete, functional sample application that demonstrated each aspect of the API. The framework’s documentation was pretty useful in demonstrating how the API worked overall, but PhoneGap Essentials provided much more thorough examples.
The book went on to become the bestselling book on the topic and it was used in university courses around the world. According to Amazon.com, people are still purchasing this book today.
With the release of Apache Cordova 3, I reworked the manuscript and published Apache Cordova 3 Programming (www.cordovaprogramming.com). This book also weighed in at 300 pages, but was essentially a rewrite of just the first half of PhoneGap Essentials with only cursory coverage of the Cordova APIs provided. This allowed me to go into much more details on the tools and development process.
Unfortunately, the book was only available as an ebook, so most readers didn’t even know it existed. This was exacerbated by Amazon’s refusal to link a printed book to an updated version in a different format; I could point people interested in the ebook version of PhoneGap Essentials to the ebook version of Apache Cordova 3 Programming, but I could not do the same for the printed version. The side effect of this was that people continued to buy PhoneGap Essentials even though it covered an older version of the framework.
In order to accommodate those readers who were more interested in the Cordova APIs, I reworked the second half of PhoneGap Essentials into another 300 pages called Apache Cordova API Cookbook (www.cordovacookbook.com). In this book, the complete example applications from PhoneGap Essentials were enhanced and expanded and all of the book’s content updated for the newer version of Cordova. I’d not covered some topics as well as I would have liked in the first book, so this update allowed me to really expand the coverage of some topics and include even more complete sample applications (32 I think it was).
Between Apache Cordova 3 Programming and Apache Cordova API Cookbook, I had written more than 600 pages of coverage of Apache Cordova 3. That’s more than twice the size of the original book and a lot of good information for developers.
With this book, I’ve updated Apache Cordova 3 Programming for Apache Cordova 4 plus included new content on a bunch of topics. In my previous books, I focused primarily on PhoneGap and Apache Cordova; I didn’t cover many third-party tools and left many mobile development topics uncovered as well. For this book, there were a bunch of additional tools available and some hybrid-focused HTML frameworks so I decided to cover as many of them as I could in the space available to me. Where this book’s predecessor was 300 pages, this one should top out at over 500 pages, so there’s a lot of really good information here for all types of Cordova developers. When bundled with Apache Cordova API Cookbook, you’ll have more than 800 pages of information about Apache Cordova.
Herein you’ll find most of the same topics as were covered in Apache Cordova 3 Programming, the only missing topic is coverage of the BlackBerry platform. I wrote the first book on BlackBerry development and had pretty much always carried a BlackBerry device, but between books BlackBerry experienced a dramatic drop in market share and I started carrying an Android device as my primary device. Additionally, in previous books I had the enthusiastic support of my former colleagues at BlackBerry, but when it came time to get feedback on the BlackBerry chapter in Apache Cordova 3 Programming, the development team stopped responding to my inquiries. Because of those two things I decided to drop support for BlackBerry from this book.
So, what new stuff have I added in this book? Coverage of:
- Plugman and the PhoneGap CLI
- Cordova’s support for Firefox OS and Ubuntu devices
- Automation (Grunt and Gulp) and Cordova CLI Hooks
- Microsoft’s hybrid toolkit for Visual Studio
- Third-party tools such as AppGyver, GapDebug, THym and more
- Third-party HTML frameworks such as Bootstrap, OpenUI5, Ionic, Onsen UI
There’s a lot more, but that’s just the highlights.
The one thing I cover in the book, but not in tremendous detail is how to build custom Cordova plugins. I cover the topic and show you how to create two complete plugins, but this isn’t a native mobile development book and that’s a native mobile development topic. I’ve learned from my readers that the material I do provide is enough to help a lot of people get started with plugins and create their own plugins; I’ll leave it up to another author to write a book dedicated to plugin development so it can get the attention it deserves.