Article Preview

FEATURE

An Elastic Window

Or, a different way to handle display resolutions

Issue: 5.1 (September/October 2006)
Author: Christian Miller
Author Bio: Christian Miller is the President of Pariahware, Inc., a software consulting and shareware developing firm founded in 2001.
Article Description: No description available.
Article Length (in bytes): 6,707
Starting Page Number: 34
Article Number: 5113
Related Web Link(s):

http://www.w3schools.com/browsers/browsers_stats.asp
http://www.pariahware.com/elasticwindow.php

Excerpt of article text...

As developers, we tend to crave screen real estate. We use large monitors and crank up the display resolution. Sometimes we forget that not everyone has this same craving, or the ability to feed it. Some 2006 statistics from w3schools.com show that 1024x768 is the most popular screen resolution, but 20% of computer users are still using 800x600, while 17% of users have a display size greater than 1024x768. Armed with the above knowledge, what is a GUI designer to do? There are two approaches one can take when designing an interface. Redesign the layout or leave potential users out in the cold. Many people have poor eyesight due to a disability or simply due to aging. Do you want to lose customers because they cannot read the text on your windows?

For example, say your window is designed with a size of 1024x768 but many of your users are using displays set to 800x600. Depending on your application, redesigning its layout can take hours. You'll spend time getting controls as close together as possible. If that alone does not work, perhaps you'll add dialog or sheet windows in order to compensate for the lack of space. I ran into this exact scenario a few years ago. When the company for which I worked started beta testing a product, we had numerous complaints regarding their windows being "chopped off." Which brings us to how the OS handles windows that are too large for the screen.

If our company had not cared about those with a lower resolution, we could have ignored them, as opposed to redesigning the user interface. Yes, our beta testers said that their windows were being "chopped off." You see, on the Windows operating system, if one launches an application and the designed window is too big for the screen, the window size is trimmed to the resolution of the display. All controls whose positions are larger than the screen are "lost." On the Macintosh, the entire window is displayed but the user needs to drag the window around the screen. However, if the window is too tall, the bottom of the window may not be accessible due to the Mac OS menu bar, because typically windows are not allowed to be above it.

Being a good developer, you have ensured that your window will display properly on lower resolutions. Good. Now how do you handle the smaller window on the larger screen? Everything looks smaller. Allowing people to resize the window is a common function. Typically, this is done using the very useful properties of the rect control class in REALbasic: LockLeft, LockTop, LockRight, and LockBottom. These properties, in case you are not familiar with them, allow a GUI designer to tell REALbasic, no matter what size the user resizes the window to, that a control should be "W" pixels from the left of the window, "X" pixels from the top of the window, "Y" pixels from the right of the window, and "Z" pixels from the bottom of the window. These properties suit their purpose, and we are all used to seeing their results in action (see figures 1 and 2). While locking controls is the most common way to allow a user to resize the designed interface, if implemented improperly, the window will have overlapping controls. Additionally, allowing windows to be resized in this standard method may not be aesthetically pleasing for your design implementation.

What if you would like your interface to look the way you designed it, no matter what the screen resolution of the end user? What if, when the user resized the window, the font size was increased, enabling the user to better see your interface? What if you create kiosk applications where large controls are the norm, but you cannot guarantee the screen size of the kiosks themselves?

I encourage you to consider a product put out by my company, which deals with the above issue, called Elastic Window. Elastic Window is simple to use. Just drag the Elastic Window folder into your project and set your window's super to ElasticWindow. When the user resizes the window, controls and, by default, fonts, will proportionately expand or contract to the whim of the user. See figures 3 and 4 for an example of what this looks like. Some may say that using Elastic Window does not conform to interface guidelines. However, kiosk applications typically do not follow guidelines and if your application is targeting those who are visually impaired, they would prefer see what they are doing, than worry about a button's height not being 20 pixels.

...End of Excerpt. Please purchase the magazine to read the full article.