Chapter 1
Screen Design for FRAME Entries
1.1 Overview 2
1.2 Widgets 2
1.2.1 The Types of Widgets 3
1.2.2 How Many Widgets Can Fit on a Screen? 5
1.2.3 Listboxes 5
1.2.4 Prompting Widgets 6
1.2.5 Objects from Other Applications 6
1.2.6 Popmenus 6
1.2.7 Modifying Objects at Run Time 7
1.2.8 Using the _FEEDBACK_ Method with Extended Text Entries 8
1.3 Screen Layout and Data Flow 13
1.3.1 Automatic Ending on Execution of Commands 13
1.3.2 Navigating Around Objects on FRAME Entries 18
1.3.3 Initial Field Placement 21
1.3.4 Insert Mode 22
1.3.5 Hidden,Grayed,and Swapped Out Fields 22
1.3.6 Placement of Action Widgets on the Screen 26
1.3.7 Tool Tips 30
1.4 Screen-Related Issues 39
1.4.1 The Size of Our Screens 39
1.4.2 Logos and Logo Placement 40
1.4.3 What is a Menu? 40
1.4.4 Fonts 41
1.4.5 Storing User Choices 42
1.5 Displaying Messages 43
1.5.1 Designing Systems to Avoid Error Conditions 43
1.5.2 Messages for Multiple Fields 44
1.5.3 Error Message Layout 45
1.5.4 Unmodified Fields 46
1.5.5 Difficulties with Error Processing and Screen Design 46
1.5.6 Informing Users about Long-Running Tasks 48
1.6 The HELPMODE Command 49
1.6.1 What is HELPMODE? 49
1.6.2 Starting HELPMODE 49
1.6.3 What If No Help is Available? 49
1.7 Summary 52
Revised Stanley Chapter 1 10/19/98 6:02 PM Page 1
1.1 Overview
This chapter presents some ideas for designing screens used with FRAME
applications.These ideas are a combination of tried and tested techniques,
my ideas and those of others that I have found work in practice.The code in
this chapter allows you to use a set of tools and ideas immediately in your
applications.
GUI development is different from the old menu-driven “select a number
and be branched off somewhere to fill out a couple of fields” system. A GUI
is not just a pretty face;it is also the first and often only thing that forms a
user’s opinion of a system.
Here is a statement worth considering when building a GUI screen:
O
Users don’t care what happens behind the scenes.They don’t
care about case tools,traditional structured programming,or
object-oriented techniques. As far as they are concerned,the
system is the GUI that they interact with.
Few developers are trained to develop screens that are ergonomic. We
know that if the user clicks a certain box,certain events must happen,and we
code those events with relish.How much thought do we put into whether
the user can easily use the screens we create? Who uses our systems,and
what right have we to dictate to the end user how their system interface will
look? When developing GUI applications in an organization,we should work
to accepted organization standards and involve users in determining the look
and feel of the screen.
1.2 Widgets
We can add extra widgets at run time by creating dynamic objects using the
CLASS class _NEW_ method. The ability to swap regions in and out also
allows additional widgets to be viewed in an application without having them
on screen (hidden,grayed, or visible). From Release 6.12 on,the TAB LAYOUT
object allows us to place practically any number of objects in a FRAME
without making the screen cluttered.
As GUI designers,we need to maximize visual impact as well as provide users
with a screen that suits their work habits and methodologies.If a user requires
many fields on a screen and regularly works with all that data, then we maxi-
mize the user’s ability to carry their job out by having all those fields on screen.
2 Solutions for Your GUI Applications Development
Revised Stanley Chapter 1 10/19/98 6:02 PM Page 2
If they regularly work with a few fields that are physically divorced from an
aspect of their job that uses other fields,then putting all the fields together
may be confusing.
There’s only one hard and fast rule. Get the users to help design (or com-
pletely design) the GUI. We are just here to make their job a bit easier,not
to impose our interpretations of how we think they work. At the very least,
create a prototype and have the user review it.
1
.2.
1
The Types of Widgets
An object class is a template like a push button. We create a region using the
mouse to drag out a rectangular box and fill it with a particular object class.
These regions are called widgets.
A widget is a type of object.The other type of object is called non-visible or
non-widget.Non-visible objects are not seen by the user and do their work
behind the scenes.These are not referred to as widgets.
Push buttons take a bit of extra space but are a fairly standard way of pre-
senting any sort of clickable selection.They can look at bit disjointed when
you have different sized ones together,consequently it’s not unusual to see
buttons of a standard size that contain varying amounts of white space.
Note that push buttons require an extra character on all sides of the visible
button.Don’t use push buttons to display non-clickable information.
Icons are considered more graphically pleasing because they include a picture.
You are limited in your selection of icons. You can define your own,but it is a
lengthy task and defeats the point of rapid applications development.Consult
“Creating User-Defined Icons to Use with the SAS System” in Observations
(Second Quarter 1994). You can only use SAS fonts with this object.
Text entries aren’t intended for command driving,however, you can associ-
ate a command that is executed when the field is modified with a text entry
object. You can make text entries look like buttons.I often use a border
around them,as the region is not always obvious,especially if the pad charac-
ter is blank.This object is irritating with its insistence on not permitting use
of the first and last apparent character position. You can only use SAS fonts
with this object.
Graphics text can be used just like text labels, but you can change the type
font to make them look nicer,and they are graphical rather than character.
You can also cram different lengths of text into the same size boxes.Try to
avoid this as it can look awful! You can only use SAS/GRAPH fonts for this
object class.
Chapter 1:Screen Design forFRAMEEntries
3
Revised Stanley Chapter 1 10/19/98 6:02 PM Page 3
SAS/GRAPH and IMAGE widgets let you use as small a region as you like
because the picture is scaled to fit.Be careful — you can display an unintelligi-
ble picture:something created at 640X480 and displayed at about 40X40 can’t
maintain all the information it started with.The more pictures you use,the
longer it will take for your application window to open and redraw. You can
use region attributes to make GRAPH and IMAGE widgets resemble a button.
Image objects maintain the picture better than GRSEGs,however,the image
will not necessarily fill the whole region if you use the KEEP ASPECT RATIO
attribute;if you don’t use that attribute, the image may be distorted.
Image icon is an image with text attached.It is different from an icon
because you can combine a picture with text. You can use operating system
fonts for the text.
Toolbars are a collection of images or text all under one region.I like using
these as I can define a whole set of buttons easily. Toolbars allow you to mix
text and graphics. You can use operating system fonts for the text.
Extended text entries are a graphical form of text entry.They accept char-
acters as input,but the object is inherently graphical,allowing it to be moved
on a pixel basis rather than a character basis.Extended text entries only
accept character input and can use operating system fonts rather than SAS
system fonts.This object is powerful in its ability to allow the entry of a char-
acter (without an ENTER) to be an event that drives a method called _FEED-
BACK_. You can have code running as the user types.For example, you could
ask the user to enter some text and have the _FEEDBACK_ method display
a listbox that displays only the records in a dataset that match the currently
entered text.
Input fields are a simple input mechanism.They are a composite widget,
utilizing an extended text entry for the actual data input.They offer the abili-
ty to use formatted input and display.
Composite widgets are a special type of widget that is based on multiple
classes. An example is the image icon,which is built from more than one
object class.If you use cursor tracking with composite widgets,you may need
to switch on the push button region attribute because the region may only
track on the border otherwise.
TAB LAYOUT objects arrived with Release 6.12.They have the inherent
ability to place many objects in a FRAME,while only displaying the ones on
the currently selected tab.I think this object should be used extensively;it
allows an application to group tasks simply and elegantly.
4 Solutions for Your GUI Applications Development
Revised Stanley Chapter 1 10/19/98 6:02 PM Page 4
1
.2.2 How Many Widgets Can Fit on a Screen?
FRAME entries make it easy to forget that we can call up other FRAME entries
to do additional tasks.Its easy to see some spare space and put another field in
it.Question whether the overall impact of the screen is improved by doing
that or whether calling another entry would be better. My experience is that
I often get carried away with the ability to get everything in one place,and I
have to go back and re-examine the screen when I run TESTAF on it.
However, with the TAB LAYOUT object my whole approach to screen design
has changed,and the cluttering that can result in FRAMES is minimized.
A related issue is the choice of which screen resolution to use during devel-
opment.Use the lowest common denominator. If your site has predominantly
640X480 screens with 16 colors,don’t develop at 1024X780 with 16 million
colors.640X480 with 256 colors is a good size. Be aware of and guided by
your client’s hardware.
Attachments are a feature of FRAME entries intended to give developers
control over the resizing of objects in relation to other objects and the
FRAME master region. You can use attachments to maximize your ability to
run an application on different screen sizes.
I find attachments work best when all your objects are graphic based. You
can resize a FRAME master region so that character-based objects disappear
off the edge of the FRAME because they cannot be shrunk beyond a certain
size. In particular with push buttons,you may find that graphic image icons
work better than attachments.
1
.2.3 Listboxes
Make extensive use of listboxes to aid users with data entry. Listboxes used
in this manner are often known as a component of data driven software
because, instead of making the user enter a value and possibly get it wrong,
the user is given a list of items to select from.
Remember that a LISTBOX object contains the entire set of listbox items in
the object.The listbox items exist in memory while the listbox exists. You can
quite easily run out of memory if you use listboxes that have a lot of items.
Don’t give users listboxes with so many items that they become counter-
productive. As a rule of thumb,I try to avoid using listboxes with more than
three to four screens of scrolling.
Chapter 1:Screen Design forFRAMEEntries
5
Revised Stanley Chapter 1 10/19/98 6:02 PM Page 5
