5 ms·

How to design for the Internet of Things

42 points by danfrost 13y ago

sp332 13y ago
I think the "Unix Philosophy" is way ahead on this one. http://www.faqs.org/docs/artu/ch01s06.html http://www.faqs.org/docs/artu/ch01s06.html Rule of Least Surprise: In interface design, always do the least surprising thing. Rule of Silence: When a program has nothing surprising to say, it should say nothing. Rule of Repair: When you must fail, fail noisily and as soon as possible.
- dllthomas 13y ago
  You can minimize surprise by always immediately crashing. There will be a slight learning curve, but rather quickly a user will never be surprised by your UI again.
  - austinhutch 13y ago
    This is interesting, can you elaborate or provide and example? Thanks!
    - dllthomas 13y ago
      It was meant to be amusing, not interesting... The idea is if the only thing your program does is crash, users will expect it to crash, and so it will never do anything unexpected (or useful) like "not crash".
      - austinhutch 13y ago
        That totally went over my head! I was thinking you might have had a philosophy that forces users up a steep learning curve more quickly, whoops!
        dllthomas 13y ago
        For myself, I find the best way to have a shallow learning curve for me is to define the interface as I go (building out keybindings in ratpoison as I want them, &c). Leaves it pretty impenetrable to others, though. I think that last bit is more bug than feature.
- dclara 13y ago
  Interesting rules. I can feel they are right. But if all the UIs are not surprising, people will be pretty bored and hard to remember to come back. This is a dilemma for my website UI design.
jmpe 13y ago
Have a bit of experience in this field, on a technical side: - Always provide a way to auto update and fallback if failed. - never implement a buzzer or beeper. - stay away from blue status leds. people really dislike them, especially in the bedroom. - always design with sleep/low power mode functionality. If it's embedded uC: 1 watt is more than enough, even with RF. Pick bistable relays. If it's a Linux SoC aim for less than 3W. If there's wifi keep it under 21 dBm. Pick sps modules like 78SRxx from murata instead of linear 78xx. - if it's a thing you plug in the wall socket make sure it doesn't obstruct other sockets. - expect people to unplug it every moment every day. - don't force people to provide an email to activate some functionality or feature. - use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process.
- angersock 13y ago
  use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process. This, a thousand times this. Because I don't want to have problems if/when your company goes under in a couple of years.
  - dllthomas 13y ago
    Or gets bought, changes focus, ...
  - jmpe 13y ago
    The main motivation on my behalf is that it allows us to create synergy with sensors. Company A sells door/window contact stuff. Company B sells indoor presence detectors. Company C sells plugs to dim/switch/measure appliances. If they make their communication stack transparent anyone can jump in and combine these products to improve comfort (e.g. appropriately dimmed lights as you walk through the house), reduce the energy bill ("you're running the airco with the window open" or kill lights in unoccupied rooms) or add a level of security ("no presence inside, no appliances on but the window just opened..."). Without it you're limited to the island solutions provided by the service.
- zwieback 13y ago
lowglow 13y ago
I just heard a talk with Sproutling's CEO Chris Bruce. He really recommended reading this book: http://www.amazon.com/From-Concept-Consumer-Ideas-Money/dp/0137137478 http://www.amazon.com/From-Concept-Consumer-Ideas-Money/dp/0... You should also attend the SF Hardware Startup meetup, run by my friend Nick Pinkston (great guy): http://www.meetup.com/HardwareStartupSF/ http://www.meetup.com/HardwareStartupSF/ You should also come and join us at the Hackendo::Integrate conference in April: http://hackendo.techendo.co/ http://hackendo.techendo.co/
dclara 13y ago
Very good solution outlook. The main concern I have is: "Design for scale of everything", given the example of 200 bulbs. That's exaggerated, but how about you have 200 of IoT at home? Do you use 200 or 100 apps to control them? This is the problem of Nest which has the architecture of producing one thing after another controlled by smart phones. This architecture does not scale.
- davidnagy 13y ago
  Would you think that a "platform" do unify all this smart devices - makes sense?
  - dclara 13y ago
    Yes, I think so. It's under development. Other than that, if we build each smart device like Nest's, the cost is not acceptable when we are going to have 100 at home, all of which cost > $100 and have so many different apps to control each of them. The current trend in the public is: making each device HTTP-enabled so that they can talk directly to the web server in the cloud, which in turn to talk to the mobile devices or controller, and vise versa. I see a pretty good implementation here: http://ronguest.com/blog/2013/10/how-to-run-temboo-from-openwrtlinino-on-arduino-yun/ http://ronguest.com/blog/2013/10/how-to-run-temboo-from-open... This is a solution that minimize the cost for realizing the IoT available so far. But it still does not scale. The design requires to upload a Python SDK to the memory of the second chip and requires SSL for security. SSL is slow in terms of the performance of a device response. It's redundant. Wi-Fi itself is very secure if the message can be transported on a lower level. Alternative solutions could be: unify all the smart devices at home using home computer as a central control which will send messages back and forth to the smart phone or remote control. Between the central controlling program and the devices, some type of communication either on the HTTP level or lower level will help. It's not necessary to bring everything onto the Internet, only the web server on the home computer is exposed, which is a lot more secure. This way, your smart phone only need to have one app to control all the smart devices at home. More aggressive solution is to control the smart devices on a lower level than HTTP from the cloud, so that the cost of building the smart devices can be reduced significantly, keeping the device price minimum change from the traditional devices. That's in the future.

