The shape of a button

Here are a few buttons, 3 with default styling and 3 with border-radius: 50% and colour changes.
The button label shows what size it is - 1x1, 2x1 or 2x4.

  1. Perhaps foolishly, I expected a 1x1 or 2x2 button to be square, but it's rectangular. Why? Is there a way to configure the template so they will become square?
  2. If I try to make a button square by specifying 2 wide and 4 tall, it becomes almost square. Just sufficiently not square so that it looks wrong. On my browser, full screen it seems to be 283px wide by 310px high.
  3. If I drag my browser window to different widths, the button width scales but the height does not. This leads to some undesirable effects:
    Starting off pretty slim 1

    and getting progressively wider
    2 Blank space appears to the right of the group.

    3 Then it disappears

    4 And comes back again.
    At this point the sidebar leaps unrequested onto the page, further screwing up the buttons.

This is with @flowfuse/node-red-dashboard v1.16.0.

Summary of what seem to be issues:
A square button is portrayed as a rectangle.
The width of a button is responsive but the height is not.
The button font size is not responsive and in some representations it is allowed to overflow.
The sidebar is displayed at some screen sizes and not at others.
Once the sidebar has manifested itself, it does not go away again without clicking on the hamburger icon.

It does not seem viable to create a dashboard to use at different screen resolutions, or am I missing something fundamental?

Edit: It seems that one fundamental thing I missed is that changing border-radius from 50% to em or rem units changes the button from elliptical to a much nicer oval.

Which layout style are you using? For "Grid" the width drives the number of columns the button renders at, which will the vary the px width, depending on the width of your screen.

If using "Fixed" layout, then I think we do have discrepancies here, that I agree, should be consistent

This is a result of the "Breakpoints" and the driver of how we handle responsiveness in Dashboard 2.0

You can read more about them here. The TLDR is that we render a different number of columns at different screen widths in order to maintain a sensible layout automatically.

If you want sizes to be consistent (as in px consistent) then you can use the "Fixed" layout.

Please do open an issue for that, that is a bug.

I'm pretty sure it's "Grid" but I can't verify that since after upgrading to v 1.16.0 the dashboard 2 sidebar is blank

Forgive me if I'm misunderstanding you Joe.

Are you suggesting that a 1x1 button not getting rendered square is not a bug?
What about the non-responsive height?
The intrusive sidebar?

I was referring to the text overflow, sorry, should have been clearer in my quotation.

