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 readable?

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:  29.87%
1920x1080: 16.69%
1440x900:   6.86%
1600x900:   5.81%
1280x800:   5.14%
1024x768:   4.74%

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 window.

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.

 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 ambassa...@fourthworld.com                http://www.FourthWorld.com

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
> fit
> 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?
> Thanks,
> Peter Bogdanoff
> ArtsInteractive

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to