DIY Smart Homes

Back in Fall of 2016, we were asked to attend an on-campus seminar as a part of a course and write a brief report about it. The day I chose to explore on-campus seminars fortunately coincided with the Aware Home Seminar, which was atypically being held in the Home itself. Not knowing what to expect, I walked in and discovered the place that would fascinate me for the rest of my Georgia Tech days.

This 'Living Laboratory' for ubiquitous computing research was founded by Dr. Abowd and several others at the GVU center in 1999, for studying everyday activities and how technology can support and supplement humans living in such an environment. Over the years, it has grown to support many academic and industrial projects, accumulating many sensors, actuators and smart home equipment bought, donated and built for the Aware Home.

After stumbling across this wonderful place, I decided to get involved with the ongoing projects there. I spent many days exploring the home and its vast collection of functioning and legacy projects, various systems, data streams and so on. In the Spring of 2016, I volunteered to work for credit in the Aware Home, studying and documenting existing systems and identifying opportunities with data collected, as well as helping the lab assistants with creating networked systems. I also collaborated with the Ambient Alerting panel, linking the lights to IFTTT with inputs from sensors fed through a Particle Photon.

Another major accomplishment during the time was creating a Slack Bot for understanding natural language commands sent over Slack and converting it into parsed JSON, enabling further actions. This was my first foray into understanding how smart home systems work, vastly differing from my old project 'Internet Controlled Switchboard' from my undergrad years.

As a kid, you very likely played with Lego®s. Would you buy a completely built model of the Starship Enterprise, when you'd rather get the blocks and build on your own?

My solution would be based on a similar premise. Building a smart home all by yourself would be a creative and rewarding experience, but then, building it should not be so complex that it would deter you from building it in the first place. Obviously, the learning curve for building a smart home is much steeper than the one for learning Lego® blocks, but if the reward was worth it, why wouldn't you?

The 'UX Crossover Point' is the point where a technology is sufficiently mature for designers to treat the problem from the users' perspective and think about designing solutions rather than treat it as a experimental research project. The rise in platforms like the Wink Hub and Samsung SmartThings indicate the readiness of the technology for a design intervention and a focus on the users. The rise of commercial Machine Learning that can run even on embedded systems like the Raspberry Pi, and the ease of use of Machine Learning with frameworks like CoreML and Tensorflow Lite opens up the field to common users on ubiquitous devices, which can form a cluster system with power unimaginable even a few years ago.

Another reason why I believed this would be a successful system was the resounding success of MOOC platforms, inspiring millions around the world wanted to learn new skills, programming included, to get smarter. Therefore, I would not have to limit my design to only experts, or strip it of advanced capabilities to keep it simple.

Finally, my frustration with where UX has been going in the modern world greatly motivated me to build something that did not confine you to a single workflow, instead allowing you to explore creatively and think differently to automate aspects of your own home and beyond. Also, drawing inspiration from early days of computers, the Open Source Movement and DIY platforms like Instructables, and I have been an advocate of open systems, tinker-friendly technology and platforms for sharing knowledge. I believe treating users as co-developers presents advantages that are critically needed for the next wave of computing, with Internet of Things making the biggest splash since the proliferation of personal computing in the 80s and 90s.

There is plenty of literature that exists out there for smart home enthusiasts - everything from novice blogs expressing the frustration of technology, to Youtube videos on how to install smart homes, to research papers that explore ubiquitous computing. Since my project is time and resource constrained, to mitigate the effects of conducting user research on a small sample size, exploring these were critical. Also, such an endeavor helps me understand the key areas I need to solve this problem.

In addition to literature survey, conversations with smart home users, colleagues at the Aware Home and DIY enthusiasts I know from my circles opened up a trove of valuable insights.

Unless you are working on something like a rocket launch interface for a space travel company that you design and very likely never use yourself, I do not believe the adage "you are not the user" applies. Therefore, I am currently exploring first-hand converting my own house into a smart home (Thanks, Jeff!), having added several sensors and systems over the past few months, including studying domestic wiring and tearing up the walls to reconfigure and troubleshoot issues with smart switches and other appliances, which has proved invaluable in giving me a front row account on how hard a problem this is, exactly.

One of the key steps of UCD is to actually talk to users of your system to understand their needs, capabilities and limitations. For this, I chose to do a hybrid approach between an ethnographic study and contextual interview.

After completing the necessary human subject research approvals, I set about finding my target user group - people who did not have smart home experience beyond owning perhaps a Google Home or Amazon Echo (so I could have them install a device and find out exactly how much the effort was), and people who own and/or live in a smart home (so I could learn about their experiences and expectations of a smart home system).

My primary interview questionnaire collected the following data:

• Basic demographics
• Living arrangement and house configuration
• Frequency of use of Smart Home equipment they own
• Experience with the equipment / installation
• Familiarity with and willingness to learn embedded systems (like Arduino), task automation tools (like IFTTT), scripting tools (like Python or BASH), and wireless protocols (like Bluetooth or Z-wave)
• Things they rely on others to do, or wish was taken care of
• Self-evaluation of capability of putting a system together that solves the problem above
• A cognitive walkthrough of the 'rules' they would need to set up the hypothetical system, to see if they would think of all the possibilities and exception cases
• The willingness to build such a system (with or without assistance), and the cost differential that would convince them to buy one over build one
• The kind of assistance they would need
• Potential concerns (for example, security or privacy) they would have in a system they have built/bought

Since this is ongoing research AND this website is publicly accessible, publishing my hypotheses may bias potential test subjects. If you want to know my hypotheses, talk to me!

Obtaining the views of Subject Matter Experts (SMEs) seemed pertinent to my exploration of smart homes - mainly to make sure my eventual set of recommendations would be implementable in practice. After all, a design solution that satisfies all the user needs but can never be built with the technology we currently have is worthless.

I plan to interview experts in the fields of smart homes, embedded platforms, communication systems, wireless protocols, machine learning, distributed systems, cognitive science, computational creativity and other related areas to understand their view on the user needs and my initial ideas at a solution.

After learning the needs of users and gaining a deeper understanding of the field from experts, the next step is to design several low-fidelity solutions that balance the two. These solutions will be prototyped, with the firm knowledge that they are technologically feasible.

Low fidelity prototypes will take the form of paper prototypes, Wizard-of-Oz chatbots, physical prototypes, and so on. The prime objective of this phase is to create enough artifacts to validate my assumptions about my solution and prepare for testing with users, by coming up with a set of key measures that evaluate how effective my prototypes are.

This is the stage in which I think user feedback really matters. As a rule, UX Researchers do not ask users what the solution should look like in the beginning (What work would we have if they all made their own solutions?)

Once I have designed solutions and evaluation metrics, I take a look at how existing solutions (if any) handle the problem, and compare it to my own. Then, I let users evaluate my prototypes, with an intent to understand the extent to which these prototypes fill the gaps in user needs.

The process will differ from a traditional prototype evaluation because it is meant as a DIY solution, which means that the prototypes do come with a learning curve and the users will be modding and tweaking and building on my solution. This means testing with a wider variety of audience, with a baseline expectation that some users may not be able to pick it up as easily as others.

At the conclusion of research, I will publish my results as a set of recommendations and a series of Proof-of-Concepts that will help my users and other organizations to build on the solution.

I may go ahead and start building parts of the system (for fun!) after I graduate - it really is a waste of good research if it just stops at just recommendations.