Auto scaled apps and placement

Hello David,

As we told yesterday, I have tried to compute some questions about the auto scaled apps and hope not to have missed some. For that I have mixed constraints values and not ; trying to mimic the reality. The demo app source code is here : demo_placement.zip

The demo app is alive here
The screenshots can be seen here. They are screenshots taken from the Debugger and two taken from a random Android device (Lenovo K33a48 1920x1080 440 dpi)

The original app looks like this

What I noticed :
- when rotating the device (for ex: Debugger_2_480x320.png) the first label (green) overlaps the second one)
- even if a label is put in a container with a select control, it doesn't keep its alignement (for ex: Debugger_2_480x320.png)
- on a real device (Android 6.0.1 using Chrome), the first label is under the browser's search/url field (for ex: Real_device_1.png)
- the font size in a Select control or an Input field is not kept consistent in some resolutions (for ex: Debugger_5_640x360.png & Debugger_6_1024x768.png)
- the space width between a not fixed size button and a fixed sized button (blue buttons at the end of the screen) curiously varies not depending ont the resolution (ex differences between Debugger_5_640x360.png (which seems correct because the width is the double of the original one it was developed on) and Real_device_2.png (which looks like the original layout but is 1080 px width)
- the width of buttons seems not to be consistent too. For example, "Button4" ends before "Button button with max-width" (for ex: Debugger_4_412x732.png) or ends after (for ex: Debugger_5_640x360.png but not Real_device_2.png)

Of course, this message needs not urgent reply. It is only because we discussed it yesterday. And I did not forgot that responsiveness is something difficult to achieve too.
So this is a report as we discussed. :)

Hello Samuel,

Thanks very much for this well explained post. I will try to answer you step by step according to my knowledge, but probably we can continue discussing here about. Then go on!

- when rotating the device (for ex: Debugger_2_480x320.png) the first label (green) overlaps the second one)

Maybe the rotation of a device is one of the more difficult "scale" issues that we can find, because, certainly the screen is not only reduced, but completely "streched". What we can do about? We can try various possible approach, depending on our apps requeriments, for example:

1º We can simply avoid the "landscape" mode. This is perfectly possible and commonly used by the applications in mobile platforms. We have the appropiate app's Cordova option in order to fix the application in portrait mode.

