It is not without some sadness that I write this post.
For the last five years, it has been my pleasure to dive deep into the Salesforce1 Platform community. I have shepherded the Salesforce1 Labs program, helped launch AppExchange Checkout, delivered the IoT Zone experience at Dreamforce 2013 and co-delivered it for Dreamforce 2014. I have met thousands of developers, admins and partners; diagnosed problems, challenges and opportunities; and talked with CEOs, CIOs and CTOs about their businesses. I have presented on a large number of topics at user groups and conferences around the world, and worked extensively with Salesforce’s uniquely awesome Sales Engineer, Account Executive, Customer Success, and Services teams.
And make no mistake: it has been my honor to work with a great crew of Developer Evangelists and an incredible Developer Relations team. They have been fantastic and inspirational co-workers. They have pushed me to be better and I have learned a ton from them in the process. I am incredibly grateful to have met them!
Yes, the last five years have been fantastic.
However, these words (penned by fellow Kenyon College grad Bill Watterson) have often bounced around in my head:
And so I have decided to embark on a new adventure.
Later this week I officially transition to the Salesforce Marketing Cloud where I will help manage a collection of products on the mobile team, including MobilePush. We have a great team working on these products, and a great crew of customers using them. It is a huge opportunity for Salesforce and I am very excited about the chance to shape it.
Best of all, I still get to work with the Salesforce developer community: one of the key outputs of my new team is a series of developer facing mobile SDKs (checkout the Github account).
These last few days have been more emotional for me than I predicted. My last regularly scheduled 1:1s with my team in particular — such a great crew!!
A big thank you to Salesforce for this new opportunity, and a big thank you to everyone I’ve worked with — in and out of Salesforce — over the last few years. Here’s to many more together!
Yes, this is change, but I’m not going far. You’ll still see me at Salesforce events and I’m still only an email or tweet away. Let’s definitely keep in touch, and if you have a question about Salesforce Marketing Cloud mobile apps, please reach out!
This year, I ignored everything but my little portion — the DF14 DevZone Internet of Things area — and it still took me three pretty long posts and almost 3000 words. What a difference a year makes!
Whether we finally see an iWatch tomorrow or not, all of this frenzy around wearables made me curious what the timeline on the architectural approach looks like. So I did a little research and came up with the following table. This is incomplete for sure, but I found a few things that surprised and entertained me, so here it is for your enjoyment. Comments, additions, criticisms all welcome on @ReidCarlberg.
Format: Earliest Date Seen or Announced – Name (Category) – Link for More Information
09/09/2014 – Apple iWatch Maybe (Unknown) – Apple.com
I’m in the thick of Dreamforce prep. This will be my 8th Dreamforce, and I find myself reflecting on what it’s meant to me over the years.
2007 — The band was INXS, and I was a brand new Salesforce consultant. The company I was with at the time — Model Metrics — won an “Appy” award for something we did. Pictures from that time show me wearing — gasp — a suit. My first time at Dreamforce spoiled me for other conferences. Even then, Dreamforce was a very happy place. Everyone was high energy, the partners were awesome and I felt like I was part of something much bigger than me. By the end, I was completely exhausted, and when someone stuck a camera in my face and asked, What was your favorite part of Dreamforce? I said, “The cheese plates.” Really. Hint: you should probably have a better answer. For example, I should have said, “Talking to all the Salesforce customers who came by our booth.” I love love love staffing a booth. Call me crazy, but it’s true.
2008 — I don’t remember the band, but thankfully @eliz_bethdoes — it was The Foo Fighters. I don’t think I went, and I regret this. This Dreamforce stands out for me because it was the first one I spoke at. I co-presented at a session on Salesforce and GCal integration. Yes, I was wearing a suit. Now, this was also the first year Salesforce offered the Certified Developer credential and I was very excited to be part of the first 500 group. If you attended the Model Metrics party at Foley’s that year, you probably also remember the dueling pianos in the basement. It was hot and crowded and a great time. The great thing for me about 2008 was getting to know people in the community better. Where DF07 was brand new, DF08 was more like a homecoming.
2009 — This was a big year for me. I had written and iterated on an app called Cloud Converter and had completed a big project working with the Salesforce partner team, and I was speaking about both. I had a great time preparing for these presentations, and got great feedback. After one of the, a friend came to me and said, “You were born to speak like this.” I was very humbled and surprised to hear that. Public speaking is something I’ve always wanted to be good at, but I hadn’t found many opportunities to exercise that muscle. Also in 2009, Jeff Grosse, Miriam Melo and I started “The Octies,” the only canned-seafood themed community recognition award in enterprise software (still!). Yes, the prize was a can of Octopus. Incidentally, I was still wearing a suit.
2010 — This was my first year at Dreamforce as a Salesforce employee, and attending Dreamforce as a Salesforce employee is a little like being part of a giant wedding. There’s always 100 more things to do, but Dreamforce is going to happen as advertised no matter what, ready or not. So you work and you plan and you hope and you rehearse, and then you do all of that some more. When I showed up in San Francisco, I remember very clearly thinking to myself, “WOW all of the work has totally been worth it.” My focus in 2010 was Salesforce1 Labs — or Force.com Labs as we called it at the time — as well as many of the “Introduction to X” sessions. Introduction to Data Modeling. Introduction to Visualforce. Introduction to Apex. Intro sessions are always my favorite because you can see the lightbulbs going off over the heads of the people in the front rows. It’s very rewarding. Also, this time I was wearing regulation long sleeve t-shirts, which I still occasionally wear today.
2011 — My second year as a Salesforce employee, I was privileged to lead The Open Source Garage. Leading any section at Dreamforce is a challenge, the Open Source Garage was no exception. I helped recruit partners, organize sessions and conversations, and I spent a good deal of time in the garage learning a lot right along with the rest of the attendees. I also caught a cold. Let me tell you what, the one thing you don’t want at Dreamforce is a cold. I was definitely not at my best when the event started. Fortunately, if memory serves me correctly, I had at least one session with the inimitable Jeff Douglas on a panel, and that’s always a good thing. By the last day, I was feeling a bit better, but was a little anxious about my final session. It was the last possible spot, late in the day Thursday, which no speaker I’ve ever talked to has been excited about. It was on open source in the Salesforce community and it was packed. The audience was just as engaged on Day 4 as they had been on Day 1. I loved it.
2012 — Most of my time during 2012 was spent working with developers who wanted to launch businesses on the AppExchange. I focused on something called AppExchange Checkout and my Dreamforce was all about the different ways partners could sell apps. It was very interesting for me to work with so many of our great partners. Up until 2012, my AppExchange experience was limited to free apps, and “free” is a very interesting question when you’re dealing with enterprise software. Consumers pretty much demand free to start. Enterprises are much more interested in the total value proposition. In fact, “free” can turn out to be very expensive, so finding the right balance is challenging. It was a huge learning opportunity for me. I should point out that the 2012 concert was my favorite of all time: the Red Hot Chili Peppers at the Civic Center. It was crazy cool, and they put on a fantastic show.
2013 — Last year was a breakthrough experience for me because it was the debut of the Connected Device Lab. I was originally nominated to lead the lab based on some work I had done in 2011 connecting my model trains to Salesforce and there’s no way I could have pulled it off without my experience running The Open Source Garage. Now, I wasn’t sure how the Lab was going to be received–nobody was. No one had really done anything like it before. I arrived at Moscone on Saturday and started the setup process. While I was working, many of the tradespeople building the DevZone stopped by to watch and ask questions. On Sunday, the same thing happened with Salesforce employees. And I started thinking, Uh oh. Monday, all hell broke loose and I have to say I loved absolutely every minute of it, including losing my voice. This tweet and the response chain summarizes the whole thing for me. The experience was breakthrough for a few reasons. First and foremost was the response of our attendees. People were curious, engaged, and asked great questions. Second, it sparked fantastic conversations with a lot of people I really respect: Parker Harris, Peter Coffee, Charlie Isaacs at Salesforce and many, many other customers and partners. Lastly, it kicked off a great year of really interesting activity — ThingMonk, ThingsExpo, IoT World, M2M Evolution in both Miami and Las Vegas, #IoT Chicago and several really rewarding customer specific engagements. 10 out of 10 — would work hard for months, talk for 14 hours straight 4 days in a row and lose my voice for two solid weeks all over again.
So that’s my personal Dreamforce history. Dreamforce is unlike any other event I’ve ever been to, and I love every minute of it, before, during and after. It’s a time to connect with old friends, a place where I get to share what I’ve been working on and a unique opportunity to meet customers and learn about their needs. DF14 is shaping up to be great in a whole new way. See you there.
Update November 20, 2014: Mild update to code — moved the https include to the top in order to eliminate a non-responsive camera module.
TL;DR – I wrote a script on my new Tessel that posts images to Salesforce Chatter and learned a lot along the way. You can find the full Tessel Image Capture script over on Github and you can ask me about it on Twitter @ReidCarlberg. The screen cap above is an automatically captured picture of a 3D printedT-Rex Skull on Salesforce1.
Hello Tessel
The Tessel is a brand new hardware prototyping board that lets you code in Javascript rather than C. I first ran into it during their crowd funding campaign last year, and received my first unit last week. Since then I’ve had a chance to create my first simple app on the device, so today I’m going to share what I’ve learned so far. Tessel Review
If you’re already used to working with hardware prototyping boards, there’s a lot you’re going to like. There are plenty of analog, digital, I2C, SPI and serial ports to go around. You can use these ports to connect any old hardware you already know how to connect, or you can use one of their preconfigured modules. Pretty easy.
One thing that confused me since I first spied the prototype is the positioning of the interface ports. They’re bent at 90 degrees and so rather than facing up, they face out. (Note: in the picture above you can see that my C port is at a weird angle. Bent it somehow.) This design helps a board with a number of modules attached stay flat, which is particularly useful with something like the servo module where you’re going to connect a number of wires in. The GPIO port faces up as you would expect.
Basic interaction is super simple. You access all of the ports via standard Javascript syntax. For example, the blink app (“Hello World”, but for hardware), is just a few lines:
// Import the interface to Tessel hardware
var tessel = require('tessel');
// Set the led pins as outputs with initial states
// Truthy initial state sets the pin high
// Falsy sets it low.
var led1 = tessel.led[1].output(1);
var led2 = tessel.led[1].output(0);
setInterval(function () {
console.log("I'm blinking! (Press CTRL + C to stop)");
// Toggle the led states
led1.toggle();
led2.toggle();
}, 100);
You can run scripts from the CLI using the command “tessel run myScript.js”. Here’s what running the blink.js example looks like.
$ tessel run blink.js
TESSEL! Connected to TM-00-04-f000da30-006a473e-34b02586.
WARN No package.json or node_modules found. Deploying just this file.
INFO Bundling directory /Users/reid.carlberg/Projects/tessel-blink (~428 bytes)
INFO Deploying bundle (4.50 KB)...
INFO Running script...
I'm blinking! (Press CTRL + C to stop)
I'm blinking! (Press CTRL + C to stop)
.....
And if you want the script to run headless, you simply use “tessel push myScript.js” and you’re good to go. The script will start automatically as soon as it has power.
The modules are pretty easy to use, and they all come with node libraries and sample code. When you want to use a module, you simply insert it into one of the ports, grab the library via NPM and get to work. Installing the camera module, for example, is as simple as typing “npm install camera-vc0706”. My Tessel Sample App
My sample use case is pretty simple: when something is close enough to the Tessel, snap a picture and upload it to Salesforce. In this example, I connected my own proximity detector and used Tessel camera and climate modules. The first thing I wanted to do was connect to the Salesforce platform the way I usually do, with the excellent nforce library. Now, I’ve used it quite a bit, and have watched the npm install routine probably 100 times without really wondering about all of the components it requires. However, I couldn’t take that same laissez faire attitude when working on the Tessel. Although it is designed to be Node.js compatible, it’s still a limited device and larger, complex modules like nforce are too much for it to handle. This is not that big of a deal. In fact, it was a great excuse for me to get more familiar with some Node.js basics I’d managed to ignore until now, such as the HTTPS request object. Incidentally, before rolling my own OAuth2 and REST interactions, I also attempted to use the excellent request and restler libraries. No luck!
The good news here is that rolling your own autonomous client / username & password flow OAuth2 is pretty easy. Setup your connected app in Salesforce (example), send a few parameters to the endpoint and voila! you have an authorization token.
function handleOauth() {
log('handleOauth');
var body = 'grant_type=password&client_id='+clientid+'&client_secret='+clientsecret+
'&username='+sfuser+'&password='+sfpass
var options = buildRequestOptions('/services/oauth2/token', body, 'application/x-www-form-urlencoded');
options.hostname = 'login.salesforce.com';
log(options);
handleHttpsRequest(options, body, handleOauthCallback);
}
You can see I’ve built a few small routines to make this easier, but the main job is done in four lines of code. Add a callback to interpret the results, and I’m off.
Sending an Image to Chatter
The next step is capturing an image and sending it to Chatter. The good people at Tessel have made taking the picture extremely easy. The basic code looks something like:
var camera = require('camera-vc0706').use(tessel.port['A'], { resolution: 'qvga' });
camera.takePicture(function(err, image) {
if (err) {
log('error taking image', err);
} else {
//do something with the image
base64content = image.toString('base64');
}
On the Chatter side of the fence, if you can send an octet-stream directly to the Chatter API, you can use a single call and post a message and the picture at the same time. In theory, the image buffer should work in here, but I couldn’t get it to work on either the Tessel or my MBP. I ended up taking a note from @Metadaddy and an example from @CCoenraets, and did a 3 step process after base64 encoding the buffer object. Step 1, insert a ContentVersion object. Step 2, lookup the ContentVersion and get the ContentDocumentId. Step 3, insert a FeedItem that references the ContentDocumentId. The final Chatter code looks like this:
var body = {
attachment: {
attachmentType: "ExistingContent",
contentDocumentId: contentVersion.ContentDocumentId
},
body: {
messageSegments: [{
type: 'Text',
text: 'Here is a current picture. \nClimate: ' + currentClimateText
}]
}
};
body = JSON.stringify(body);
var chatterOptions = buildRequestOptions('/services/data/v30.0/chatter/feeds/record/me/feed-items', body, 'application/json');
handleHttpsRequest(chatterOptions, body, handleChatterCallback);
The other option for inserting the picture is to create a custom ApexREST web service. This is a good option if you want to minimize API calls, but it adds the extra complexity of creating that bit of Apex. Fortunately, that bit of Apex is easy to create. In fact, I had created something similar for the Share Wonder project I did a while back. Share Wonder, however, inserted the data into an Attachment object rather than a ContentVersion object. Before I wrote the ContentVersion code myself, I search a bit and it turns out that Maxim Fesenko over at Cloud Catamaran had written a blog called File Upload to Chatter Using the ConnectAPI just a few days ago.
My slightly modified version of the code from that blog post looks like this:
/*
* Totally copied from
* http://cloudcatamaran.com/2014/04/file-upload-to-chatter-with-using-connectapi-class/
*/
@RestResource(urlMapping='/TesselImage')
global class PostHelper{
@HttpPost
global static ConnectApi.FeedItem post(String text, String imageName, String imageBase64) {
ConnectApi.MessageBodyInput v_messageInput = new ConnectApi.MessageBodyInput();
v_messageInput.messageSegments = new List();
ConnectApi.TextSegmentInput v_textSegment = new ConnectApi.TextSegmentInput();
v_textSegment.text = text;
v_messageInput.messageSegments.add(v_textSegment);
ConnectApi.FeedItemInput v_input = new ConnectApi.FeedItemInput();
v_input.body = v_messageInput;
ConnectApi.NewFileAttachmentInput v_fileIn = new ConnectApi.NewFileAttachmentInput();
v_fileIn.title = 'title of file';
v_fileIn.description = 'description of file';
v_input.attachment = v_fileIn;
ConnectApi.BinaryInput v_feedBinary = new ConnectApi.BinaryInput(EncodingUtil.base64Decode(imageBase64), 'image/jpg', imageName);
System.debug('***Just about to insert');
ConnectApi.FeedItem v_feedItem = ConnectApi.ChatterFeeds.postFeedItem(null, ConnectApi.FeedType.Record, 'me', v_input, v_feedBinary);
System.debug('***Inserted');
System.debug(v_feedItem);
return v_feedItem;
}
}
And if you’d like to install it in your org, here’s an unmanaged package which yes of course includes full test coverage.
Tessel Lessons Learned
I learned a lot going through this sample app. Some of my key takeaways.
* Base64 encoding takes quite a while. A qqvga image (160 x 120) encodes in about 20 seconds. A larger qvga (320 x 240) takes about 2 minutes. A vga image (640 x 480) takes more like 20 minutes.
* System intensive actions like base64 encoding will block other actions you have setup on an interval. Once the encoding is done, all of the blocked actions will fire.
* Yes, the Tessel uses Javascript, but it’s still a constrained device. You should expect complex, memory intensive operations to be tricky. Every platform has constraints. The Arduino, for example, doesn’t handle JSON parsing well. Just because you can use Javascript on the Tessel, you shouldn’t assume you can use Javascript exactly as you might on more powerful platforms.
* The wifi is a bit tricky. Setup is dead easy — “tessel wifi -n MyNetwork -p MyPassword” — but the Tessel doesn’t have a huge antenna, and reception isn’t the greatest. I found areas of my house that work great for a larger device but not for the Tessel. They actually have a tutorial on how to add an antenna.
Finally, I would like to point out that the crew over at Technical Humans have been super responsive and helpful.
In the End…
In the end, I think the Tessel is a super interesting iteration on the hardware prototyping platform. Coding hardware using Javascript – even if it’s a little different than other places you use Javascript – is very interesting. I hope a lot of people buy one of these boards, because I definitely want to see what the future holds for this extremely interesting team.
The Internet of Things, the Internet of Everything, the Industrial Internet — whatever you call it, connected devices are a fantastic gift to any business that wants to get closer to their customers. The pattern captures people’s imaginations and many of the predictions feel like magic, but IoT solutions are hard to get right. If you’re trying to decide on your first project, you probably have a lot of questions. Here are six critical things to keep in mind as you move forward.
#1 Pick a Great Use Case
There are a lot of fun IoT use cases around the Internet. Many of them don’t matter. In the interest of keeping good relations with the rest of the world, I’m going to call out something I did as a fantastic example of a trivial exercise: the Coffee Copter, detailed in the video below. As you pour a cup of coffee, a quadcopter takes off. As you empty the cup, the quadcopter lands.
Now, as fun as that was, it was an execise in can you do something, and these days can is the wrong question. You need to be asking yourself should questions. Should I connect a coffee urn and a quadcopter? No.
But there are lot of areas where the answer is yes.
One of my favorite examples in this department is New England BioLabs. NEB sells supplies to medical researchers. As part of their sales process, they stock these supplies in a freezer at their customer’s location. Now, it used to be that they had a hard time knowing the right supplies to stock, validating that supplies were kept at the right temperature, and tracking the researchers that used a specific item. NEB solved this by transforming their freezers into connected devices and now they know the researchers, they know the supplies and they know the temperature history for each item.
I’m sure we can all agree that medical research is a worthy cause. But not everyone is a healthcare researcher, so you have to find a similar problem in your business. You need to start by identifying the target outcomes your customers are looking for, and then come up with ways to help them achieve those outcomes more reliably. When you do this, you deliver additional value and build better relationships.
These outcome oriented use cases are what matter, and you should start with them.
#2 Create a Great User Experience
Once you decide on the right use case, you have to create a user experience that delights your customers.
User experience, UX, determines how people engage with your solution, and there’s no one UX for every product. Your UX goal should be two fold. First, if possible, your new solution should fit into what customers already know how to do. Second, it should reduce the friction of what they have to do to realize the value it delivers. Great UX not only disappears into the environment, it makes the environment better.
The current generation of fitness wearables is interesting example of good UX. Fitbit, for example, has no buttons. All you have to do is put it on and the technology does everything else in the background. Now, on the down side, the user also has to tap the device from time to time. It’s easy to get the hang of, but I wouldn’t call it natural, and it still requires a local gateway rather than being able to magically talk directly to the cloud. There’s no great way around that right now, it’s a constraint that the technology hasn’t eliminated yet. But the first wearable that includes some sort of background connectivity will have a tremendous advantage.
#3 Community & Collaboration
I’m not talking about the network of connected toasters or refrigerators complaining to each other about being out of milk. I’m talking about actual people. People value interacting with other people in context of things they care about. In fact, they value it so much, if you don’t create a destination for the community that pops up around your product, your customers will probably create one on their own.
There are three main types of communities to be thinking about.
The first is a data-centric community. Runkeeper has created an excellent example of a data-centric community. Data-centric communities take the output of the device and interact around it. In Runkeeper’s case, this is a leader board comparing the number of activities between you and your friends (yes, that’s me at the bottom). Most fitness wearables have data-centric communities as a core part of the product.
The second type of community is product-centric. Product-centric communities are more about how to use things, news from the company, tips and tricks, etc. PrintrBot has an excellent product-centric community. Interestingly, it’s not operated by the company itself. Customers created their own informal community. Today the company has an official one as well, but the original continues to thrive.
The third type is transaction-centric. Say you manufacture MRI machines, and you connect those MRI machines to an enterprise backend like salesforce.com. When the MRI machines have actionable data, that data gets posted to Chatter, and all of the people who have a legitimate interest in it can collaborate around that particular post. MRI techs, doctors, hospital staff, biomed technicians, and external contractors can create a short lived, ad hoc community around that transaction. (The screenshot above is from this video, a couple of minutes in.)
#4 Developer Experience
Open Source has shown time and again that remix is often more valuable than the original. And although I won’t presume to say you should open source your core IP behind whatever connected solution you land on, I think its critical you have an easy to understand, well documented and powerful API that developers can harness.
A great example of a good out of the box Developer Experience (DX) is Automatic, the car tracking company. With Automatic, you pair an OBD-II device with your phone and track driving patterns. Automatic launched with an API out of the box, and they exposed their API using a number of standards. For example, it has a REST API and handles authentication via OAuth2. This definitely sets them up for developer success, and people are doing great things. (Note that Automatic’s API is still in beta. That’s fine.)
Like the community, the funny thing is that if you don’t deliver an API out of the box, chances are good someone else will attempt to. Take the example of Kickstarter success LiFX. It took a year for them create and ship bulbs to their backers, and they did so without an official API. However, an unofficial API showed up on Github in days. Now the challenge here is that an unofficial one is OK, but people don’t have a lot of confidence in it. Meanwhile the Philips Hue, their competitor, has had a reasonably good API for quite a while.
This all begs the question of Nest. Nest doesn’t have a public API yet which probably makes you wonder if you really need one. My opinion is that most of the time yes you will need one. Nest has proven to be a successful exception. There may be more exceptions, but I suspect not many.
#5 The Right Amount of Data
In order to succeed, your IoT solution needs to gather enough data to create accurate, actionable insights for your users. Is this Big Data? Yes, but your users don’t want and can’t handle big data. They want the processed results.
How do you handle big data if you don’t already understand it? The right thing to do is partner with a company who already has the expertise, of which there are an increasing number. Companies like Etherios, 2lementry and Axeda, just to name a few. Can you develop it yourself? Sure, but see the above discussion about can versus should.
Processed data is where the action is. A typical IoT value chain has a number of components, all of which are easy to get lost in, but processed data, that someone can act on, will drive the success or failure of your product. User experience plays a critical role here as well, although it’s a different set of users: internal users. If your use case involves helping customers achieve better outcomes from their purchase, and it should, then the processed data needs to sit very close to the customer data so people can take quick action on it.
Learning what data is valuable will take some trial and error, and the data that’s valuable today will be different that the data which matters tomorrow. You need to figure this out for your customers.
#6 Non-Technical Integration
Connected devices open up new and interesting future possibilities, but they have to play well in the current world with all of it’s existing requirements. A good case in point is government regulation.
Brivo Labs is a great example of a company that understands the impact of regulatory requirements on IoT solutions. Brivo Labs is an access management company that’s a spin off of a well established commercial security access control company with a deep understanding of regional building codes. This kind of knowledge is absolutely key to working effectively with existing markets, and they’ve used this to create a number of interesting products, including an iBeacon enabled app that works with Salesforce Identity called Rändivoo.
Nest experienced an interesting result of regulatory requirements when they found a problem with their smoke detectors. They started to fix it and then received a demand for a recall from the Consumer Product Safety Commission – six weeks after their own disclosure and initial action. This kind of interaction can be very distracting for a business, especially when it’s not planned for, but the reality is that even the most leading edge companies are still subject to it.
Source. Note that as of this writing, Nest Protects were not available on the Nest website. This letter from Nest CEO describes the situation.
Now is the Time to Jump In!
I hope this list is helpful. The Internet of Things is an architectural style that will drive really interesting innovation in the coming years. There’s a lot of detail around creating an IoT solution, but you shouldn’t let that stop you from jumping in. Now is a great time. Companies are increasingly turning to connected customer experiences as a way of delivering what all customers really want: better outcomes.
If you’re looking for more ideas and inspiration, you should take a look at the ever growing list of artifacts created by some of the leading thinkers in the space. I recommend the videos from ThingMonk, ThingsCon and SolidCon as a great place to start.
I’d love your feedback on this or any other article.
The Internet of Things — IoT for short — is the new black, but most people still can’t explain what it is or why the average person, developer or CEO should care. Let me break it down in 5 easy to understand steps.
#1 Nobody Wants Your Product
I want to start off by setting the stage with a very simple fact: nobody wants your product. I don’t care if you make smart phones, cars, houses, bathroom scales, pens, pencils or chairs. A priori no one wants your product.
This is confusing. We often conflate the effects of marketing and advertising with inherent desire and generally that inherent desire just isn’t there. Now, if your products are food staples, or maybe art, I’d open that up for discussion but once you get beyond those basics – once you get into the very specific realm of, for example, prepared sandwich cookies, desire isn’t natural, it’s manufactured.
#2 People Want Outcomes
People want outcomes. Smart phones provide connectedness. Cars provide safe transit from point A to B. Houses help us feel safe.
Products and outcomes are different. Sometimes it’s difficult to remember that they’re different while caught up in the day to day world of making things and selling them, but that’s why people buy products.
They want outcomes.
It’s always important to ask, what are people getting out of this product? Why are they buying it. It’s the why that matters.
#3 Technology Enables Better Outcomes
I’ve been in technology most of my career. The reason I like technology is simple: technology enables better outcomes. The has been true for a long time, since long before we called it “technology” (a term that joined us in the 17th century) and long before there was a tech industry (coined in the 20th century).
Think about Gutenberg’s printing press (from the 15th century). Gutenberg’s printing press was the quad-copter drone of it’s day. It made “printing” a thing. Before Gutenberg, creating new books meant copying by hand. For centuries, control of the printing presses conferred a huge amount of power.
Computing power is the same. It started with mainframes, went to PCs, then the Internet and now everyone carries a wildly connected supercomputer in their pocket that fundamentally creates better outcomes for them every day.
Importantly, these better outcomes still require a device, an intermediary, something that separates the user from the computing power.
#4 IoT Breaks Computing Power’s Fourth Wall
The fourth wall is a metaphor describing the relationship between the performers and the audience in a theater. The fourth wall keeps the actors on the stage, safely separated from the audience in their seats. Breaking the fourth wall, a concept that started in the 19th century, is all about engaging observers in the performance.
IoT, as a technical architecture, is fundamentally about eliminating computing power’s fourth wall. IoT embeds computing power among the diverse devices a user might rely on to improve outcomes and reduces the intentionality required for a user to engage it.
IoT is a great marketing term right now as well, which means it’s sometimes used out of context. That’s OK. Marketing terms, even those lacking precision, can be useful organizing principals that help people talk about similar ideas in a similar way.
#5 All Estimates of IoT’s Impact are Too Small
You’ve probably heard 75 billion devices and $14 trillion in revenue opportunities. These are huge numbers — mind boggling — which is great — but kind of insignificant when you switch your default mindset to assume every thing you come into contact with every day will soon have incredibly rich computing and communication capabilities.
Think a decade out, or two decades out, when the standards are agreed on and the technology stack is mature. Suddenly, I Dream of Jeannie is the new normal. But instead of Barbara Eden crossing her arms and nodding her head, it will be you, conducting the technology embedded everywhere around you, without thinking about it.
Sensors, robotics and technology we’re not even talking about yet will turn I Dream of Jeannie into brilliant speculative fiction instead of a quality sitcom.
IoT is the organizing metaphor that will help us get there.
…And We’re Just Getting Started
I hope this paints a clearer picture of IoT. This architectural style is just getting started and people are thinking about it in many different ways. It doesn’t matter that we don’t agree on all of it yet, or that we don’t have all of the technology worked out. That will happen.
This sponsored article over on Gizmodo is a little FUDdy but it asks what I think is going to be an increasingly difficult question to answer: who has dominion over the data I emit?
In the case of a regular human, a typical IoT device user will passively generate massive amounts of real time data. This is exactly what we regular humans want. The more predictably this data is generated, the less conscious effort it takes, the more useful it will be for later analysis.
However, already today, data goes any number of places. It can go the obvious places, and then it can live on in a much broader context via distribution to 3rd parties. After all, any data interesting enough to gather is valuable enough to sell.
This situation presents three risk areas. The first is the primary service provider (phone, device or system), second is any third parties you authorize via terms and conditions and last is add-on capability providers, like apps, which might also leak to third parties. Are these really “risks”? Well depends on who you are and what you value.
Now this is just for regular humans. Imagine the complex web of risks a modern business faces adopting IoT solutions at scale. The good part for businesses is that many business providers address this confidentiality concern contractually as a core part of their business. If you are a business owner, you should clearly understand where the data you generate goes and what that means for your business.
Back on the regular human side, it’s another story. Facebook and Twitter have demonstrated clearly that regular humans are more interested in short term functional capabilities than long term data re-use and analysis. It’s therefore tempting to call for government regulation to address the issue. That might work in the EU but it has a snowball’s chance of passing in the US. In the US, I’m not sure what the right thing to do is. It might be our only option is third party services that monitors our data and alert us when something goes awry, but at that point it feels like the chicken has flown the coop. What would be super useful is some sort of labeling that reminds us what’s happening, a human readable privacy policy, but even that feels a little late.
Maybe there’s room for something similar to “organic” labeling or MPAA ratings, a third party evaluation that regularly inspects a service providers business and contracts, and then awards a regulated label based on what it finds.
As a cohabitant of two good sized dogs and a couple of kids, I am both thrilled and disgusted each and every time I empty my Roomba. The initial, “Wow! Look at everything it picked up!” is inevitably followed by, “How could there be so much dirt?!”
I have the Roomba 595 model they sell at Costco for $299 which my kid named “Bob.” Totally worth it. I’ve had to make a couple of small modifications to ensure everything works as I would like, so I thought I would share them.
First, make sure your cleaning area is Roomba friendly. Tuck cords and power strips away, ensure the things it might run into are stable enough to stay standing when hit and be sure there are Roomba-width access paths to the areas you want cleaned. Bob has pulled down and broken my wife’s alarm clock and knocked down wooden gates that were leaning peacefully against a wall. Not the end of the world.
Second, if you have black flooring, know ahead of time that the Roomba’s excellent and self-preserving edge detection will mistake these for edges and NOT clean them. If you tape small white pieces of paper over the edge detectors, you can mark danger zones with virtual walls. This way you don’t send your Roomba tumbling down the stairs and it cleans your black carpet. Bob is much happier cleaning our black-edged dining room rug with these in place.
Third, schedule it to run every day. Yes, you could run it once a week or every couple of days, but a daily schedule is the best way to ensure it’s doing its job. I have noticed that Bob will occasionally lose its schedule. I don’t yet know why, but I assume it somehow used up too much of its battery.
Trouble Spots
Here are a couple of areas where Bob gets stuck. I haven’t figured out a way to fix these. Also, the black flooring fix I mention above doesn’t play well with these troublespots. The Roomba goes into a cycle of saying “please move the Roomba to a new location” that can only be fixed by removing the edge detector covers, which you’ll then need to reapply in order to get it to start cleaning your black flooring again.
Designed to provide a quick start for engineers looking to begin exploring IoT design concepts, the Connected LaunchPad omits many of the options included in a full-featured development kit such as the $200 TI TM4C129x Connected Development Kit (Table).
Very interesting to see all the major electronics companies coming out with their own accelerator kits. Their goal is to a) make experimentation easier and b) help the speed to transformation from experiment to production ready. ARM’s mbed is another super cool example of this and Intel keeps teasing about their IoT developer kit.
For me, it’s also interesting to think about how these stand up to boards like the Arduino. Here’s the thing. The Arduino is ridiculously great for a lot of prototyping and small runs, but would you use it for thousands or millions of devices? Probably not.