Enhancement / Best practice: "Zoomed" versions of SmartGWT skins

[Blama]

Hi Isomorphic,

could you suggest what is the best approach for a "zoomed" version of the showcase and in general a SmartGWT application?

With display DPIs getting higher and higher your default skins become very small.
As you already suggest one should not use browser zoom.
My last problem showed that this might be true for system zoom as well.

So like a few years ago we might need "+" and "-" buttons in the web again (???) as the DPI-numbers get higher but you can't be sure this is always the case.

Could you create a larger version of your skins? At least for the low-image-count skins like Simplicity this is hopefully very easy. Or do you suggest an other approach?

Best regards,
Blama

[Isomorphic]

There's no problem with higher DPI, because a CSS pixel in not a device pixel (Google "css pixel definition" for details).

[Blama]

Hello Isomorphic,

I went to the Apple store today to take some screenshots of the online showcase on different machines.

I uploaded the screenshots here:

• showcase_Mac Pro Mac Pro 27in display (2560x1440)
• showcase_iMac Retina 5K (5120x2880) system zoom 2560x1440 (same content as above)(native/no zoom not even possible in system settings!)
• showcase_MacBook Pro Retina (2880x1800) system zoom to "more space" 3840x2400(!)
• showcase_MacBook Pro Retina (2880x1800)

As you can see the content differs from system to system, which is somehow expected.

Observations and questions:

1. The space in the "middle column" with the tiles is smaller in the 4th picture compared to the 3rd, even though they have the same aspect ratio (1.6 : 1).
   Can I conclude from this that the width of the left column is defined in pixel rather then in percentage values?
2. What is the recommended method for defining sizes? For example, in my application I have a window that I define in absolute terms (700px * 700px). This looks always the same in my different-resolution screenshots (which is what I want), but has a problem when connecting to an old VGA 1024x768 beamer: Because of the space used for browser UI and system taskbar, it is not possible to see the whole window, hiding important UI elements either in upper or lower areas of the window.

I'm pretty sure there is not the one best solution that fits all cases, but what is your best practice (considering an environment of 1280x1024 and above)?
When use percentage, when absolute values in the code? Any other tips?

Thank you & Best regards
Blama

[Blama]

PS: Thanks for the hint on CSS pixel, which I did not know. The learning for me is that "1 pixel" is no absolute value, but a relative one and that it is not possible to know the outcome beforehand, which is a bit annoying. From what I understood, one solution would be css @media queries, but these do not apply to SmartGWT.

Let's say one always would want the showcase to look like in the last of the four screenshots (five rows of tiles, "pretty big" tiles). How would one do that with different resolutions? Is it even possible?
I do not want that in my application, but what I want is a "not too big, not too small, just right" visualisation from 1280x1024 to 3840x2400 (very different resolutions, somehow different aspect ratios).

Best regards
Blama

[Isomorphic]

Identical appearance is a non-goal for both content and applications. People intentionally choose devices or configure devices for a DPI that suits them.

As covered previously, the CSS definition of pixel is defined in terms of DPI - basically in terms of human vision. If a device renders logical CSS pixels far too small or far too large, that's a broken device, and not one to try to compensate for with dynamic sizing (which usually would not be feasible anyway)

1. yes, it's pixel sized

2. this doesn't sound like a DPI issue but rather just use of space. Whether to use percents or fixed pixels depends on the type of content or functionality, and answering the question "how do I allocate space" is tantamount to a full training course in UI design. However, to give some quick examples, fixed pixels obviously make sense for fixed-sized media; they also make sense for something like a navigation bar where titles tend to be short, where any additional available space is probably best allocated to other elements.

[Blama]

Hi Isomorphic,

thank you for explaining.
This means that the value x, which would make a Widget "the full screen wide" in setWidth(x), differs from device to device and can also be smaller on a slightly bigger display/resolution. Good to know.
Do you know of a resource for device manufacturers telling them/us a recommended range for x, so that one can translate a given x in a percentage value range to get a feeling for the possible size while programming?

Also, browser zooming there for this exact reason, correct? If the user is not satisfied with the default logical size he or she can change it. If so, it is a pity that that area is scattered with browser bugs (FAQ).

I know that is not really a SmartGWT/SmartClient topic anymore, but I'm sure that it will help many users finding this thread via search. Do you think this would also be useful as entry in com.smartgwt.client.docs?

Best regards
Blama

[Isomorphic]

We actually now have limited support for browser zoom, with a long list of caveats. This will get better as browser vendors fix the severe bugs that still remain in this area.

As far as resources for figuring out how small or large your UI components might end up on different screens, there are a lot of sites out there that can help, like this one. We don't plan to jump in with another site along these lines.