Well put and I bounce back and forth between Things and Dashboard views for the same reasons you mentioned. Needs to be rationalized.
This is a great reminder as I get desensitized to it at times because the vast majority of my stuff is automated through Hello, Home phrases that automatically trigger without opening the app, controlled via my voice from our forthcoming Gear S app on my wrist, sensing of beacons and NFC tags with my phone, etc. Much goodness that will be available to all before long but doesnât change the point about needed improvements around the basics.
I like the idea of hello home actions, but they donât really fit my household. Someone is always in the house. For me the biggest improvement would be to extend the platform with zones, then allow each zone to have itâs own modes, as well as allowing each user to have their own modes globally. I have tried working with modes as they are, but it quickly got very complicated and that is the opposite of why I am using ST.
The org growth acceleration is recent, and lots of it has gone into next-gen cloud architecture (for reliability and scale), craploads of basic bug fixing, moving Android towards parity and beyond, next gen stuff to be announced next week, etc. The root problem I think has been in our organizational structure. We havenât had a substantial dedicated team for development of the core SmartApps (the ones we publish within Dashboards and Hello, Home which are all built using the same tools available to the entire community), for creation of new device handlers and updates to older ones, and for testing and certification of innovation submitted by the community (which it measured in the many thousands of new apps per month right now). Without a big enough dedicated team on those things, it has been far too easy for even the best intentioned team members to get derailed over and over onto something slightly more pressing at the head of the list.
We are fixing that now (per my comment in my first big reply around dedicated teams model) while also expanding a ton. So I do think it will get a lot better in the coming months as we shift and grow into the new approach. E.g. if we have XX engineers doing nothing but supporting new SmartApp and device handler development, I think our pace would go up a ton as they would never be pulled into anything else.
I also understand that much of the above may sound like the same old story to those in the community who have been patiently waiting and that action is all that matters. But it is the authentic truth.
Weâll get it right soon and have come a long ways. I just hope all you great supporters donât give up on us in the meantime!
If you have the patience and time for it, Iâd love to have an email outlining your specific scenarios just so that I can think it through along with the team. If you do I promise a deep read through and consideration.
Itâs literally coded so that it is tied to a door opening and shutting, so itâs not a bug itâs a feature I completely understand your point on it though, and agree that it should work differently without the requirement for the associated door open/close event.
Yes. Pretty much every home automation platform on the market has concepts of rooms and scenes. These are easy to explain even to a 6-year old. Why SmartThings decided to ignore these fundamental concepts or to come up with a different terminology defies reason. Itâs like building a car with square wheels just to look different.
Home âmodeâ are a good concept, but itâs too limiting for large households with multiple occupants and rooms. I donât want my entire house to go into âMorningâ mode when my daughter wakes up at 5 AM, but the rest of the family is still sleeping. Every zone (room) has to have itâs own mode, in addition to the house (global) mode.
From a UI Perspective it just makes sense. Even @alex has things grouped into zones. It would be even cooler if the those groups were treated as objects that could have rules and smart apps of their own. All things should be objects from a UI standpoint. Location => Zone => Thing.
Agreed. I am most excited to build a product for SmartApp discovery. I want to build a community device wiki that lists every device with every possible capability and which SmartApps work with it.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
111
I strongly feel that Shake is really not an acceptable user interface, imhoâŚ
It is not intuitive, nor is it labelled (i.e., there is no way to know that shake is available to perform the described function⌠the Things screens do not say âShake to view labelsâ). To the best of my experience, I can think of only a handful of apps that use shake anywhere in their user interfaces (one example, perhaps, are music players that use shake to switch to a random track: If this is intuitive, then I would expect shake to cause SmartThings to turn on a random switchâŚ).
Android devices are not required to have shake as a mandatory hardware function. In an extreme case, we can be running the SmartThings app from inside Chrome or via an Android emulator (âAndyâ or âBlueStacksâ). My PC gets a tad upset if I pick it up and shake it (and that wouldnât work anyway, since my PC has no vibration sensor).
The gesture adds a non-trivial step to what should be a single fluid activity: i.e., (a) view the devices, (b) select device. Instead it is (a) view the devices, (b) canât figure out which device is which, (c) shake until labels appear, (d) try to remember all the labels because they disappear after a few moments, (e) trust your memory, faith, and select a device.
Shake is not accessibility (ADA) compliant. Does iOS, Android, and Windows provide an Accessibility option to provide an ADA compliant way to trigger shake?
It is reasonable to wish to take an old phone or tablet and attach it to the wall in your home as a SmartThings âhome visualizer and controllerâ. But, except for the rare earthquakes here in San Francisco, it is not possible to shake my entire wall.
Seriously, am I being facetious?Iâll let my peers commentâŚ
My personal perspective is that if an interface can be made more accurate and useful while reducing operational complexity, then just do it already. I brought up my âshake isnât a gestureâ complaint over 18 months ago or more. Why is formbeatingfunction in the interface?
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
112
I also believe that Scenes should be a âFirst Class Objectâ (and/or, at least, Hello Home Actions / Macros should be available throughout the systems as a First Class Object).
I may not be using the terminology precisely, but what I mean is an extension of what @jody.albritton has written: The âThingsâ display (and the logic rules that can be applied to Things, such as read state, turn on and off, etc.) should include compound Things (Groups, Zones, Scenes) and a Sequence of Actions on Things (Actions, Macros, Saved State (dim levels of a set of lights, grrrrâŚ), etc.); with as little interface differences as possible.
If it says so on the bottle and itâs not doing it, itâs a bug, not a feature. There is no fine print.
You have no idea how many times I have tried to figure out why my lock is open in the morning, before I noticed the pattern and found a workaround. If my wife ever found out, ST hub would be in the dumpster already.
Well said, my friend. It would go along well with a âDo you feel lucky?â button.
What is there to debate about? I have not met a single person, either on this board, or in person whoâd give âthumbs upâ to this âfeatureâ. The most benign reaction I get when I show it to someone is a blank stare. What kind of UX geniuses came up with this bright idea?
+1 minus the songs. shakes suit her not ST. Cmon guys! You guys are nasty. Rather than some coding and tweaking ST, itâs ST reversed Taylor Swift on my mind. May be @alex should make her the spokesperson for ST?
@alex thanks for this guidance. I just removed eight non-essential Things from my setup. Down to 82 from 90 devices. My Android full app startup load time just decreased from about 45 seconds to 14 seconds. Iâm fairly certain removing the DLink and Foscam camera devices made the most significant improvement to mobile app startup load time performance. Also removed 2 of 3 Jawbones and some Virtual switches.
@alex Regarding the mobile app performance. 90% of the time when I start the mobile app, I am not interested in checking status of my devices. I usually start the mobile app to control a single device, execute a Hello Home action, or configure a device or app. The low hanging fruit for performance here would be to simply not refresh all devices status when the mobile app is started. Rather, have a âRefresh devicesâ button available on the initial load screen. Maybe only load people presence status on initial load.
Alternatives. The majority of the time I load the app I click on Things under Home & Family. I rarely use the options below like Safety & Security, Labs, Lights & Switches etc. Itâs almost always Things, or occasionally scrolling to the bottom and clicking the â+â to add new things or SmartApps. I wouldnât mind if Things status was not polled by the mobile App until I clicked on the Things menu. At that point I would expect it to load the status of my top-level Things that have no parent group. For things I have in groups, I would expect those statuses would not load until I pressed the group and the child Things tiles load.
For users who do use the initial view to check things like âDamage & Danger: Everything is OKâ status, you could have a separate âLocation Statusâ menu to jump to that gives that polls all things status and gives the full status view by category. I have notifications setup for anything important. Thus loading the mobile app to check status is something I do very infrequently. For me, this full location status report is not worth the pain of a full Things poll wait each time I start the app.
I think avoiding the unnecessary cost of loading everything each time the mobile app is started is going to be the easiest way to avoid miserable performance for people with many devices. I have other Apps on my phone that work similarly. A couple even have an option in Settings for me to turn on/off status refresh when App is started. That would work too.
I think the mobile App basically provides three use cases: Control, Configure, Report Status. I think the UI should be redone to focus on those three primary uses. Without one slowing the experience of the other.
Also, the mobile App occasionally loses status of devices when the user makes changes. Dragging down the screen in the Android App does not refresh status AFAICT. I would prefer to have a drag to refresh or âRefresh Thingsâ button to press rather than having to force kill the app and restart multiple times.
I completely understand your point on it though, and agree that it should work differently without the requirement for the associated door open/close event.
