fullscreenmode and rect of a substack on mobile device ?

[Richard Gaskin]

J. Landman Gay wrote:

 > Auto-resizing does require an awareness during initial layout of how
 > fullscreenMode works. The objections you've raised can all be dealt
 > with if you're a stickler for HIG (which even the companies who
 > publish them don't follow. They're just guidelines.)

Of course. But beneath the niggly dictates of the HIGs are some 
fundamental principles worth considering.  Nothing as onerous as 
skinning details, just basics like making sure text is readable, buttons 
tappable, and, when practical, that an app looks and behaves in ways 
that blend well with the rest of the user's experience.

Please let me clarify, as I have in every discussion of this topic, that 
I fully recognize FSM exists for a reason, and there are cases where 
it's a good choice.

Despite the ardent back-and-forth here and in related discussions, I've 
never seen any disagreement at all on the applicability of one resizing 
method over another as it relates to a specific layout.

This discussion of Swami's app is a good example:  based on your 
previous description of the particulars of his layout, I'd already 
written that FSM may be a good fit for that.

As with anything in software design, it helps to stand on the shoulders 
of those before us:

When we want to make an app, look at other apps of its kind and do that.

If there's any caution at all merited for FSM, it's simply that as 
useful as it, when we look at the apps we have on our devices we see 
that the stretch-or-gap method FSM provides is less common than specific 
control placement.

Of course "less common" does not mean "non-existent".  I keep supporting 
use of FSM in cases like Monument Valley because it's a gorgeous and 
successful app, and uses exactly what FSM offers quite easily.

But if one is making other types of apps, use the methods those apps use.


 >> We're scripters; we generally enjoy scripting. But reasons I
 >> don't yet understand, writing the relatively small part of the code
 >> to deliver a precise UI annoys people to the point of spending a
 >> multiple of the time the task requires trying to find ways of
 >> avoiding the task.
 >
 > In my experience this is exactly backwards, maybe because we develop
 > different types of apps.

"Yes!", "Bingo!", "Hallelujah!", and every other enthusiastic 
affirmative I can find. :)

That's the thing:  Not all apps are the same.

To say one must always use one method over another without regard for 
the specifics of the app would be as ineffectual as requiring a raincoat 
every time you leave the house regardless what season it is.

The two methods are as different as sandals and galoshes.  They're so 
different there's usually no question at all when we would choose one 
over another.


 > Tell you what. Let's have one of our friendly chats some time and I'll
 > will either convince you or hit you over the head with my goody bag at
 > the next conference. :P

I always enjoy talking with you and you're always welcome to call.  But 
given that you and I have never disagreed on the applicability of one 
resizing method over another for a given layout, I would imagine that 
part of the conversation would be very short.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com