I'm sure that approaches vary all across the spectrum on this one, so let me tell you what I use and let others relate what they use. Perhaps a consensus will emerge, perhaps not.
I design for the smallest screen I think is likely to be used so that all can use the Dbase effectively. I then use Get(Screenwidth) to see if it a widescreen and either adjust the zoom level or switch to another layout that has "extra" buttons on the side.
Note that I typically build only for in-house use, I am not a 'hire-out' developer (insert proper term here...I dunno...freelance?) and I have a pretty good feel for what size screens I'm working with. The "extra" buttons also add a little momentum for the folks with 6year old CRT monitors to request an upgrade...
I'm sure there are many, many other approaches...this is mine, quick and easy. I can't say I've spent much time thinking about what the optimal approach would be.
I designed my solution to work as low as 800X600, although since that is probably in the minority these days, I use 75% Zoom to accomplish this, allowing for better quality (100% Zoom) for pretty much all other scenarios.
On that note, it would have been nice to have smaller steps in the zoom rather than it suddenly using 50 increments, 25 all the way would have helped.
My solution is a vertical market solution (shrink wrapped / off the shelf) so it has to cater for as many configurations as possible. The introduction of dynamic resizing helped, but its not perfect, we could have done with more control with horizontal resizing, such as when you group 5 fields and resize them manually. If only that ability could be leveraged..
Due to this, to keep my solution looking at its best I have duplicated a number of the main layouts (but not all) so I have a standard aspect and a wide aspect which also make use of dynamic resizing.
75% of the screens cater for both
On startup, I check the screen size then set a variable such as $$aspect = "W"
During scripting / layout changing, I use go to layout [$$aspect & "-layoutname"]
Its extra work, but I feel its worth it, since FM9's release when we adopted this we have yet to have any complaints. Before hand, we used to fix the window size (via a plugin) but windows users like that maximise button, so a fixed window was not very welcomed.
Sizes I use are :
Standard = 994px wide X 640px height
Wide = 1230px wide X 640px height
Whilst there's not a great deal of difference, its enough to allow me to make things look in proportion, rather than having a single field stretch, I can resize most of them just enough.. but it also helps with various screen resolutions too.
Another thing I do, depending on the screens of course, is use a calculated repeating field to display data (not edit it) for example :
A calculated repeating field to display values from 4 different fields, displayed horizontally with auto resize containing the calculation
Get (CalculationRepetitionNumber) = 1 ; table1::Field1 ;
Get (CalculationRepetitionNumber) = 2 ; table1::Field2 ;
Get (CalculationRepetitionNumber) = 3 ; table1::Field3 ;
Get (CalculationRepetitionNumber) = 4 ; table1::Field4
This allows you to achieve otherwise impossible results for display purposes, whereas natively, only 1 field could resize horizontally, making it soon look rather strange, this allows as many fields as you want to resize horizontally, keeping a consistent look at any screen width. Of course, this only works if the fields are meant to be next to each other and are similar widths by default.
I have to thank John @ Seedcode for this one, it did not even cross my mind until I set my eyes on his new calendar solution which uses a similar technique and allows the entire calendar to stretch both ways.
You can use the get function get(applicationversion) for the script to determine what to do.
I too wish FM would create more zoom options - 25% increments up to 200% would be nice, with perhaps a 110/115% together with (say) an 85% for smaller adjustments. These, together with an opening script to set the size would do a lot of jobs nicely.
Although I'm new to FMP I have played with dynamic resizing which seems a bit of a mixed blessing. Works fine with horizontal resizing but in my experience trying to resize a portal in both directions upsets other design elements.
Like the idea of using a calculating field to display values together with auto resize containing the calculation. A neat trick which I would never have thought of.
Thanks for all the suggestions - plenty to think about.
Just another note on portals & dynamic resizing..
Theres two ways a portal can resize vertically.
1. If you anchor ALL of the fields / objects within the portal to the top the portal will increase the number of available rows
2. If you don't anchor ALL objects to the top (even if you anchor all but one to the top), the portal row height will expand, leaving the same number of rows