Device versus window size for UI elements

[iBelieve]

Should UI elements be sized based on the device type or the size of the window?

For example, are the tabs layed out in phone mode only if the device is a phone, or also if the window is phone-sized on a desktop?

Depending on what we decide to do, we may need to think through how we're going to base UI elements on the window size in a clean way that also works for pure QtQuick.Controls apps.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[andresmanz]

To be honest, I don't really know how this is on Android. Is it device-dependent? When changing to portrait orientation, tabs in some apps on my tablet at least seem to look like those on a phone.

Personally, I would prefer UI elements to be depending on the window size. Being able to test different screen sizes without having to run the app on an actual mobile device (or emulator) is just very convenient. Besides that, desktop apps with small windows could benefit from this feature, too.

[marco-piccolino]

It seems that this is somehow left underspecified in the specs.
Probably most desktop apps should have clear minimum, maximum and preferred size, and then follow the platform-specific guidance for desktop. In cases where there should be no clear minimum size (any examples tho?) I'd set sensible breakpoints, tie those to device types, and use device-specific ui structure guidance.
Could the Polymer implementation offer any useful guidance in this respect? I'm not sure how much thought about this aspect has been poured into it.

[marco-piccolino]

https://www.polymer-project.org/0.5/components/paper-calculator/demo.html

[marco-piccolino]

from the specs: "On tablet and desktop, factors such as screen size, orientation, and the number of sections will determine if tabs should be full bleed or fixed along the left, center, or right."

http://www.google.com/design/spec/patterns/app-structure.html#app-structure-top-level-navigation-strategies

[marco-piccolino]

after I/O 2015, there is some more guidance on this: https://www.google.com/design/spec/layout/adaptive-ui.html#adaptive-ui-breakpoints

[marco-piccolino]

Now that Google Design have elaborated more about adaptive behaviour, I think the first step towards a strategy is to incorporate the concept of breakpoints into the framework.

One way to achieve this would be to add an object to the Units singleton (or create a new singleton called Adaptive) which contains information about each breakpoint so that this is available to components:

property var breakpoints: {
        // small handset portait
        0: { minWidth:0, window:'xsmall', columns:4, gutter:16 },
        // medium handset portrait
        360: { minWidth:360, window:'xsmall', columns:4, gutter:16 },
        // large handset portrait
        400: { minWidth:400, window:'xsmall', columns:4, gutter:16 },
        // large handset portrait; small handset landscape
        480: { minWidth:480, window:'xsmall', columns:4, gutter:16 },
        // small tablet portait; medium handset landscape
        600: { minWidth:600, window:'small', columns:8, gutter:16 },
        // large tablet portait; large handset landscape
        720: { minWidth:720, window:'small', columns:8, gutter:16 },
        // large tablet portrait; large handset landscape
        840: { minWidth:840, window:'small', columns:12, gutter:16 },
        // small tablet landscape
        960: { minWidth:960, window:'small', columns:12, gutter:24 },
        // large tablet landscape
        1024: { minWidth:1024, window:'medium', columns:12, gutter:24 },
        // large tablet landscape
        1280: { minWidth:1280, window:'medium', columns:12, gutter:24 },
        1440: { minWidth:1440, window:'large', columns:12, gutter:24 },
        1600: { minWidth:1600, window:'large', columns:12, gutter:24 },
        1920: { minWidth:1920, window:'xlarge', columns:12, gutter:24 }
    }