Dashboard rendering and different screen sizes


#1

Hi

1920x1200 monitor…

IPad Air 2 @ 2048x1536

l2

IPhone 5s

Questions

  • the IPad gauge renderings are being clipped.
  • why is not the monitor and IPad rendering identical?
  • the IPhone gauge order seems to be left-first, right-last … which seems backwards to me.

Thanks


#2

Re: the iPad, can you please let us know what model the device is and the OS version? We’re unable to recreate that bug here in our office.

For the monitor vs. iPad, the dashboard blocks are horizontally responsive (they expand / contract to the screen size) but the height is fixed. Hence the different aspect ratios you’re seeing.

As for mobile, those blocks are likely ordered in the order they were added to the dashboard; we collapse to a single column because following the dashboard grid just doesn’t work on such a small device. Admittedly we could do a better job of that and we have some such changes coming next year.


#3

IPad Air 2 running 10.2.1. According to its spec, the screen resolution is 2048-by-1536-pixel resolution at 264 ppi. Why the rendering difference versus the 1920x1200 monitor … particularly when oriented as landscape display?

If the blocks on the IPhone are ordered per the order they were added to the dashboard, that could create quite a mess as dashboards are adjusted over time.

Thanks


#4

Thanks for the info on the iPad. We were able to reproduce the issue and have a fix implemented. It should hit our production environment early next week.


#5

Losant rocks! Thank you


#6

I’m not seeing any improvement with the IPad rendering. Further, on the 1920x1200 monitor … my dashboard layout has the entire right side as blank space. Yet when I try to contract the size of the browser tab by pulling the right margin towards the left, my dashboard components on the left immediate start to compress instead of just reducing the blank space.


#7

You are still seeing the gauges on gauge blocks pushed up above the top of the block on the your ipad?

Also, for your 1920x1200, could you put in a screenshot and let us know what browser you are using? We regularly run Losant dashboards on monitors of that resolution or higher and don’t see that - dashboards should always expand to fit the width of the browser.


#8

Full size display …

Right edge pulled to left …

Firefox 64 (64 bit)


#9

I just checked your dashboard, and the issue appears to be that you simply have the blocks set to these sizes. The dashboard is an 8-column layout and each block can be resized to take up a width of 1 to 8 columns, and 1 to infinite columns of height. You can grab the bottom right handle of a block and resize it to take up more space - or grab the drag handle in the top left corner to move the block to a different spot on the dashboard.

Or am I misreading this completely here? Have you previously laid out your dashboard as you want it - taking up the full screen width - and something is causing it to snap back to this half-width layout? Or is there some alternative layout you’re looking for when viewed on an iPad? (I see all your other dashboards are similarly sized to take up half the screen width.)


#10

IMO when I pull the right side of the dashboard towards the left (reducing the size of the browser window), the dashboard should not be compressing the left side blocks until the right side “white space” has been exhausted.

In general, I am finding the dashboard rendering issues very frustrating.


#11

This is not a rendering issue, this is the intentional behavior of the dashboard. You have defined your blocks to only take up the first few columns, and so the dashboard is obeying that.


#12

Please confirm … no matter how the browser window is sized, it will always attempt to display 8 columns (even if some number of columns to the right contain no block content)?


#13

On mobile screen size, it becomes a single column of blocks. Above those sizes, the dashboard always maintains the exact block placements and column layout that you have defined. So if you have defined all the blocks to only use the first 1 or 2 columns, yes, the right half of the screen will remain blank - because the dashboard assumes you meant it to be blank.


#14

Operating as designed … I don’t agree but OK understood.

This is all rooted in my original problem statement … a consistent look between the monitor and the IPad held in landscape orientation. AFAIK a fix was introduced, but I see no difference lately.

Thank you for your patience with my issues.


#15

So with the ipad issue, you are still seeing the gauges rendering incorrectly? shifted up and getting cut off at the top of the block?


#16

I think there’s a relatively simple feature request in here that would get you close to what you’re looking for: a “maximum width” defined on the dashboard layout. So by default the maximum width for the layout is “auto”, which means the grid containing the blocks stretches to fit the width of whatever screen you’re looking at.

But you as the dashboard owner can define a maximum width (let’s call it 1200px in this case) where, on larger screens (such as your 2000px-wide cinema display) the grid takes up only 1200px in the middle of the screen and is surrounded by white space on the left and right. On smaller screens (such as your landscape iPad at 1024px wide), the layout takes up the full width and the blocks compress as little as possible to fit within the smaller view.

Does that make sense?


#17

The IPad gauges are no longer being clipped at the top, but the IPad is still compressing the blocks as in the screenshot I posted above. Given their screen resolutions … why are not the monitor and IPad displaying identical content?


#18

Assuming a left to right column labeling of 1…8.

If my dashboard is layed-out to only occupy columns 1…3, I do not understand why any block compression should occur until I’ve pulled the right edge into column 3.

But again, my macro issue is duplicating the monitor and IPad landscape display.


#19

Assuming a left to right column labeling of 1…8.

If my dashboard is layed-out to only occupy columns 1…3, I do not understand why any block compression should occur until I’ve pulled the right edge into column 3.

Each column is always 1/8th of the width. For example, at 2000px, each column is given 250px, while at 1000px, each column is given 125px. Even if the column is blank, we assume you meant for it to be blank, and maintain those blank columns.


#20

Understood, operating as designed. Don’t agree, not my main issue.

My macro issue is duplicating the monitor and IPad landscape display.