The not square if a side effect of the grid layout (although I think there are frustration in 'Fixed" too which we need to investigate).

The non responsive height is very much by design. If you have a Form/Table with n rows, the wider the screen gets, the height of each row should not change.

It is possible to do square button but it is unreasonable to provide as default behaviour cos the responsiveness has strategy and there can be only one strategy in use at the time.

So the strategy is that all elements (widgets) are also responsive. (to some extent at least) That way it is possible to make layout without need to manage inconsistent free space around widgets.

Other kind of problem rises up if that square thing tries to be responsive. So it grows according to space available. In both directions. So the row it is in grows in height. But if something is next to it, it also should do something to still look nice and commonly still provide balanced layout. That kind of situations can't be predicted thus nothing can't be provided as for common layout with zero coding needed.

It is also possible to make your own layout in all levels of the container system the dashboard provides. It is pretty complicated and it heavily depends on content. Thus it is not something I can just point out how to do.
It takes to have clear vision of the page.Most useful is to start with planning with pen and paper.
And then it's mostly the CSS.

Can you check your console Joe:
I fixed this last month - Blank Sidebar when def icon is a function (subflows) · Issue #1195 · FlowFuse/node-red-dashboard · GitHub

@hotNipi I have seen many examples of your work on dashboards which show your appreciation of the aesthetics.

I don't agree.
There is a grid. It should be square and (if the browser window is big enough) it should be rendered square.
Of course you are right that when things get shuffled around something has to give.

A half round gauge retains it's proportions at different screen sizes.
Well of course it does, a gauge is a strongly visual element which would look ridiculous if it was stretched.
The payoff is that the gauge gets extra white space above it.
image

Is a button not also a strongly visual element?
If it's a default button, a coloured rectangle 1 unit high then the answer is no, it's more like a simple text element.
But buttons don't have to be simple coloured rectangles.
This is a dashboard 1 button I've been using for years.
image
I can't use this on dashboard 2 because a) It does not display as a circle (in a square) at any screen resolution b) change the resolution and it's going to be stretched into various elliptical shapes.

Do we need to have two different dashboard widgets, a button which stays in proportion and a button which stretches to fill the space allocated to it?

Oh no. Same rights for every HTMLElement please!!!

Here's the layout is forced to behave to have 5 square buttons and the last column has buttons to fill the rest of space available. Square buttons have defined width and aspect ratio 1.

It takes to have CSS override for that group and for buttons which land on those square slots.

.special-grid .nrdb-layout-group--grid{
    grid-template-columns: 48px 48px 48px 48px 48px 1fr !important;
}
.square-button{
    aspect-ratio: 1;
    width: var(--widget-row-height);
}

So it is entirely possible to have square buttons but it takes also to manage the surroundings somehow. So it is so called "dedicated design". Common solutions can't be built with such kind of options in mind. It is not manageable and not predictable.

1 Like

Providing a user-configurable dashboard that truly 'listens' to the user is superhard. Especially when applying a gridsystem and dealing with responsive layouts. As masonry is not an option (yet) (although you could use a column layout as well, at the cost of horizontal alignments), you always end up with dealing with row heights, but why the same height is applied to a button puzzles me.

The only interface that truly nailed it, is Grafana, which actually using something similar to gridstack, which (un)ironically the node-red-dashboard uses for the layout of the widget.

Could you post a mini flow using that please, so I can have a play with it?

Edit: code reposted further down the thread

That appears to be just a D1 template node, I meant your attempts to make it work in D2, which give the effect that you have described.

No, it's a simple button node with a bit of CSS.

My attempts to migrate it to the new dashboard go no further than my original post illustrating a button with/without border-radius 50% producing an unattractive result.

I can only see the ui_template, ui_group and ui_tab in the export.

Oops, try this

[{"id":"20d45887.d8ef1","type":"ui_button","z":"69594495cf1ea8a1","name":"Button","group":"5b5ee9f169c93ecf","order":1,"width":2,"height":2,"passthru":false,"label":"","tooltip":"","color":"{{foreground}}","bgcolor":"#eeeeee","className":"round","icon":"fa-power-off fa-4x","payload":"toggle","payloadType":"str","topic":"","topicType":"str","x":450,"y":80,"wires":[["46b4fb8b97653bf0","36ac183f82ba116c"]]},{"id":"f8088574.aea0e8","type":"ui_template","z":"69594495cf1ea8a1","group":"5b5ee9f169c93ecf","name":"CSS","order":8,"width":0,"height":0,"format":"<style id=\"round-button\">\n.round i {\n\ttext-shadow:\n\t-1px -1px 1px #444444,\n\t1px -1px 1px #444444,\n\t-1px 1px 1px #444444,\n\t1px 1px 1px #444444,\n\t0px 0px 10px #888888;\n}\n/* round button */\n.round button {\n    border-radius:50%;\n    border-style:solid;\n    border-width: 3px;\n    border-color: #888888;\n}\n.nr-dashboard-button.round { \nmargin-left: 10px !important;\n}\n</style>","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":450,"y":40,"wires":[[]]},{"id":"46b4fb8b97653bf0","type":"debug","z":"69594495cf1ea8a1","name":"Button press","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":610,"y":80,"wires":[]},{"id":"36ac183f82ba116c","type":"function","z":"69594495cf1ea8a1","name":"Change foreground","func":"msg.foreground = context.get(\"buttonstate\") || \"white\"\nif (msg.foreground === \"white\") {\n    msg.foreground = \"red\"\n}\nelse {\n    msg.foreground = \"white\"\n}\ncontext.set (\"buttonstate\", msg.foreground)\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":270,"y":80,"wires":[["20d45887.d8ef1"]]},{"id":"5b5ee9f169c93ecf","type":"ui_group","name":"demo","tab":"195948bb680041dd","order":1,"disp":true,"width":"6","collapse":false,"className":""},{"id":"195948bb680041dd","type":"ui_tab","name":"Demo","icon":"dashboard","disabled":false,"hidden":false}]

OK, I will have a look in the morning, hopefully.

Surely if you need to go to those lengths, you'd have to consider hard whether Dashboard was the right tool for the job?

Dashboard's main job is surely to be quick and easy to get started. It probably won't be the best tool if you need very specific page designs since you will have to undo or work around much of the baseline of the Dashboard.

I suspect that there may be a misunderstanding here - the difference between a mathematical grid and a CSS grid layout. There is no assumption of squareness in a CSS grid. It is really a kind of dynamic layout.

If you want true square/circular elements inside a CSS grid, you must make the object a child of the grid cell and give it explicit sizing. Then you will probably need to decide on positioning within the cell to allow for the varying whitespace around it. I don't really know the details of how buttons are specified within Dashboard to say whether that is done.

Here, for example, is the visual grid layout from a recent example of mine:

And here is the specification for it:

image

As you can see, the grid is 12 columns by "auto" rows and the cells are far from square which is to be expected since the rows auto-size to fit the tallest cell entry for each specific row.

If I wanted a square button inside one of those cells, I would have to explicitly size the button.

Here is a quick example:

The HTML is simply:

<article style="--article-width: 7;">
    <h2>Card 5</h2>
    <p>
        This has an overridden width, see the HTML. Sets the number of grid columns used, there are 12 total in the default example but you can change this to anything in the CSS file.
    </p>
    <button class="square">Square dude!</button>
</article>

And the extra CSS is:

.square {
    width: 5em;
    height: 5em;
}

Set with em sizing so that it resizes on zoom or other user-settings.

Or even better, specify as:

.square {
    width: var(--sq, 5em);
    height: var(--sq, 5em);
}

Then you can override the default the size easily in HTML:

<button class="square" style="--sq: 10em;">Square dude!</button>

Sometimes I love CSS! :grinning:

1 Like

@jbudd I still cannot import your code into dashboard 2, unknown ui_template. unknown ui_button