In iteration 4 of my Ideal thermostat interface, we talked about focusing on what the user wants and how my interface fits into this. By “user,” I mean the average user, or 80% of the people who use my interface.
But what about the other 20%? These are called “edge cases,” and force the designer to think about a step farther beyond the basic functions of their interface.
We were introduced to this in class after testing our fourth interface—we must now produce an interface that does all of the things below, and then two more. Just in case you’ve forgotten, they are:
1. Turn the system off and on.
2. Turn the heat/cool off and on.
4. Turn the fan off and on.
5. Adjust the temperature.
6. Have a scheduling interface that allows users to add a time, delete a time, or interrupt the schedule.
and two more in this iteration:
7. Allow the user to connect to a wireless network (to pull the date and time for the scheduler) and
8. Make it so that when a user turns on the cooling in cold weather, the system prevents them from doing so (if they were to do so, the system might break due to the way that it’s constructed).
So, what’s changed?
At this stage, the interface is being tweaked, but the heat and cool underwent another iteration. In iteration 4, in order to turn the heat and cool on, the user must adjust the temperature three degrees:
In this new iteration, the temperature is toggle-able and very clearly visible on the screen. See the full PDF of the wireframes here.
Notice that when the heat/cool is triggered, an “Off” switch slides up to allow the user to return the state to off. This allows the user to have no hidden functions and to make sure that they have enough feedback to know what state is activated when. The thermostat will also let you know when you’re about to make a huge mistake and alleviate being too hot in cold weather with a fan…
Setting up the Internet
How does the system know whether or not it is a “mistake” to turn on the cooling? By having the time and date stored. Previously, we haven’t had to make much use of the date, since we only have a “daily schedule” that runs every day without fail.
I started building out an interface for connecting to the internet, being careful to only display information when it’s needed…
Notice that if users don’t see their network, they can manually enter it via a touch screen keyboard. We don’t want a loop of frustration where the user doesn’t see their network and because the thermostat didn’t recognize it immediately, they cannot have wireless functionality. Also, if the wireless has a WEP key, the next screen allows them to enter it via touch screen. When the user exits the “set up wizard,” they are pointed towards the wireless icon should they need to access the settings again.
Additionally, if the time and date is not set up, and the user taps to cancel…
…the system is insistent on at least getting the time and date from them. This prevents (most) users from not setting up the time and date on their system and as such, not benefitting from the system knowing when it is a good time to turn on the cooling.
So, edge cases have been thoroughly addressed. Though the heat/cool interaction has been a constant revision, I feel like I’m on to something. All that’s left to do is to…
So what about your user testing?
In our user testing, we discovered a few interesting things about the interface—
1) Users appreciated being able to turn the heat/cool on by tapping the temperature a few times up or down (but only when the heat and/or the cool was engaged).
2) There was a general concern of “fat fingering” the schedule bubbles to add a schedule—not so with editing a schedule. It looks like there should be some edits on how a user adds a schedule as well as general markings on how to drag the interface to go down the timeline.
3) A user asked me, “So, what happens if I don’t want to keep a stable temperature? I just want to turn the system off?” and honestly, I didn’t have an answer for them. I think this is something that has been previously missing in the schedule that needs to be added—the ability to turn the system off.
As I’ve looked back on all the other iterations, I’ve realized that I’ve had to change the design of the interface less and less all while thinking more and more about different states of the thermostat and how the user interacts with micro interactions, or the details.
No Comments »
Ideal Thermostat Interface by Chelsea Hostetter is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.