Plan layout for floorplan-like pages with system/custom widgets

[tarag]

I wanted a way to create pages with floorplan layout but interactive (allowing any kind of widgets). It seemed to me the most logical way was to extend the existing layout pages with one additional layout.

That way, the existing floorplan pages can be kept for those using them.

[relativeci]

Job #217: Bundle Size — 10.65MB (0%).

810060e vs 6873f34

Changed metrics (1/8)

Metric	Current	Baseline
Cache Invalidation	0%	50.88%

Changed assets by type (0/7)

No changes

---

View Job #217 report on app.relative-ci.com

[ghys]

Thanks @tarag for your work, just know that it's not been unnoticed! There are surely use cases for this type of layout.
I did try it and while I have concerns about the designer UX (I will elaborate on those later), with OH 3.1 just around the corner I believe out of stability concerns we should rather target it for 3.2, maybe the first milestone even. But I'll be sure to follow up then.
Thanks again!

[tarag]

Hi @ghys , now that 3.2 is in progress, could you tell me your concerns regarding this PR?

[ghys]

Sorry for the delay @tarag I'll do a review this week.

[ghys]

Apologies for my failure to follow up this month @tarag...
I did finally review it and the code is good overall - but I'd like to discuss the design/integration of this new layout type first.

For a start, we shouldn't call it "floorplan layout" in my opinion, because:

