Drag & Drop layout directly on a user defined grid size
The title is pretty self explanatory, but I should probably explain.
The current layout is functional, but takes a significant amount of time to get configured to a specific screen size or resolution. Allowing the user to start with a grid size of their choosing will allow them to verify the correct size before they begin their layout. Once they have found the correct size, the user could then drag and drop their available tiles onto the grid.
This would eliminate all of the back and forth necessary to do a new panel layout, as well as the need for blank tiles to be added.
Answer
Speaking with others, this would be an incredible addition to the app and create a much needed "user friendly" set up process. Several I have spoken to have stated the set up is tedious and should include some type of drag and drop and also drag and arrange process to help customize and set up the panels.
Thanks for collecting feedback on this, Jason, because the opening statement from Jon isn't accurate (i.e., Jon says "The Title is pretty self-explanatory..." ... it is not).
Implementing anything along these lines comes with a bunch of complications. Some of them are just coding related, but with every change to make things simpler, there will be somebody who finds it more complex.
Thus, this discussion needs to be much more active and detailed in order to first figure out what is likely the "optimal" design, and then whittle in down (and build it back up) by seeing what is possible in code and doing usability testing against it.
Note:
We have very important internal reasons for the current implementation. That doesn't mean it is optimal; rather this means that we carefully considered and balanced the cost of implementation, reliability, complexity, and other factors in order to arrive at the current design. Improvements may be incremental or radical or some of both. This is completely undecided at this time since more research is required.
There are dozens of other Features very likely to take precedence over this one. Form vs Function: Most customers would prefer us to spend effort (aka time and money) to add new functionality, rather than diverting the resources to fix what isn't broken, even if it isn't optimal.
Thanks for the input, David!
The effort to configure a panel in the current implementation is at least 3 or 4 times longer than if you had drag and drop.
If the process of Panel Building and Editing were that onerous, we hope we would have a lot more VOTES on this Topic. Adding Tiles in a list, in Left-to-Right / Top-to-Bottom order is technically very efficient, especially since the customer is aware of how many Tile units exist per row - in most cases it is under 15.
SmartThings's first version App (pre-Classic!) used a "tiled" layout for all Things, and had in-place drag & drop. But the actual behavior was Left-to-Right / Top-to-Bottom: i.e., if you moved a Tile up from one location to another, all other Tiles would shift to the Right to make room for it - thus changing the rest of the Tile layout grid in a somewhat unexpected way.
I reiterate that we certainly hear and recognize that layout could be more "user-friendly"; but a stable / reliable grid-based drag & drop editor is difficult to implement. Particularly without serious impact on editing performance.
This Request is never out of our minds. There will be a magic moment when it is optimal to implement it, instead of working on something else. In addition to this Forum, we also poll random users and listen to Help Desk feedback, etc., to ensure that any particular issue isn't becoming a critical problem to our Customers or sales growth.
So this morning was a perfect example of the drawback of not having a drag/drop interface.
I discovered the weather tile you can add via the SmartThings IDE. I would like for this to be at the top of my panel next to the Date/Time thing I have in the upper left corner. This has of course shifted everything on my panel so now I have to go into the panel builder, select arrange tiles, move some stuff around, go back to view the panel and repeat the process until I have it right. If I were able to see the layout as I moved things around it would take FAR less time.
Home Automation is not a build a panel and forget about it. Things are always being updated and enhanced with new devices or features. This is why I think the effort you put into this feature would make a large percentage of existing customers and all new customers much happier.
Thank you for a great product which I hope will be even better in the near future.
Isn't this accomplished by having your tablet, or tablets, near you? I'm just getting started on my first implementation so new to the game, but I saw a video where the person did tiles and looked at his tablet to view.
Don't get me wrong, my tablet hasn't arrived yet so definitely already frustrated with having to go back and forth.
Hi Carle,
Yes - using a desktop or laptop saves a lot of time when building or editing a Panel. You don't even need to have the Tablet next to you, since you can open a second browser window and just size it the right width to match your target Tablet. Of course, having the Tablet next to you gives you extra work-space and ensures you verify the legibility and performance of the Panel too.
Without using multiple windows or tablets, "going back-and-forth" is generally avoided by getting a feel for how the layout engine works. Just by counting the number of Tiles in a list, you can predict where the wrap points will be. We certainly admit this isn't trivial for more complex Panels that have Tiles of assorted heights and widths.
Customer support service by UserEcho
Thanks for collecting feedback on this, Jason, because the opening statement from Jon isn't accurate (i.e., Jon says "The Title is pretty self-explanatory..." ... it is not).
Implementing anything along these lines comes with a bunch of complications. Some of them are just coding related, but with every change to make things simpler, there will be somebody who finds it more complex.
Thus, this discussion needs to be much more active and detailed in order to first figure out what is likely the "optimal" design, and then whittle in down (and build it back up) by seeing what is possible in code and doing usability testing against it.
Note:
We have very important internal reasons for the current implementation. That doesn't mean it is optimal; rather this means that we carefully considered and balanced the cost of implementation, reliability, complexity, and other factors in order to arrive at the current design. Improvements may be incremental or radical or some of both. This is completely undecided at this time since more research is required.
There are dozens of other Features very likely to take precedence over this one. Form vs Function: Most customers would prefer us to spend effort (aka time and money) to add new functionality, rather than diverting the resources to fix what isn't broken, even if it isn't optimal.