I’m Anu! I research, make, craft, code, and sometimes, hack things.
Living with a Smart Plug 🛋
This is a case study of a smart plug and my experiences of living with it for roughly 8 months. In this study, I will briefly describe the device, its features and functionality before elucidating the qualities that I find are striking in the adoption of a smart device.
Features and Functionality of the D-Link W215
The Smart Plug is probably the most undemanding of all IoT products available in the market today. The idea is simple – it is a device that allows you to remotely control your appliances, especially when you are not physically near it. Its functionality is tied to a handy mobile-app with a simple toggle button interface, one for each smart device (from the same manufacturer, see fig 1). Further, its installation is easy because it either connects to an existing Wi-Fi connection or a Smart Hub.
Figure 1: D-Link W215 Smart Plug and Mobile App
The one I have is the D-Link W215 WiFi Smart Plug that works with a free mobile-app called ‘mydlink home.’ One of more common features among all Smart Plugs available today is its scheduling feature that lets a person schedule when s/he wants the appliance turned on/off everyday. This feature particularly caters to the larger speak of ‘home automation,’ which builds on values like comfort, convenience and even sustainability. In the case of sustainability, a person has the option to turn off a device when it is not in use in order to save energy (a.k.a phantom load). In that, the mobile-app also offers an additional feature to monitor the device’s energy statistics in use. Further, the D-Link Smart Plug channel is also available on IFTTT (If This Then That), which offers a wide range of possibilities for what one can do with the device.
Using the Smart Plug: D-Link + IFTTT
IFTTT greatly boosts the Smart Plug’s functionality. Not only can you turn an appliance on or off at your own accord, but also do it automatically when you receive a phone notification or you can also couple your morning alarm to the coffee machine via IFTTT and the Smart Plug. Confronted with an endless list of possibilities, I decided to program my device with a simple recipe that switches my night lamp on when it gets dark in the evening and switches it off when there’s daylight (see fig 2a, 2b). At the outset, it worked so well that it seemed almost banal and uninteresting. Having used it for a considerable period, I find that there are certain qualities within IoT-based automation that are worthy of discussion.
Figure 2: My Night Lamp with the D-Link Smart Plug and IFTTT connected to D-Link Smart Plug
Qualities of Interaction
1. Affective Presence
Personally, I always need a bit of light when I go to bed everyday and the device did just that and more. In some anthropomorphic sense, this night lamp kept me safe in the dark, without having to make the effort everyday. My night lamp was not like any other lamp but something that had taken presence in my life, beyond the obvious light it produces. Further, it changed the way I think and go about my sleeping routine. The notion of presence supported by the smart plug as therefore not just physical but also affective. While there was nothing novel about what it was doing, my relationship to the night lamp had grown manifold.
2. Ambiguity within Reason
As winter arrived, darkness hit early and my night lamp turned on everyday while I was still at work. So I set the device to a fixed schedule instead i.e. turn on at 9pm and turn off at 7am. Whenever my lamp turned on, it reminded me that I had programmed it to do so. It behaved exactly like an alarm clock. I realised that programming the device to a fixed schedule didn’t quite retain my interest in the device or the lamp. The difference here is that the device reacted to a schedule, whereas in the case of IFTTT the device reacted to daylight instead. In the latter case, the lamp portrayed autonomy such that it left space for ambiguity within reason. Sometimes I would open my curtains to crosscheck if there was daylight or darkness in sync with the lamp. However, with the arrival of summer, I switched back to the IFTTT recipe.
3. Manageable Tensions
I went on a six-week vacation in the summer, which meant that I had to turn off my IFTTT recipe. Instead of turning off the recipe, I simply unplugged the smart plug from its outlet because I was afraid that I would have to reset the recipe all over again. IFTTT is a third-party application and my recipe was being triggered from the IFTTT servers through the D-Link channel. Due to such a complex process, I let the recipe run during the summer, even though the lamp was turned off. Beyond any logical reason, I felt a sense of calm running the recipe while I was away but I was also guilty of my own conviction. As control gets further away from our hands, both in the form of intelligence in the device and the involvement of multi-party stakeholders, tensions will arise that we will attempt to manage by playing out our ethical and moral sensibilities. This becomes even more crucial when we begin to articulate the maintenance and repair of our IoT devices.
4. Emergence of new practices
In both cases of using the scheduling feature and the IFTTT recipe, my interaction with the Smart Plug had come down to programming it just once using the interface on the mobile-app and never engaging with it again (unless something went wrong). Therefore, the real interaction was in the experience that came later with the lamp (when the schedule triggered) and not my experience with the Smart Plug itself. For IoT, there is a clear shift in focus from interacting with the device (Smart Plug) to interacting through the device. As such, experiencing existing practices (e.g. turning on a night lamp before going to bed) through IoT and the emergence of new practices should be new focus of designing with IoT.
Final thoughts
The aim of this case study was mainly to contribute to a growing discourse in the research and development of IoT devices. Instead of the stating the obvious, I used my own experiences to elaborate upon the interaction qualities that reveal interesting gaps and potentials in the use of an IoT device. As it is evident, this case study is written from the position of an interaction designer, which I realise can be limiting. Therefore, I take an active part with other professionals to discuss these gaps and potentials, which can be mutually beneficial for everyone involved in the field.
This text was written for Mapping the IoT workshop conducted at Nordic CHI 2016 by Vitali et al. 2016, Politecnico di Milano, Italy
Reference: Ilaria Vitali, Valentina Rognoli, and Venanzio Arquilla. 2016. Mapping the IoT: Co-design, Test and Refine a Design Framework for IoT Products. In Proceedings of the 9th Nordic Conference on Human-Computer Interaction (NordiCHI '16). ACM, New York, NY, USA, Article 142, 3 pages. DOI: https://doi.org/10.1145/2971485.2987681