Recently I have been asked a lot, mostly in tech events and panels, about the design process behind the hardware development at iomando. Some people are curious about this because our approach to mobile access technology is way different than our competitors.
I have been giving a lot of thought to that and I realized that this is a pretty illustrative story of how designing a product in a constrained environment can also lead to a great output. So I decided to recap some of the challenges we encountered during the design process of building our hardware.
If you don’t know about iomando I encourage you to read the iomando series, a series of articles that I've put together in order to recap the story of iomando. But for those who don’t have the time, long story short, iomando is a mobile platform to manage accesses in all kind of places; is like a key, but from your smartphone.
If I was to draw a quick sketch of our platform, I’d represent three main components that keep everything up and running.
- The mobile app: this is what our users download in order to open the door. A nice interface shows them the doors available, the time frame where they have permissions and a big button to open or close the doors. It's like the key, but instead of being physical, it lives inside your smartphone as an app.
- The server side: here is where the magic happens. The server controls the permissions and updates all the data in real time. So if you were to cancel your permission to your house because your phone has been stolen, the server could do that, in real time. You just log in into your panel and delete the permission.
- The electronic device: this is the piece of hardware we install next to the door in order to open it with our smartphones. Smartphones can do a lot of things, but talking to doors right out of the box is not one of them, so think of this device as a translator between door and smartphone.
Talking to the door
That being said, for the sake of the argument lets focus on the hardware side of the equation. There are several technologies available that could enable this “translation” and when it comes to pick a technology over another, it is always a trade off.
We designed our first commercial prototype back in 2011. To understand our design process we need to have in mind two things: 1) some technologies that today sound ubiquitous, they were not back then, and 2) when we crafted our firsts designs we didn’t fully understood the potential outcome of the business model.
The moment we faced the blank canvas we had four candidates on the table: GSM, Wi-Fi, Bluetooth (not 4.0) and NFC. We prototyped and tried out all the technologies. We spent a lot of time with each of them. Then we analyzed how the business model we had back then could fit in there. And finally, we went with GSM. Now I tell you why.
Reason #1 - Compatibility
Let’s start with an easy one. Back in 2012 a lot people saw the introduction of NFC as a major disruption when it came to interact with the real world (wrong!). Of course NFC could be a great way to check-in with iomando, but it presented three issues that left it out from the beginning:
- Compatibility: in 2012 only Android was officially supporting NFC. Since the 39% of our user base runs on iPhone, leaving more than one third of our clients out of the service might not be a good idea. (Update from late 2014: the iPhone 6 sported an NFC chip, but it was only for Apple to use, so no API, no developers, yet. Still bad news for NFC.)
- Access with cars: despite we now install in all kind of places, iomando started its operations only in communal parkings. By definition you accessed there inside a car. In this kind of environment one can easily see how NFC forces you to reach some element that is installed outside the car. It sounded like something we wanted to avoid.
- Additional equipment: here it comes the definitive deal breaker. Even though the experience of waving something outside the car was crappy, the idea of having to equip each parking with a clunky reader implied more costs and a difficult installation. It could not be even mentioned.
GSM seemed like a good idea, basically because it was rooted in the nature of all smartphones. Sending and receiving packages over TCP/IP is the thing they do best. Moreover, if we talk about compatibility, GSM is compatible with all devices out of the box, without the need of explicitly turning on some additional of connection. Believe it or not there’re a lot of people that turn off Wi-Fi and Bluetooth because “it drains my battery”. GSM was working out of the box for everyone, no questions asked.
Reason #2 - Installation
As the lines above mentioned, our product needs to be installed by a professional. I don’t know if you are familiar with the logic board that controls your garage door, but if you are not, you definitely want a professional to touch the wires in there.
For this reason, there’s an obvious disconnection between the selling of the service, which (sometimes) do ourselves, and the installation in the field, which is done by an authorized installer of our network. Therefore, beyond having a great product for the end user, we also want a great product for the installer. After all he is our user, too.
In other words: we need a product that is easy to install and works in (almost) any environment without any external dependencies.
That leaves out the Wi-Fi version of it (at least running in infrastructure mode), because most of the time there’s not a reliable Wi-Fi connection available to feed the device. The versatility of our product (we can install in places ranging from small houses to big corporate buildings and public facilities) leads to two problems:
- Sometimes you just don’t have a network available in the middle of the street or in an industrial environment. Most of the places where we install don’t have it.
- Occasionally you might have a network in range, in a community for example. But in a shared property like that, the neighbors don’t want to share their network for the sake of the service. You can’t count on that.
And if that was not enough, this also raises two more questions.
- When you actually have a connection and there’s the will to use it, in a private house for example, there’s no easy way for the installer (who might know nothing about routing) to properly set the DCHP or configure the system to point to a particular IP. It makes the installation process way more difficult.
- And the most important, reliability. How can I possibly grant the QoS if the connection doesn’t depend on us? If iomando is providing the service, the fewer intermediate dependencies that it can’t control, the better. So a Wi-Fi from someone we don’t actually know, sounds like a bad idea.
Here the GSM seems a no brainer to us. The installer just need to plug the device to a source of power and then connect it to the door. Is that easy. The GSM connection automatically registers the device to our platform and assigns it to the administrator. The only thing the admin has to do is log in to our online panel and start granting permissions to the end users. Is the frictionless process we could came up with. And believe me, we put a lot of thought into it.
Reason #3 - Pairing and Open
From the installer perspective a GSM enabled module made a lot of sense, but it also had to appeal to the end user. From the end user perspective the installation and set up of the product had to be as easy as possible.
Here is where the concept of pairing comes into play. Pairing a phone with another device has always been (at least before the introduction of Wi-Fi Direct and BT 4.0) a painful experience. We built some prototypes with Bluetooth and Wi-Fi, and we also tried some of our competitors products, but it was a nightmare when it came to pair the device with the smartphone.
That made us think deeply in the problem we were trying to solve and the interaction that made it possible. Open the door with a smartphone is not a long-term procedure: you pull your mobile off, launch the app and push open. Old keys and remotes are not great products, but they are fast as hell. If we wanted to appeal to our customers we needed to, at least, match that speed.
Bluetooth technologies are great for long term relations, like a headset for streaming music, where the main experience is way longer than the pairing. But in our case, the procedure was quite the opposite. You wanted the pairing to be fast, almost non-existing, because the shorter it was the whole experience the better.
That was not possible with Bluetooth. Every time you wanted to access you had to wait for the device to pair, even in some places where the entry point was far from the device, there were problems with the range of the network… It was not a great solution for the kind of experience we were working on.
Moreover, imagine the first time pairing, the on boarding process. Let's picture a public facility where thousands of people have access (we've got plenty of that). The people had to go next to the device in order to pair their phone, as some kind of pilgrimage or something. Bluetooth doesn’t scale well beyond a reduced particular use.
We went with GSM because There are two main advantages when using this technology in order to pair and open the door.
- One is that the pairing is done at the server side, there’s never a direct communication between the smartphone and the device. That allow us to manage and push the permissions at scale and in real time. Users don’t have to pair anything because is the server that grants the permissions in a transparent and automatic process for the user. The moment the app is downloaded, the user already has a button to open the door if the admin has already granted permission, with no action required on his side.
- The second is that opening the door is way faster, between one and two seconds after the button is pushed. Since the connection is a TCP/IP request to the device, the time it takes to open the door is no longer than sending a WhatsApp to your colleague, at the end of the day, we use a similar protocol. Again, the best things mobile phones do is transmit data packages over cellular connections, so leverage that to build our platform was a great idea.
Reason #4 - Security
This one is tricky, because it is difficult to evaluate security in absolute terms. You can say one thing is more secure than other, but “how secure is it?” might not have a direct and easy answer.
One of the great weaknesses of old systems, like remote controls, is that they could be locally hacked. That means if you could iterate the codes within the emission frequency it is really easy to break in.
That is because there is a local element you can interact with, so finding a security breach becomes a matter of time. But with the GSM connection we removed the direct connection between smartphone and device, because all the traffic was routed from the server. Of course that arises another kind of security issues, like what happened if you got the server compromised… But that’s something for another post.
Still, more reasons
- Real time: this is one of our costumers most valued features. It lets our users know when the door has been opened (even with systems other than iomando). Real time also fashions itself as a security feature, because permissions are updated instantaneously, so if an administrator has to grant or block access to anybody, changes occur immediately.
- Remote open: as we said before, there’s no direct connection between the smartphone and the device. This unlinks the physical constrain when it comes to open, so one of the indirect benefits is that doors can be opened remotely.
Looking back, using GSM connections in our devices was one of the best decisions we’ve ever made, and it gave us a huge competitive advantage from the product perspective. It allowed us to design an easy installation process and making the on boarding experience frictionless from the user perspective.
 There were more, actually, but those were the four that made more sense. There were products in the market that opened doors with missed calls and things like that. I spend a lot of time looking into them, I studied them and I tried to figure out the competitive advantage that something like that could give to our business model. But our service was standing in the shoulders of giants because of the smartphones, so everything that wasn’t pointing in that direction didn’t make any sense.
 The layer of communication is not running explicitly over GSM protocol in some cases. Cellular might sound like a more accurate descriptor, but for the sake of the argument I'll refer to GSM / GPRS / UMTS / LTE as cellular or GSM indistinctly.
 The data is from November of 2013, but since then it has remained more or less the same.
 The Wi-Fi version could come in three flavors: Access Point, Infrastructure or Ad-Hoc. The Access Point, creates an SSID on its own, that’s great, but we found out that in some places the network could interfere with the one you already had installed. The Infrastructure mode was useful if you already had a Wi-Fi in your place, but that was not the case in communities. And of course, dealing with DHCP was a mess. Finally, the Ad-Hoc connection is great for this kind of application, but the Wi-Fi direct protocol was not mature back then and there was poor support for it.