42 points by danfrost 13y ago

sp332 13y ago

I think the "Unix Philosophy" is way ahead on this one. http://www.faqs.org/docs/artu/ch01s06.html http://www.faqs.org/docs/artu/ch01s06.html Rule of Least Surprise: In interface design, always do the least surprising thing. Rule of Silence: When a program has nothing surprising to say, it should say nothing. Rule of Repair: When you must fail, fail noisily and as soon as possible.

dllthomas 13y ago
You can minimize surprise by always immediately crashing. There will be a slight learning curve, but rather quickly a user will never be surprised by your UI again.
- austinhutch 13y ago
  This is interesting, can you elaborate or provide and example? Thanks!
  - dllthomas 13y ago
    It was meant to be amusing, not interesting... The idea is if the only thing your program does is crash, users will expect it to crash, and so it will never do anything unexpected (or useful) like "not crash".
    - austinhutch 13y ago
      That totally went over my head! I was thinking you might have had a philosophy that forces users up a steep learning curve more quickly, whoops!
      - dllthomas 13y ago
        For myself, I find the best way to have a shallow learning curve for me is to define the interface as I go (building out keybindings in ratpoison as I want them, &c). Leaves it pretty impenetrable to others, though. I think that last bit is more bug than feature.
dclara 13y ago
Interesting rules. I can feel they are right. But if all the UIs are not surprising, people will be pretty bored and hard to remember to come back. This is a dilemma for my website UI design.

jmpe 13y ago

Have a bit of experience in this field, on a technical side: - Always provide a way to auto update and fallback if failed. - never implement a buzzer or beeper. - stay away from blue status leds. people really dislike them, especially in the bedroom. - always design with sleep/low power mode functionality. If it's embedded uC: 1 watt is more than enough, even with RF. Pick bistable relays. If it's a Linux SoC aim for less than 3W. If there's wifi keep it under 21 dBm. Pick sps modules like 78SRxx from murata instead of linear 78xx. - if it's a thing you plug in the wall socket make sure it doesn't obstruct other sockets. - expect people to unplug it every moment every day. - don't force people to provide an email to activate some functionality or feature. - use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process.

angersock 13y ago
use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process. This, a thousand times this. Because I don't want to have problems if/when your company goes under in a couple of years.
- dllthomas 13y ago
  Or gets bought, changes focus, ...
- jmpe 13y ago
  The main motivation on my behalf is that it allows us to create synergy with sensors. Company A sells door/window contact stuff. Company B sells indoor presence detectors. Company C sells plugs to dim/switch/measure appliances. If they make their communication stack transparent anyone can jump in and combine these products to improve comfort (e.g. appropriately dimmed lights as you walk through the house), reduce the energy bill ("you're running the airco with the window open" or kill lights in unoccupied rooms) or add a level of security ("no presence inside, no appliances on but the window just opened..."). Without it you're limited to the island solutions provided by the service.
zwieback 13y ago

lowglow 13y ago

I just heard a talk with Sproutling's CEO Chris Bruce. He really recommended reading this book: http://www.amazon.com/From-Concept-Consumer-Ideas-Money/dp/0137137478 http://www.amazon.com/From-Concept-Consumer-Ideas-Money/dp/0... You should also attend the SF Hardware Startup meetup, run by my friend Nick Pinkston (great guy): http://www.meetup.com/HardwareStartupSF/ http://www.meetup.com/HardwareStartupSF/ You should also come and join us at the Hackendo::Integrate conference in April: http://hackendo.techendo.co/ http://hackendo.techendo.co/

dclara 13y ago

Very good solution outlook. The main concern I have is: "Design for scale of everything", given the example of 200 bulbs. That's exaggerated, but how about you have 200 of IoT at home? Do you use 200 or 100 apps to control them? This is the problem of Nest which has the architecture of producing one thing after another controlled by smart phones. This architecture does not scale.

davidnagy 13y ago
Would you think that a "platform" do unify all this smart devices - makes sense?
- dclara 13y ago
  Yes, I think so. It's under development. Other than that, if we build each smart device like Nest's, the cost is not acceptable when we are going to have 100 at home, all of which cost > $100 and have so many different apps to control each of them. The current trend in the public is: making each device HTTP-enabled so that they can talk directly to the web server in the cloud, which in turn to talk to the mobile devices or controller, and vise versa. I see a pretty good implementation here: http://ronguest.com/blog/2013/10/how-to-run-temboo-from-openwrtlinino-on-arduino-yun/ http://ronguest.com/blog/2013/10/how-to-run-temboo-from-open... This is a solution that minimize the cost for realizing the IoT available so far. But it still does not scale. The design requires to upload a Python SDK to the memory of the second chip and requires SSL for security. SSL is slow in terms of the performance of a device response. It's redundant. Wi-Fi itself is very secure if the message can be transported on a lower level. Alternative solutions could be: unify all the smart devices at home using home computer as a central control which will send messages back and forth to the smart phone or remote control. Between the central controlling program and the devices, some type of communication either on the HTTP level or lower level will help. It's not necessary to bring everything onto the Internet, only the web server on the home computer is exposed, which is a lot more secure. This way, your smart phone only need to have one app to control all the smart devices at home. More aggressive solution is to control the smart devices on a lower level than HTTP from the cloud, so that the cost of building the smart devices can be reduced significantly, keeping the device price minimum change from the traditional devices. That's in the future.