Hi, SparkFun people!
I'm Pavel, creator of Blynk. My background is more in user experience and visual design, so this post is slightly different from what you usually see here. Since I’m a new guy here, let me tell you a bit about myself.
I’ve been designing web, mobile, and car interfaces for the past 10 years. I am obsessed with how everyday routines can be optimized, and how familiar things around us can be made better.
About three years ago, I came across Arduino and was amazed by how easy it was to convert some of my crazy ideas into prototypes with buttons, knobs, LEDs and so on. I never thought of myself as an engineer, but it seems that genes have a mind of their own. (My grandmother designed electric circuits and dashboard interfaces for USSR secret military projects, and my grandfather was a scientist, seriously tinkering with lasers for war airships during the Cold War.) Very quickly, I realized that things can talk to one another through the internet, opening so many possibilities.
The Internet of Things is definitely happening, but it is still young, and many aspects of it have yet to be explored. We makers are definitely on the front edge, shaping the industry of tomorrow and building the connected products of the future. The most awesome thing is that, with all the readily available information and components - and an amazing maker community - you can build almost anything at home. However, when technology is “solved,” another important aspect comes into play: user experience.
IoT reminds me of the early days of the internet, which was built by a group of developers...and used by other developers. It was focused primarily on technology; no one thought about how people will use it. Technology comes first, and as it evolves and more people adopt it, the focus shifts toward design and UX while technology becomes invisible.
Next time you are making something cool (using the SparkFun Blynk Board, of course) try to think about how someone else, like perhaps your parents or non-tech-savvy friends, would use it. My advice is mostly software-related, but creative solutions might come from the engineering side.
1. Functionality can be distributed across devices and interactions.
You can set a smart thermostat with a hand, then someone can use a smartphone app to adjust it, and then a rule can trigger it to switch to a night mode.
2. Cloud services can be unavailable.
If the server is performing most of the functions, when there is no internet connection the device can obviously become inaccessible. Now imagine an internet door lock – if your lock is connected to the cloud and it goes offline, you are locked out or in. You get the idea.
3. Requests may take time.
It’s OK for an Instagram feed to show a spinning wheel, but latency can become a very frustrating experience when interacting with real objects.
4. Not everything is actually in sync.
When a sensor checks the temperature once in 15 minutes, and then the device goes to sleep, it doesn’t represent the current state when you are checking it on a mobile app. It’s a different experience from physical objects.
5. Consider interoperability.
It’s more a question of standards, but since there is no single protocol yet (another similarity with pre HTTP-era internet), you should consider how your product will talk to other things and services.
There is, of course, much more to consider, and if you are interested in the subject I would recommend looking at:
User Experience Design for the Internet of Things, which might become outdated very soon.
Ten basic rules for user interface design, by Jakob Nielsen. They were written years ago but are still very relevant.
I also believe every maker should learn general UX design principles.
I’m convinced that for the Internet of Things' evolution, user experience will become the most important factor. With all the forecasts for billions of devices online, people will need to interact with them. They will need to operate and configure them, and create rules for how they will talk to one another, etc.
I do hope your ideas will turn into some fantastic things used by millions of people around world. Maybe you will design a new, smarter thermostat or (please no!) a better SmartPipe.
Hi Pavel Blynk rocks! Ive used it on several proyects and it is so easy. Thank you for taking the time to get it going and making it user firendly. The first time I used the esp thing it was not exactly simple..Blynk let me focus on my proyect and not so much on the software side. thanks again
Thank you for kind words! Glad you like Blynk. There is still a lot of room for improvement, but we really work hard on the best UX.
ESP8266 can be tricky, for sure :) I hear you. I'm glad SparkFun took all the hassles out of it and made it much more accessible.
IOT is exactly a network of physical objects with network connectivity. The tips mentioned here surely are good as a Computer science engineer I have designed a project based on IOT but I didn’t go through this blog before and face lots of issue. http://www.printwiz.com.au/
It's strange that nobody commented on SmartPipe :) I thought that it's as crazy as it could be
Hi Pavel, I've read about the app, seen the screen shots and it looks awesome.
I however belong to the PIC crowd, and I was wondering where can I get the information required to code, for PIC, an interface to the App.
Is there API information available? ... or enough info for me to develop my own microcontroller code (for sharing obviously).
Thank you!
I'm not that familiar with PICs, but Blynk engineers might be. I've asked them already, but you can also do that on our forum: http://community.blynk.cc , or shoot and email to hello@blynk.cc
rephrase: Where can I see the information necessary to make my own interface on the micro controller side. There is no "unified" compiler/environment for PICs so, coding our own Micro code would be much simpler. You would think using Microchip Compilers would be the solution but frankly, the tool chain sucks.
According to Blynk's community, they seem to believe PICs are few and far between. I don't expect Blynk code for PICs any time soon.
Quote: "while it is used for production, PIC is currently not very widespread among makers".
Thank you for point #2. "Cloud services can be unavailable."
I don't know how many projects that I've seen that seem to expect the internet to actually be there at all times. (Shawn's breatholator tie for instance.) I'd like to see an easy to implement (and later analyze/plot/sort/etc.) method for phant (and other IoT services) for a date/time stamp to be associated to a data point from when the device took the reading, not when the cloud service received the data point. Most of them seem to take a single piece of data and assign the date/time when the server received that data point.
Yup! I actually had issues with WiFi when we were shooting the breathalyzer project. I think there's a way to have the Photon run without WiFi, but that's not its default behavior. For a real implementation on a project like that, I would want the microcontroller/SBC to collect data, store it to some kind of nonvolatile memory (e.g. SD card), and then only post to a site once it knows it has a solid Internet connection.
[Edit] As an answer to your final point, you can create a separate field for a timestamp so you know the real collection time (and not post time). This requires a connection for NTP or access to an RTC. I did the NTP method with this tutorial.
For those curious: You can adjust the Particle board's desire to use WiFi using the SYSTEM_MODE() function.
Details here: https://docs.particle.io/reference/firmware/electron/#system-modes
Thanx. I'll look at that tutorial.
Ok. Egg on my face. I guess I hadn't looked hard enough at multiple examples. The one or two examples that I saw were just pushing a single field per record so I didn't realize that phant supports multiple fields per record.
Yes, exactly. I think that soon it will be less of a problem, but still, there should be always a "backdoor". Depending on the application or the product, connectivity design should be very well thought through. Most of the user frustrations come from system failures, so all the errors should be handled.