It seems to me that if there is going to be a hardware widget mounted on the wall for the sole purpose of humans fiddling with it, then it ought to be engineered and optimized from that perspective first (UX: user experience)…
It seems to me that if there is going to be a hardware widget mounted on the wall for the sole purpose of humans fiddling with it, then it ought to be engineered and optimized from that perspective first (UX: user experience)…
My thermostat lets you override the schedule to raise or lower the temperature any time. It reverts back to the regular schedule 8 hours later.
The override is just a simple matter of pressing up or down on the temperature scale arrows.
That sounds great, but maybe I’m just not understanding what the problem or contraction is. In my mind the very same could be applied to this interface (both the invisible schedule and timeout/realignment).
I’m just saying that configuring that level of complexity is best left to a different interface (computer or mobile), especially for something like a schedule where it might need to be saved more permanently or managed in-mass for many thermostats and brings in other concerns not relevant to such a limited interface (like the current date/time/season, identity or historic preference of the occupant, etc).
There is an infinite number of ways one might want to “program” a thermostat, and an unlimited number of ways to include it as part of a larger comfort system (both as an input [like noting if/when the occupant wants in warmer/colder] and endpoint [like resetting it in a hotel when the occupant leaves])… but for a good FINITE interface we need to not overwhelm the user while still giving them all the control they need with no training or documentation required.
I guess I just don’t trust thermostat makers to be able to develop a competent mobile app. If one did manage to develop a really good mobile app then I’d be excited to use that. I don’t see it happening.
Perhaps one of the biggest issues is that thermostats are typically made by HVAC type companies who don’t have an established culture of developing quality software. Their management may see software only as a necessary evil, not a product differentiator.
This may have been further exacerbated by the HVAC installation and repair industry which has a lot of issues of its own (licensing, conflict of interest, and bundling).
Totally get it. I’m often frustrated by this kind of “good hardware bad software” experience, and kinda hate the “install our crappy app” push. What I would like to see is companies doing what they do best (in this case, a thermostat builder making a good thermostat), and leaving the rest of it (like mobile/web/control apps) to those who do it better. What we see in practice though is that business don’t want to create an ‘interface’ for interoperability (for fear that they may be replaced), but instead want to “control everything” end to end, which is why we see proprietary thermostat-to-air-handler protocols, and even encryption between garage door openers and the BUTTON on the wall to open your own garage door.
Yeah exactly. Open standards are what we want but they’re just so hard to get without regulation. Sometimes we see industries that are smart enough to form their own standards body when they realize it’s in all their best interests to standardize. Other industries seem to never realize that.