Since dragging items under a 1d index restriction is kinda frustrating and provides a lot of unintuitive use cases, we're going to give 2d positioning a try, and compare the experience.
We start from the premise that this isn't going to work for resize, but it's kind of a false dilemma. Sure, we have to recalculate the position of the widgets when opening the Board on a different grid configuration (zoom), based on an algorithm that converts 2d positions into 1d ones and than back again, for the new grid configuration. But we already do this, dozens of times per second, while the poor user tries to drag.
OK, so whether we use the algorithm to position the items from the start (the screen on which the user probably stays 90% of the time), or just after changing grid configuration (on a different screen size), we have the same displacement effect, because we use the same algorithm. This is constant, you can't have the same positions for less or more space.
Since using both strategies we establish the same experience when a board is opened on a different screen size (zoom level) than the one it has been configured from, let's improve the one it will MOST LIKELY be used on, the one it's being configured in.
We're now violating a basic UX rule: don't alter the user input!
Acceptable frustration:
"I opened the canvas on a different screen size and the widgets don't have the EXACT same order"
Inacceptable frustration:
"I'm dragging a widget in a corner and it goes in the other corner"
or
"I just wanted to swap two widgets and ALL THE WIDGETS got displaced"
Let's not make our product unusable. Instead of being "it doesn't work like that, it's complicated, you can't put that there" let's be "anything goes, just put widgets wherever you feel like it, and we'll try to make it work as similar as possible on any resolution, if you want to arrange a dashboard for a specific screen size, please organize it directly in that resolution (just like you do for reports mode)"
Here are a few other advantages:
You no longer need weight, since displacements are less intrusive, you just POST the updated coordinates for the moved items
Instead of calling the 2d > 1d > 2d algorithm every other millisecond while the user is trying to drag, you just call it ONCE, only if the user opens the board in a different screen size than the one it was configured for (we just store number of rows). If the user edits the board in a different screen size, then this is the size the board needs positions persisted for, so all the new widget positions need to be POSTed. This is the only drawback, but we'll communicate this as a "convert" action, just like changing boards/reports mode.
The internals of the grid positioning layout simplifies, we don't have these so called groups. The widgets are just as the user puts them, then the algorithm generates a virtual 1d index reading widgets top-to-bottom > left-to-right, then it positions them the same way top-to-bottom > left-to-right (since the height is the fixed part), and that's that. It's just a conversion algorithm, the positions are 2d, as they should be in any drag-and-drop environment.
Our current work wasn't at all in vain, the algorithm is the same, the tests just need to be adapted (I integrated Jasmine in the meantime, it's DOMless and pretty cool) - and in the end only when having both demos to test on will we be able to make the best decision. /cc @aismail @valentinzberea @andreivasilescu @vladimiroane
Since dragging items under a 1d index restriction is kinda frustrating and provides a lot of unintuitive use cases, we're going to give 2d positioning a try, and compare the experience.
We start from the premise that this isn't going to work for resize, but it's kind of a false dilemma. Sure, we have to recalculate the position of the widgets when opening the Board on a different grid configuration (zoom), based on an algorithm that converts 2d positions into 1d ones and than back again, for the new grid configuration. But we already do this, dozens of times per second, while the poor user tries to drag.
OK, so whether we use the algorithm to position the items from the start (the screen on which the user probably stays 90% of the time), or just after changing grid configuration (on a different screen size), we have the same displacement effect, because we use the same algorithm. This is constant, you can't have the same positions for less or more space.
Since using both strategies we establish the same experience when a board is opened on a different screen size (zoom level) than the one it has been configured from, let's improve the one it will MOST LIKELY be used on, the one it's being configured in.
We're now violating a basic UX rule: don't alter the user input!
Acceptable frustration:
Inacceptable frustration:
or
Let's not make our product unusable. Instead of being "it doesn't work like that, it's complicated, you can't put that there" let's be "anything goes, just put widgets wherever you feel like it, and we'll try to make it work as similar as possible on any resolution, if you want to arrange a dashboard for a specific screen size, please organize it directly in that resolution (just like you do for reports mode)"
Here are a few other advantages:
Our current work wasn't at all in vain, the algorithm is the same, the tests just need to be adapted (I integrated Jasmine in the meantime, it's DOMless and pretty cool) - and in the end only when having both demos to test on will we be able to make the best decision. /cc @aismail @valentinzberea @andreivasilescu @vladimiroane