New emoncms layout not scaling well with apps

[pb66 (Paul)]

Surely this cannot be right?

why are the power and kwh graphs now side by side and why is that all squeezed into less than a quarter of the screen space available, so each graph is only using around 5-10% of the space it could be using.

This is all the latest master branches updated today.

The reason there is no data is because this is a test set server, my live servers will not be seeing these latest updates for some time yet.

Same occurs for the mysolar although the individual graphs are larger as they almost use the full quarter screen each eg power view

and history view

I’ve checked settings.php and

    // Use full screen width
    $fullwidth = true;

I’m not convince “full width” is actually strictly speaking “true”!

This is a large 40" 4K screen so not your average size but still . . .

Am I missing something (other than a pair of binoculars)?

[TrystanLea]

Hello @pb66, this is what I see:

I think the issue must be the dashboard optimized for a lower screen resolution? if I zoom out I can replicate what you see…

[pb66 (Paul)]

@TrystanLea

this is what I see:
. . .
if I zoom in I can replicate what you see…

Likewise I can zoom out to 175% and see something similar to what you see

it’s pretty much the same as I would see on a smaller screen, just larger, not better quality nor more detail nor a longer time frame displayed. Just bigger. For example that menu column down the left edge is now way oversize at 150mm (6") wide.

Also note the page footer overlap too.

This is a pre v10 myelectric page at 100%, the browser is fullscreen but the webpage is just open on a tab, the “$fullwidth” setting is false on this live server.

This is a post v10 myelectric page also $fullwidth=false and the exact same settings window size etc etc

Considering they are both using $fullwidth=false my only criticism of the pre-v10 would be that it could have perhaps extended the graphs vertically to fill the screen, it knows where the screen ends as the footer (as seen in the post-v10 but not displayed on my live server) is correctly positioned.

Whereas the post-v10 layout is not only smaller overall, it has much narrower report periods, both time wise and screen wise. Despite the layout being side-by-side rather than stacked like the pre-v10, the vertical scale isn’t much greater than the pre-v10, it’s just half as wide, which equates to half the detail. Plus it is not centred.

@TrystanLea

I think the issue must be the dashboard optimized for a lower screen resolution?

Possibly, but are you saying that’s by design? Does accommodating smaller screens need to come at the cost of supporting larger ones?

It would be nice to be able to see data in greater detail for a longer reporting period , especially when interrogating graphs. Here is a pre-v10 multigraph (same settings as above)

Same issue with the limited height, but at least it’s full width, here’s a post-v10 multigraph (same settings)

This is a pre-v10 rawdata visualisation after clicking the emoncms “fullscreen” button in Viz

Possibly a bit too much height there as you need to scroll to see it all, but that is a far better view for looking at raw data in detail than the post-v10 page generated by the same “fullscreen” button in viz

I think part of the issue is that honouring $fullwidth isn’t (wasn’t?) consistent, all of the above is with both servers set to $fullwidth=false; mainly because I do not like the way that $fullwidth=true; changes the dashboards and apps to be left aligned rather than centre aligned (much like the current app even without $fullwidth=true). So you see the pre-v10 wasn’t always NOT fullwidth when $fullwidth=false is set. Below is the same rawdata (as immediately above) but with $fullwidth=true set

Much better! But unfortunately it doesn’t get applied to either the apps or the graphs

and the pages are left aligned to the menu

unless you set $fullwidth=false

but that only centres the graph module not the apps module

or the dashboards $fullwidth=false:

$fullwidth=true so dash becomes left aligned to the menu

Notice how the footer is always centred regardless of the menu collapse or $fullwidth setting, this should IMO apply to all dashboards, graphs and apps too. The page should always be centred in the page, collapsing/uncollapsing the menu should just widen/narrow that screen.

So going back to the original observations with the myelectric page, to sum up I think all app, dash, graph and viz pages should

• centre align on page (even if $fullwidth=true)
• scale horizontally to use full width when $fullwidth=true
• scale vertically to utilise the available height down to the footer (regardless of $fullwidth)

obviously there would be min page sizes that introduce scroll bars on smaller screens/windows

more specific to the my electric page, why are the graphs now side-by-side? If it’s to accommodate smaller devices could it be dynamically switched from the old layout on smaller devices? Or be a user setting? I think the older stacked layout would scale better for most screens.

Oh! I just took a look at the myelectric on my mobile and was pretty surprised to see the graphs stacked! That is indeed IMO the better way, but now I’m confused as to why the layout was changed for non-mobile users, why not just keep the stacked view for all?

[borpin (Brian Orpin)]

@pb66

This is a large 40" 4K screen so not your average size but still . . .

It is down to the displayed information being a fixed resolution - a window of about 1494*784. I’m guessing you are running at a much higher resolution (monitor size is irrelevant - resolution matters - you could run a 40" at 1080p if you wanted) so the top corner is about that. At any resolution, if you expand / contract the browser window size, the contents do not scale.

[nchaveiro (Chaveiro)]

Noticed this bug too.
And if you set a graph on a dasboard to be 100% width it does not scale also as it used on v9.

[pb66 (Paul)]

Further to the above I have just noticed another anomaly regarding centre alignment of the graphs module with respect to the menu.

I wanted to capture a screenshot of an appliance run with the various settings etc so that it was self explanatory and could easily be reproduced later. For this I wanted the menu shown so that the feeds selected were visible.

I also wanted a compact screenshot rather than a huge picture with lots of dead space so i reduced the windows size to better suit the graph area. The menu then obscures the graph

until the window is big enough to show the whole graph with a column of dead space equal to the width of the menu (marked in red)

Yes, I can (and have) just took a screenshot of the window minus the dead space. The reason i posted here was just to demonstrate the different behaviour of the graphs to the dashboards(with $fullwidth=true) and apps which are both left-aligned to the menu and simply move with the menu so they are never obscured by the menu (in fact the input and feed pages are also like that when $fullwidth=true) but they do not centre on the whole page, they seem to centre on the whole page minus the menu as I would expect across all the modules and pages.

So to update

@pb66

to sum up I think all app, dash, graph and viz pages should

• centre align on page (even if $fullwidth=true)
• scale horizontally to use full width when $fullwidth=true
• scale vertically to utilise the available height down to the footer (regardless of $fullwidth)

should perhaps be

to sum up I think all app, dash, graph and viz pages should

• centre align on page when menu is collapsed (even if $fullwidth=true)
• move to the right, remaining centred on the non-menu part of page when menu is visible
• scale horizontally to use full width when $fullwidth=true
• scale vertically to utilise the available height down to the footer (regardless of $fullwidth)

It seems the centering behaviour is closely tied into the $fullwidth (except for the apps module) because even the input and feeds pages centre on the pages “fullwidth” when $fullwidth=false (A bit upside-down perhaps???)

It is just more apparent with the graphs module as the feed selections are useful info.

[pb66 (Paul)]

Just to add . .

With $fullwidth=true the graph page does also work the same way as the input and feeds page so my expectation is somewhere between the way the $fullwidth=false and $fullscreen=true modes work, I can get most of the screens I want by continually changing the $fullwidth setting. Not only is that PITA but as it is a global setting, if this test server was live, it would be playing havoc for other users.

With $fullscreen=true

so far so good, so I widen the window

also looks promising as the graph area has grown with the window size. Lets hide the menu . .

That’s not so good, the graph has not grown to fill the space nor has it centred! What about if we go bigger?

The graph has not changed with the window size, it seems the dynamic sizeing has a ceiling, once it gets to a certain size it doesn’t matter what size the window is, the best thing I can do here so it doesn’t look quite so odd is change the $fullwidth back to “false”

It looks better centred, BUT it is both shorter and narrower than the left aligned “$fullwidth=true” page of the same graph in the same window. As awkward as this is, the apps module doesn’t even do this! It remains firmly, both left-aligned and smaller regardless of the $fullwidth setting

[TrystanLea]

Thanks @pb66.

It seems to me from testing here that generally the behavior is:

1. With fullwidth = true; the page aligns to the sidebar and when you hide the side bar the page moves to the left side of the page. This seems consistent across all pages. The input and feed lists expand to cover the available room all the way to the right edge, whereas the other pages e.g apps, graph, dashboards have a fixed maximum page width.

2. With fullwidth = false; the pages are all center aligned with a fixed page width, apart from the apps module which actually overwrites the fullwidth settings in the app_controller to be true.

3. The visualisation module graphs do not resize if the sidebar is toggled.

I think its time to remove the fullwidth setting, it was a remnant of a preference I had for input and feed pages that had a fixed width. With the new design for the input and feed list tables and the sidebar making use of widescreen space I only ever keep the setting as fullwidth true now, its the default on the EmonPi and we only test with fullwidth set to true.

I think it would be good to change the behavior of what happens when you close the sidebar. Rather than aligning to the left edge of the window, it would be good if the page aligns to the center of the window (if it is a page with a fixed width).

In the longer term it would be great to be able to set a page width for dashboards, so that its possible to create relatively narrow dashboard pages that still center align.

[TrystanLea]

I also think that it would be good if when the user chooses to minimize the sidebar the sidebar stays minimized, even if the page is resized. If the user chooses to maximise the sidebar it then returns to the automatic responsive behavior.