IDSE201 – Revision 6 of a thermostat
At the start of last class, Matt gave us two new requirements:
1. The device must be able to connect to the wireless network (or have a really good reason why not)
2. You need to prevent the user from breaking the A/C system by turning it on in the winter.
This late breaking shift in requirements is typically called ‘scope creep’ and can ruin an otherwise healthy project. Many times it involves deep changes as flows have to be completely redesigned to accommodate the new features and behaviors.
Much like the now infamous $1000 project, this was met with a mixed reaction. In my case however, I was fairly confident that I would be able to competently address the new requirements.
Expecting the unexpected…
When starting this class, I realized that I had two advantages :
1. I have over 6 years of QA Engineering experience which involved staring at interfaces, breaking flows, and exploring edge cases on a daily basis.
2. I sat in on the start of the Rapid Ideation class last year. I specifically asked about scope creep and how that was handled. Jon’s response last year made me sure that later in the quarter I was going to see a shift in requirements.
The third advantage which I didn’t realize I had was dumb luck. I love many of the concepts behind the Nest thermostat and home automation. As a technologist, I keep up to date with what technologies are being used by professionals and amateurs to make their homes more interactive. The MSP430, Arduino, RaspberryPi, Samsung TecTiles, Electric Imp, and many more technologies are adding connectivity and remote sensors at near-consumer prices. It was natural for me to look to wireless networking as a means of vastly improving home comfort.
In my original concept model, I explicitly thought of the role of a wireless network to allow for not only remote control via a mobile device, but also intelligent climate control via remote sensing and data.
Adding a means of connecting to a network was a necessary thought. In all honesty, I had thought that it would be hardwired since the control wires to the HVAC system would have to be run as well. However, since ‘connection’ existed and was abstract enough, it was easy to switch from hardwire to wireless without too much mental gymnastics.
So how does one manage a wireless connection?
Thankfully my system control flow had room for a one-line addition of ‘Connect to Wifi’ which would facilitate this small wizard. A list of available networks, sorted by signal strength, is presented to the user.
Expecting the unexpected of the unexpected…
What do you do when your wireless network is hidden or otherwise not listed? Time for some input.
So while the keyboard isn’t super pretty, it is functional. It allows for all manner of input except for non-English language sets. However, the real thought goes into answering the question, “How many ways can this go wrong?”
Here are a few examples:
Some alternative cases worth pondering are if there are multiple networks with the same name, if there are multiple wall units in the same home, and how does the system handle brownouts or temporary power outages?
Having a dialog with the user
Sometimes you have to talk the user down from the ledge and help prevent them from doing harm to themselves. In this particular instance, if the user were to turn on the A/C in cold weather, it would break the unit.
While this is very language-centric, there are few cues which drive home the point. By adding a notification at the top of the interface, the user can see this is an unusual condition. The red X makes it clear that what just happened is a no-no. Finally, the removal of color, my indicator of whether heating or cooling is occurring, makes it clear that the system is doing neither.
Overall this was a fun set of challenges. I wish I had more time to clean things up before today’s post, but rest assured everything will be addressed before the final presentation.