2º Since we can know what mode is used in the app (portrait or landscape, with the global app's variable "App.Orientation") and also the app's Orientation event, we can try, for example, to hide some elements or customize their sizes, etc., depending on the orientation.

3º We can also try to design from scratch testing againts both portrait and landscape, so, probably we place the elements in a way in which they are more or less affordables in both modes. In other words, if we design only for portrait... probably the landscape mode produces some unexpected (in portrait) result. The App Builder's debugger offers the way to change between the orientation modes, so we can easily take a look at them.

- even if a label is put in a container with a select control, it doesn't keep its alignement (for ex: Debugger_2_480x320.png)

I am not quite sure what to say, because, in my opinion probably the container are not required at all. Maybe we can use a Label, or an Html control, without any container, and positioning it using another possible approach, if the "inline one" do not work as expected. First of all, maybe this point is related with the latest one, so, we can perform some adjust to the controls taking in care (from the scratch) the portrait and landscape modes.

Secondly, maybe we can follow another possible approach, for example, place the label up to the Select control, not at their side. Maybe even provide a default value for the Select control, which can be shown at the beginning, but only used to indicate to the user for what the Select control is intented. Anyway in my opinion this point is not exactly the same than the first one, in which we deal with some general considerations.

- on a real device (Android 6.0.1 using Chrome), the first label is under the browser's search/url field (for ex: Real_device_1.png)

Certainly this appear to be a problem specifically related with Chrome for mobile. This problem occur in any other application, so, I will investigate how to solve it. Thanks for the information Samuel.

- the font size in a Select control or an Input field is not kept consistent in some resolutions (for ex: Debugger_5_640x360.png & Debugger_6_1024x768.png)

This is a quite rare issue, according to your screenshots. Maybe I appear too stupid, but, maybe you decrease the font size in that browser in particular? In which browser you get the "reduced" font size? I never view this before...

- the space width between a not fixed size button and a fixed sized button (blue buttons at the end of the screen) curiously varies not depending ont the resolution (ex differences between Debugger_5_640x360.png (which seems correct because the width is the double of the original one it was developed on) and Real_device_2.png (which looks like the original layout but is 1080 px width)

- the width of buttons seems not to be consistent too. For example, "Button4" ends before "Button button with max-width" (for ex: Debugger_4_412x732.png) or ends after (for ex: Debugger_5_640x360.png but not Real_device_2.png)

I am not sure if undersstand, because, I can see the buttons you are using have some of their CSS properties like "max-width" established... So I can't figure exactly what you wanted exactly, sir, sorry so much. Are you try without "max-width"? What you wanted to use the "max-width"? Why the buttons inside a Container?

Some other possible considerations

In my experience, if we want that our applications uses all the screen, in larger screens, we must limit the size of the application, just like I do in the Calculator sample. In this way, the controls scaled very well, until they appear "too big", in which we "stop" the scalation of the application, so, certainly the application do not fill all the available screen, however, they looks better.

Maybe it's not a good idea to use all the available space of the application size, that is, something like I use in the App Builder samples: I let some pixels at the borders. We can consider to use some of the Bootstrap CSS 3 classes related with the "responsive utilities", so we can show or hide controls depending on some screen sizes. Another way to do the same is to deal with the app's Orientation and Resize events and global variables like "App.InnerWidth", "App.InnerHeight" and "App.Orientation".

Design thinking on small screens can be good in most situations. This means, for example, do not place too much controls in the same app's view. If we need too much controls in an app's view and have scaled problems... maybe this can be reduced by separating some of the controls in another app's view: there is no limits in the number of app's view, so, we can prepare any number of them to place any controls we need, instead of placing too much in the same app's view.

Finally...

I will take a look at the Chrome for mobile issue, since the problem do not appear in other browsers like Firefox for mobile... I think App Builder must incorporate a fix for this, so we no need to worry about, but I will to investigate about in order to find the appropiate solution.

@svanneste: I believe David has given tips on how to carryout Auto scaled on our apps. e.g Calculator sample project.

However, have it mind that all browsers render scalling differently no matter how you pop in CSSs. But you can use coventional standard scale for objects on mobile.

Hello to all,

However, have it mind that all browsers render scalling differently no matter how you pop in CSSs. But you can use coventional standard scale for objects on mobile.

In principle we use stándar HTML5 and CSS, and then, every modern browser must shown our work in a very very similar way. So maybe I missing something because I am not sure if understand well what you means by "scalling differently". What we must asume is a smaller screen can't be appear exactly in the same aspect in very larger screen except if we use a "fixed" style.

By fortune App Builder offer to us the ability to change between fixed and scaled styles in runtime, determine the size of the application (using some max size for larger screens like in the Calculator sample), events like Orientation, Resize, and, actions like "SetStyle" and "SetViewSize", among the ability to use also pure Javascript and any kind of CSS in order to achieve our desired results.

Hello to all,

However, have it mind that all browsers render scalling differently no matter how you pop in CSSs. But you can use coventional standard scale for objects on mobile.

In principle we use stándar HTML5 and CSS, and then, every modern browser must shown our work in a very very similar way. So maybe I missing something because I am not sure if understand well what you means by "scalling differently". What we must asume is a smaller screen can't be appear exactly in the same aspect in very larger screen except if we use a "fixed" style.

By fortune App Builder offer to us the ability to change between fixed and scaled styles in runtime, determine the size of the application (using some max size for larger screens like in the Calculator sample), events like Orientation, Resize, and, actions like "SetStyle" and "SetViewSize", among the ability to use also pure Javascript and any kind of CSS in order to achieve our desired results.

It is same thing we are talking about.

What I met about scaling is how browsers render differently.

Hello to all,

What I met about scaling is how browsers render differently.

Can you provide a sample? If you take the Calculator sample, can you provide me a sample of browsers that render it differently? Because that's the point. Since we are dealing with HTML and CSS, in principle, every modern browser (mobile or desktop) must show our applications in the same way.

Hello to all,

What I met about scaling is how browsers render differently.

Can you provide a sample? For example, if you take the Calculator sample, can you provide me a sample of browsers that render it differently?

At the moment there is no issue calculator sample on three major browsers (FF, Chrome and IE).

Perharps, we can still keep an eyes on other components.

Hello to all,

At the moment there is no issue calculator sample on three major browsers (FF, Chrome and IE).

Perharps, we can still keep an eyes on other components.

No matter what component we use, we are always talking about HTML and CSS. So not only the mentioned browsers but Opera, Microsoft Edge, the browsers mobile versions, etc., must shown the app in the same way. If, for example, something is wrong with a browser (see in this thread the Chrome for mobile issue) then we find a bug that must be fixed.

But the Chrome for mobile issue do not means the browser render the app in other way... it's just that, for some reason (I continue investigating about) their behaviour (not the apparence) is different and not what we expected. If we use exactly the same application in other browser like Firefox for mobile, everything works like expected.

So we find here an specific issue with an specific browser that must be fixed, but, again, due to the nature of our applications, every modern browser must render our applications in the same way.

Hello to all,

At the moment there is no issue calculator sample on three major browsers (FF, Chrome and IE).

Perharps, we can still keep an eyes on other components.

No matter what component we use, we are always talking about HTML and CSS. So not only the mentioned browsers but Opera, Microsoft Edge, the browsers mobile versions, etc., must shown the app in the same way. If, for example, something is wrong with a browser (see in this thread the Chrome for mobile issue) then we find a bug that must be fixed.

But the Chrome for mobile issue do not means the browser render the app in other way... it's just that, for some reason (I continue investigating about) their behaviour (not the apparence) is different and not what we expected. If we use exactly the same application in other browser like Firefox for mobile, everything works like expected.

So we find here an specific issue with an specific browser that must be fixed, but, again, due to the nature of our applications, every modern browser must render our applications in the same way.

Great! You sound confident in your statement, without doubt this one of the reason I like your products.

Thanks