Mobile screen sizes - another naive question

[Alex Tweedly]

On 27/04/2020 21:29, Richard Gaskin via use-livecode wrote:
>
> I've been itching to write a tutorial on using specific object 
> placement ("Responsive Design", as the kids call it) to compliment the 
> Lesson we've had for years on the other mobile layout option, 
> FullScreenMode.
>
> I had a few minutes over the weekend, and a discussion with a new 
> developer prompted me to craft a simple example of how groups can be 
> used to handle common design patterns with little code.
>
> This may be fleshed out more fully in the future, but for now at least 
> it's more than the zero tutorials we've had on it thus far:
>
> https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927
>
Interesting, and as you say, a good start can be made easily. But it has 
many built-in assumption that may come back to bite you ....

> on resizeControl -- Allow the user to enjoy whichever orientation -- 
> they prefer with responsive design: -- put item 1 of the loc of me 
> into tMidX put item 2 of the loc of me into tMidY -- if the width of 
> this cd < the height of this cd then -- Portrait: set the loc of grp 
> "UserInfo" to \ tMidX, tMidY - (the formattedHeight of grp "UserInfo" 
> div 2) set the loc of grp "MembershipInfo" to \ tMidX, tMidY + (the 
> formattedHeight of grp "MembershipInfo" div 2) else -- Landscape: set 
> the loc of grp "UserInfo" to \ tMidX - (the formattedWidth of grp 
> "UserInfo" div 2), tMidY set the loc of grp "MembershipInfo" to \ 
> tMidX + (the formattedWidth of grp "MembershipInfo" div 2), tMidY end 
> if -- end resizeControl
In Portrait mode, this assumes that the two groups are the same height 
(or nearly so). If they're not, one or other of them will finish up 
bumping against the top (or bottom) of the card.

Similarly, in Landscape, it assumes they are same-ish width, otherwise 
one of them will stick out the side.
*AND* it assumes they are the same height, otherwise the tops will be 
mis-aligned and potentially ugly.
( you could add lines like
put the min(top of grp "MembershipInfo", the top of grp "Userinfo") into 
temp if temp < the top of me + 10 then put the top of me + 10 into temp 
set the top of grp "MembershipInfo" to temp set the top of grp 
"UserInfo" to temp

to the end of the Landscape case).

And there are other assumptions

1. the fields are sized suitable to fit in the width of the narrowest 
device. If a narrow device is small enough, maybe the labels should 
slide around to above its field, rather than be beside it.

2. assumes that you don't want to widen the fields on not-very-narrow 
devices - whether stretching the fields, or increasing spacing between them.

3. In landscape, there may well not be enough width to allow the two 
groups side-by-side (say, on a phone), and you would really prefer to 
have the stacked vertically, even though in Landscape.

4. (perhaps the hardest) if you have text areas (i.e. multi-line 
fields), how do you decide whether to expand vertically depending on the 
height of the card, versus simply allowing vertical scroll bars within 
the field.


In summary - I absolutely agree that LC has everything needed to provide 
responsive layouts, and that with even a modicum of effort (which might 
seem tedious the first few times :-), it can produce layouts which are 
MUCH more responsive than a typical web page/app. But there is a danger 
of thinking it is too easy, and producing semi-responsive designs which 
are not quite good enough.

Things that would help:

1. either a widget or a compound-control for labelled field which wold 
allow the encapsulation for the sizing options for label+field; and 
would allow for labelling above or beside the field depending on 
context, space available and kind of field.

And there are others -library functions or behaviours that will help 
with the common cases - more thought on that tomorrow.

Alex.

.