Mobile screen sizes - another naive question

[Richard Gaskin]

Very good thoughts there, Alex.

The assumptions you list would be important to keep in mind if one were 
aiming to generalize basic layout handling, with libraries that have 
nicely-designed APIs, or even further with virtual props that would lend 
themselves well to reducing things further to simple point-and-click 
authoring.

But in this exercise I'm making no assumptions at all; I'm just looking 
at the UI and writing purpose-built code to make it do what I want.

And with only a dozen lines, why not?

There's good value in generalizing app development.  Data binding is 
ripe with unexplored opportunities, as are field entry validation, 
window management, menu management, exception handling and reporting, 
socket comms, and many other things we write.

Sometimes we make tools or libraries to reduce the scripting we would 
use to deliver those.

Sometimes we generalize far enough to reduce it further to assigning the 
desired behavior with property settings which would then lend themselves 
to a point-and-click development workflow.

But often we just write a few lines of script to do what we want to do 
for the case at hand and be done with it.

The draft Lesson I posted serves only as a reminder that placing objects 
where we want them isn't all that deep, and if we use groups well we can 
reduce that scripting even farther.

That this wasn't clear in the writing suggests the draft is possibly too 
long.  "Set the loc of <object> to <loc>" doesn't really require a whole 
page.

Different apps require different code. Layout is the least of it. 
LiveCode is a scripting language.  We script.

And when we look at the apps we use from others, regardless what tool 
they're written in, we see those authors do the same thing: they look at 
their layout, consider what they want to communicate to the user, and 
put things where they want them to support that.

What I had tried to convey was that putting things where you want them 
is neither mysterious nor difficult in a nice language like LC.  Clearly 
I overwrote.

-- 
  Richard Gaskin
  Fourth World Systems



Alex Tweedly wrote:
> 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.
>