Hello Peter -
Scaling is tempting, but problematic.
Automating that with the stack's scaleFactor would be quick, but will
scale everything, even controls the user needs to interact with. If the
default size is good will they be usable at a smaller size? will text be
Hand-coding a more refined scaling can be done, but it's a bit of work.
It's been a while since I've seen your app, but from from what I recall
of your app's UI it should be possible to craft a scaling routine for
it, but it would not be trivial. Many decisions would have to be made
about minimum size for both readability and interaction.
Your item #2 noted 12" screens are just a bit small. That's actually
not a bad problem to have, because it's very close to the most popular
size, 11.6", which is also the smallest practical size most apps will
need to deal with (more on that below).
Moreover, most 12" screens sold in the last half-decade or so have the
same resolution as 11.6" screens, 1366x768, with just slightly larger
pixels. So for the purposes of UI layout, they're effectively the same.
1366x768 is so common that it may be both less work and more rewarding
in terms of market share to consider a refinement of your app's design
to make that resolution optimal first, and consider dynamic scaling or
other options later on.
If this impacts a lot of your content, you may consider looking at ways
to automate that once you've identified the common patterns needed to
accommodate the change.
A world of students using Macbook Airs and the most popular Windows
laptops will welcome your app optimized for 1366x768.
The exercise may also provide a good opportunity to consider options for
making good use of larger monitors without scaling both X and Y axes, or
scale each to optimize different content opportunities. For example,
with a timeline a longer X axis will let you see more time, while a
taller Y axis can offer more details about what's happening in a given
moment. Both can be useful, but neither is true "scaling" per se.
Many possibilities, but until the app has 1366x768 as its optimal size
it may be more difficult to decide best approaches for using the space
available on the fewer machines with larger screens.
Notes on minimal size for desktop layouts:
One of the risks of being a developer is that we often have better gear
than our users. Spending all day with our machines we may have more RAM
than they do on average, or faster CPUs, and often larger monitors. Now
and then this may tempt us to design for our own system, but it's
helpful to keep user specs in mind and design for those first.
If you haven't yet don't fret; at least you're in good company. I've
met some very well-placed UI designers who overlook the market stats on
monitor sizes. Indeed it was my own mistake in this area years ago that
has me checking resolution trends at least annually now.
With monitors, 1366x768 screens are by far the most common, the second
leading size only a bit more than half as popular, and it's a long tail
of single-digit market share from there:
1366x768 is most prevalent among small-and-light form factors, but can
be found in larger laptops in the 12" and 13" ranges, and once in a
while with older, bulkier 15" laptops.
Given the market share of 1366x768, desktop software should ideally have
their layouts optimized for that first, allowing resizing where
appropriate for other sizes.
Fortunately, the need to support anything smaller is so rare you may not
need to bother unless you're in a specialized niche where a specific
small screen size is uncommonly popular. The 4% using 1024x768 are
probably machines too old to be in your target market; the other 96%
will welcome your time spent on more relevant considerations.
So in practical terms, 1366x768 is not only the primary target for
today's layouts, but also the smallest you're likely to need to support.
That's helpful, as it's usually less of a problem to have more space
available than it is to have too little.
When designing for any size, keep in mind that in Mac most users will
have the Dock at the bottom of the screen, and most Windows users will
have their Task Bar there. Additionally, the menu bar will need to be
taken into account when designing for the actual content area of your
So while 768 is a good vertical minimum to target, between the Dock/Task
Bar, menus, and drag bar, actual usable size will be much smaller.
The Dock is the largest element, 64p by default in El Capitan. With a
menu bar height of 22p, and another 22p for the drag bar, the content
region of the window is normally only about 660p. Design your content
for that and you're golden.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Peter Bogdanoff wrote:
> I’m needing to allow the user resize a stack window using scaleFactor
> and am needing advice about interface.
> First of all, I see that some Livecoders are using scripts to scale
> controls and text when the user drags the stack size larger or
> smaller. In my case, there are too many controls and text layout is
> too sensitive, and I really don’t need the improvement in resolution
> to use that method. In my case:
> 1. Default size is good for most people
> 2. Some have 12” laptops that make the window just a tad too large to
> 3. Some have larger screens whereby they might want to expand the
> window to fill more space
> For the too-small issue, I can automatically scale the window at start
> up. However, how do I present the choice to the user to manually make
> the window larger/smaller?
> Clicking on the zoom box resizes the window, not scales it—no good. Is
> there a message that can be intercepted to scale instead of zoom?
> Do I otherwise (working with the stack with size locked) add drag
> controls to the edges of the window that scales when dragged? Does
> anyone have scripts for that?
> Or should this be some kind of preference item?
> Peter Bogdanoff
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription