Is Web designer's screen-res short-axis test a red herring?

OK, I’ve mucked about in the Web designer long enough to realize its warning about DPI/resolution may be unwarranted, or at least unsuited to certain otherwise manageable situations.

As we discussed last night, the browser app checks for “shortest dimension” of available screen area (full screen - browser trim - taskbars, etc.) and takes a powder if the result comes out < 500 pixels.

Yet after maximizing my screen to get it over that hurdle, the app works perfectly flawlessly, and happily creates my multi-room dash as if nothing were amiss.

My question: Should the F11 button in Chrome wield such awesome power? Does the 5x8 scrollable grid of the resulting auto-created Dash tell us nothing about the true viability of my immense 55" LCD monitor as a proper GUI?

After all, the tiles arrive arranged in a tall column – namely in column 1, with columns 2-5 essentially unused – so I wind up having to scrollll (or is it drag?) doooown to collect them all up when rearranging. Heck, I even forgot one of them was waaaaaay down there unseen!

tl;dr It winds up working perfectly either way, why block progress at startup?

UPDATE: This post prompted me to revisit my Windows screen resolution. I bumped it up to its “(Recommended)” size. And was truly surprised when everything looked … more or less the same afterward!
Rendering my entire hypothesis moot.

Because if you wish to use a small screen device with hubiVue, use the app not the web. The web wasn’t / isn’t the first class citizen on the device as far as hubiVue is concerned. If things don’t fit or render correctly because the browser (trim, menu bar etc) robs pixels for itself, then why am I trying to fix that?

So, the rational was, if you have a small screen on a device and want to run hubiVue, then use the native app, not the web app !!

See UPDATE to OP, above. You were right. I was wrong.

GS 4 LS 0

P.S. Even at the higher resolution, app still balks, LOL. Wow.

1 Like