1. it would undoubtedly lead to confusion since there already are floorplan pages which is a quite different concept (it's basically a map with a custom background layer)
2. there is potential for this feature beyond simply floor plans (think schemas of energy flows with absolutely-positioned labels, for example). It's true that this applies to floor plan pages too, but the pan/zoom feature of these doesn't work that well with schemas, so it was simpler to simply call them "floor plan pages" as this would be the primary use case.

After thinking long and hard (!) on how to call it, I'd like to suggest "canvas" - I believe it conveys well the fact that you have a frame of sorts you can "draw" widgets on (i.e. position them freely).

Second, I think this new layout has a great deal of similarity with the existing "fixed grid" layout type; especially considering the fact that it has a "snap to grid" feature. I also don't quite like having a menu with 2 top-level fixed layout types at the same level as the responsive layout which should remain the default, recommended option for most pages unless you target it specifically for a fixed screen size.
Therefore I'd like to merge the existing "grid" layout and the new "canvas" layout into a single "fixed" layout - you would therefore have an additional page parameter to specify the type of fixed layout, like so:

Layout type	layoutType parameter	fixedType parameter (new)
Responsive	responsive or blank*	N/A
Fixed Grid	fixed	grid or blank*
Fixed Canvas	fixed	canvas

(*for backwards compatibility)

Then the initial "big buttons" menu should be redesigned to show the "responsive" type prominently and the "fixed" types with the 2 sub-types as an alternative. Especially since it doesn't look too good on narrow screens:

I'll try to come up with an updated design for this menu.

Last, it's important to have a good design experience even on a phone so first these "toolbar" buttons above the canvas:

should look similar to those in the grid layout:

That is, the snap-to-grid & configure canvas (and eventual paste if there's a copied widget) options in a dropdown menu - and "Add Item" should be changed to "Add Widget".

When on a touch screen, dragging the handles to resize a widget doesn't scroll the page but dragging the widget itself to move it does - this should be easily fixed hopefully:

Please let me know if you agree with all the above, looking forward to have this merged!

[ghys]

As stated above it should be:

Suggested change

	<template v-if="config.layoutType === 'responsive'">
	<template v-if="!config.layoutType || config.layoutType === 'responsive'">

since the layout types were introduced with 3.1 and pages created before don't have it and for backwards compatibility should still be treated as responsive types.

[ghys]

According to RelativeCI it's only a ~70kB overhead on the initial JS (or +4%), so while it's not that much, couldn't this be lazy loaded with the oh-plan-layout (see how the oh-grid-layout component imports the vue-grid-layout library)?

[tarag]

Apologies for my failure to follow up this month @tarag...

I've been quite slow in the response too so no worries. I've made a big mess with the commits too sorry for than, I hope you can figure the changes...

For a start, we shouldn't call it "floorplan layout" in my opinion, because:

1. it would undoubtedly lead to confusion since there already are floorplan pages which is a quite different concept (it's basically a map with a custom background layer)
2. there is potential for this feature beyond simply floor plans (think schemas of energy flows with absolutely-positioned labels, for example). It's true that this applies to floor plan pages too, but the pan/zoom feature of these doesn't work that well with schemas, so it was simpler to simply call them "floor plan pages" as this would be the primary use case.

After thinking long and hard (!) on how to call it, I'd like to suggest "canvas" - I believe it conveys well the fact that you have a frame of sorts you can "draw" widgets on (i.e. position them freely).

I agree with you on the risk of confusion. Yet, we could also replace the floorplan with this updated proposal as it probably fulfilled all the needs of current floorplan users but provides more (except the zoom but there is the normal plan for that and we could as a zoom feature to my proposal too). For sure in that case a migration should be provided.

Second, I think this new layout has a great deal of similarity with the existing "fixed grid" layout type; especially considering the fact that it has a "snap to grid" feature. I also don't quite like having a menu with 2 top-level fixed layout types at the same level as the responsive layout which should remain the default, recommended option for most pages unless you target it specifically for a fixed screen size.
Therefore I'd like to merge the existing "grid" layout and the new "canvas" layout into a single "fixed" layout - you would therefore have an additional page parameter to specify the type of fixed layout, like so:

Layout type layoutType parameter fixedType parameter (new)
Responsive responsive or blank* N/A
Fixed Grid fixed grid or blank*
Fixed Canvas fixed canvas
(*for backwards compatibility)

I performed this change both in code and in the new file names.

I'll try to come up with an updated design for this menu.

I did not change that, maybe you can propose something now that the code has been updated?

That is, the snap-to-grid & configure canvas (and eventual paste if there's a copied widget) options in a dropdown menu - and "Add Item" should be changed to "Add Widget".

I did change the add widget button. Concerning the Paste and Snap to Grid button, those should really be thought as temporary use edition tools and not really configuration. In fact the snap to grid function does nothing if you toggle it and then not use it to reposition widgets. On the other hand, I can tell you because I have created several of these new canvases, having them rapidly accessible is very convenient when editing layouts. Therefore I just replaced the snap to grid button with a smaller icon based one, I believe it should no longer cause visual issues on small smartphone screens (which are not really the target for this kind of layouts of course). Are you ok with this?

When on a touch screen, dragging the handles to resize a widget doesn't scroll the page but dragging the widget itself to move it does - this should be easily fixed hopefully:

I did fix some of the event handling to avoid spurious text selection when dragging widgets and activation of the widgets themselves in edition mode. It seems to me this problem was fixed also as a consequence.

I did also make the change to lazy-load the vue-draggable-resizablemodule.

[ghys]

I agree with you on the risk of confusion. Yet, we could also replace the floorplan with this updated proposal as it probably fulfilled all the needs of current floorplan users but provides more (except the zoom but there is the normal plan for that and we could as a zoom feature to my proposal too). For sure in that case a migration should be provided.

I think there's room for both and they can coexist. With the existing "plan" pages it doesn't matter whether you're on a small (phone) or big screen (1080p or more) and you can zoom & pan to get to your controls - the idea was to have icons and labels only and when you click on them, the actual control will appear in a popover -, while the "canvas" layout's strength is to be able to place full-fledged controls, not just icons and labels, on an image background with less emphasis on the "works on all screens" principle. Hence the importance of naming them differently, and as I said the "canvases" can end up being used for more than floorplans - energy flows diagrams are an ideal use case for them.

I did not change that, maybe you can propose something now that the code has been updated?

Yes I'll do it soon.

I did change the add widget button. Concerning the Paste and Snap to Grid button, those should really be thought as temporary use edition tools and not really configuration. In fact the snap to grid function does nothing if you toggle it and then not use it to reposition widgets. On the other hand, I can tell you because I have created several of these new canvases, having them rapidly accessible is very convenient when editing layouts. Therefore I just replaced the snap to grid button with a smaller icon based one, I believe it should no longer cause visual issues on small smartphone screens (which are not really the target for this kind of layouts of course). Are you ok with this?

That's fair, but maybe if possible add some tooltip to that "snap to grid" button because it might not be that obvious what it does from the icons only (even if we see the grid is appearing, it's so dense it might not be understood right away). By the way I noticed that when you choose the type of a new widget the "snap to grid" option is reset, not sure if it's intended but it was unexpected for me:

[tarag]

That's fair, but maybe if possible add some tooltip to that "snap to grid" button because it might not be that obvious what it does from the icons only (even if we see the grid is appearing, it's so dense it might not be understood right away).

I fully agree, that's what I wanted to do but I couldn't find a way to add tooltip to f7 menu-items, and still can't. I'm not familiar enough with f7/vue, and there is no easy tooltip parameter as for other components.

By the way I noticed that when you choose the type of a new widget the "snap to grid" option is reset, not sure if it's intended but it was unexpected for me:

Thanks for the illustration, this has been fixed.

[tarag]

@ghys: I have no idea how to fix the commit not signed-off, if this is OK for you, I'll create a new PR from scratch.

[ghys]

If you wish, but you could as well try an interactive rebase (see https://www.internalpointers.com/post/squash-commits-into-one-git)

Something like:

• git rebase -i main
• change pick to squash for all commits except for the first one
• resolve conflicts if any and commit with a clean commit message + sign-off
• force push (git push -f)

[tarag]

Thanks for the pointers, somehow that did the job.

[ghys]

Thanks! Here's a new round of review, but I think it's the last, I'll commit a new version of the layout type selection menu after that and we should be good to go.

[ghys]

@tarag I finished the PR with a change to the initial layout type selection and changed the imports so vue-draggable-resizable and its CSS is not loaded by default.
I also added the automatically-generated component docs that were missing.

It would be appreciated if you could write up some docs for the new canvas layout: https://github.com/openhab/openhab-docs/blob/main/ui/layout-pages.md

Thanks again for your contribution!

[tarag]

Thanks, great! I'll do that.

[Larsen-Locke]

The canvas layout is great.
But I have an issue which I described here:
#1475
Would my approach help to solve the problem or do you have any further hints?