3D Dialogue Box Layout
======================

William Stoye, Neil Kelleher

Introduction
------------

This note gives some rules for dialogue box layout in RISC OS. They attempt
to describe an evolving understanding about how best to lay out dialogue
boxes. The assume the features of RISC OS 3.1, but go further than it as
follows:

  (1) Many developers want to use 3D. Although RISC OS 3.10 does not use 3D,
      it makes certain very important moves towards it. Laying out a
      dialogue box for 3D, however, may not be identical to its layout
      for 2D. In the future RISC OS is likely to go entirely 3D.

  (2) In the future, RISC OS will move towards using proportional fonts
      in menus and dialogue boxes, instead of the system font. This has
      various consequences for the layout of dialogue boxes. It needs
      changes to the window manager beyond what is in RISC OS 3.10, as
      supplied on this disc.

  (3) Most RISC OS machines have TV-resolution monitors. A growing
      proportion have VGA-resolution monitors. We assume that typical
      developers will not want to tune different sets of dialogue boxes
      for each.

  (4) Acorn is preparing a new Style Guide, with various recommendations
      which have evolved since the last one in what they propose. This
      document reflects those changes, rather than necessarily sticking
      to existing systems.

The intention of these recommendations is to provide a reasonable layout
for dialogue boxes, and to ease the burden for developers in covering the
considerations above. It is assumed that proportional fonts are not being
used by customers yet, but that they must be considered for the future.

Finally, we welcome comment of any form (through Acorn Technical Support)
on the usefulness, correctness, and completeness of this note.

And also finally, a good book to read when laying out dialogue boxes:
  "Graphic Design for Electronic Documents and User Interfaces",
  Aaron Marcus, ACM Press, Addison Wesley, ISBN 0-201-54364-8.

About 3D
--------

3D is added to the system by redefining the window furniture, by replacing
various wimp sprites for common items such as radio and option buttons, and
by defining appropriate border types for certain icons. It's typically not
possible to make a template that is either 3D or 2D by user choice, because
the 3D items in some cases are bigger, and so the overall dialogue box
layout can change.

If you wish to make your program work on both 3D and 2D, a CMOS bit has
been allocated to indicate which the user prefers. This is bit 0 of
byte &8C - if it is a 1 then be 3D, else 2D.

About Proportional Fonts
------------------------

When RISC OS uses proportional fonts the window manager will provide a
single font which it uses instead of the system font. The designer of
dialogue boxes has to assume a set of metrics to work with in laying out
dialogue boxes. The font currently proposed for this is Homerton.Medium at
12 point. This seems about the right size in VGA modes, and a hand-tuned 
version for TV modes exists, called Darwin.Medium, which has no grey pixels,
and is designed for legibility in such modes. In comparison with the system
font this occupies slightly more screen-space vertically, lower case letters
are slightly smaller horizontally, capitals are slightly larger horizontally.
Typically, strings show a slight decrease in width.

To make applications future-proof, try to design dialogue boxes so that they
work in either system font or a sensible selection of proportional fonts
(eg. Darwin, Homerton 12 - 12.75pt, Trinity 12 - 12.75pt.). It sometimes
needs some care with alignment - for instance, a label that describes an
item to its right should be a right-aligned text icon, rather than a
left-aligned (or horizontally centred, the default for !FormEd) one that is
precisely positioned. Note that the version of Darwin supplied with this
document (30/6/93) is still under development - its inter-character spacing
may change slightly in the future - so make a small allowance for this.

For titled boxes, rather than use a filled icon of a given size for the text
use the following: Set filled and border to false. Set Sprite to true then 
make the icon as large as the text might become under the target fonts. The
wimp will then calclulate (at run time) the actual size of the text,
irrespective of the icon size, and blank the area behind it. Prefixing and
suffixing the text with spaces will make a small border. This method will
work under all wimps (>= RISC OS 2.0).

About !FormEd
-------------

Dialogue boxes are usually prepared using !FormEd. In some ways this is
becoming an indadequate tool for the sort of use described here. We are
aware of this within Acorn, and intend to correct it in due course.

For templates to work on both resolutions it is vital to edit your templates
in a TV-resolution mode, checking them afterwards in a VGA mode. If you
place items vertically in a VGA mode you might locate them half-way up a
pixel in TV resolution, leading sometimes to quite surprising effects. You
can also create an icon whose height is not a whole number of TV-resolution
pixels. FormEd keeps everything to OS-Unit resolution, with the Wimp
rounding to pixels on the fly. This can lead to bizarre effects whereby a
window looks fine at one resolution, but there are off-by-1 errors in the
other.

Dialogue Box Windows
--------------------

Defining precisely which windows in an application are 'dialogue boxes' can
be very hard. In this document, I use to term to indicate a window in which
a dialogue occurs, ie. the user fills in fields and sets up parameters,
before pressing an 'OK' or other 'action' button to initiate some action.
During this dialogue, the user can press a 'Cancel' button which dismisses
the window, and means that no effect has occurred.

This definition excludes windows which are 'instant effect', ie. the setting
of controls has immediate consequences outside the window being filled in.
However, some of the dialogue box elements described later (action buttons,
display fields, sliders and so on) can also appear in non-dialogue windows.

Dialogue boxes come in two forms - menu dialogue boxes, and standalone
dialogue boxes.

Menu dialogue boxes

Menu dialogue boxes can be reached by sliding off a menu tree. They
disappear whenever the menu would disappear. They might also be reached
in other ways (ie. keyboard shortcuts), but their behaviour is identical.
They are typically small, and can be accepted by the user as 'part of the
menu tree'.

They have no 'close' or 'back' icons. If they can have any
effect (ie. not an Info box, which simply displays information) then they
grab the caret when they appear and have a 'default action button'.

Pressing RETURN at any point in the dialogue box is analagous to clicking on
this button (this is a change from the current most prevalent RISC OS
practice). They usually have a Cancel button, but need not if they are so
small that this would significantly affect the overall size of the box (eg.
a Save box). Filling in the fields in this box has no effect if Cancel is
then clicked, or ESCAPE pressed.

Standalone dialogue boxes

These appear when you choose a menu entry that ends in "...", or by some
equivalent action as appropriate. They have a back icon, but no close icon.
They have a default action button, and a Cancel button. If the Cancel button
is pressed then the dialogue box has no effect. Clicking outside the window
does not make it go away - indeed, the window stays until some action makes
it disappear.

What characterises a dialogue box (in this terminology) as against any other
window is that it is 'delayed effect' - a 'dialogue' happens before the
application acts on what you tell it. The Task Manager, for instance, does
not count because it is not 'delayed effect' - dragging bars on it has an
instant effect on the world, and no Cancel facility is provided.

Configure has some cases where dialogue box and instant-effect are subtly
mixed, which can leave the user confused as to what will happen. Typically,
anywhere where a writable icon appears that is not in a dialogue box, should
cause careful thought as to whether this control should really be reorganised.
The new Style Guide also says that writable icons hanging directly off menus
should not be used, and that a small dialogue box is preferable.

Dialogue boxes have a background window colour of 1. Small menu dialogue
boxes do not usually have a cream title bar when the have the caret, other
boxes do. This is because the cream title bar is to draw the eye, and it is
not likely to be necessary with a small, transient dialogue box.

Dialogue Box Elements
---------------------

The following element types are defined and described in this note:
  default action button
  action button
  label
  display field
  writable field
  adjuster buttons
  popup menu
  slider
  option button
  radio button
  group box
  scrolling pane
This covers most common cases. It is not intended to suggest that nothing
else may appear in a dialogue box, but this covers the majority of cases.

Vertical spacing
----------------

A dialogue box should be defined on a grid, with rigid rules for spacing between
elements, lines and so on. Without this the spacing of items within a box becomes
uneven, and unpleasing to the eye.

Pixels mentioned in this document assume TV-resolution pixels - 4 OS units
high, 2 OS units wide.

Vertically, typical elements consume space as follows:

The system font is 8 (TV resolution) pixels high, 1 below the text baseline,
7 above.

Homerton.Medium at 12 point is 9 pixels high - this allows two pixels
below the baseline.

Space should be allowed to allow accented capitals in Homerton to be 10
pixels high. However, in such a case it's acceptable for the accents to
touch descenders in the line above. Thus, the minimum spacing for lines of
text should be 10 pixels - 2 below the baseline, 8 above.

A clear pixel of vertical spacing should be left between lines of writing.
Boxed items should have two pixels of vertical space between them, in order
that the boxes are clearly visually separated.

Overall layout
--------------

It's not possible to be algorithmic, merely to try to work from good examples.

Size and shape: A good dialogue box should not seem overwhelming to the
user. It should not be absurdly tall or absurdly long. It should not cover
more than half the screen area of a mode 12 screen.

What if the dialogue is bigger than this? There are various solutions to
this problem, such as
  fold-out sections (Edit's 'find' box, PC Soft's setup box),
  scrolling panes of dialogue box controls
  a radio choice changing most of the box
  action buttons leading to nested sub-boxes.

The choice between these may vary according to circumstances. Of the four
methods mentioned above our belief is that the radio choice and the pop-up
sub-boxes are actually preferable to fold-outs and scrolling panes.
Of these two, a pop-up is more appropriate for levels of detail that are
not normally needed, and a radio choice more appropriate where there are
alternative presentations of the same data (eg. a colour selector).

Where the number of choices and settings is just big, it's hard to pick a
clear winner. Try to think what settings are most frequently used, or are
easiest to explain to a beginner. Place these at the top level, and put the
rest on sub-boxes. Try it on real users, and watch and listen carefully!
Be prepared to change if it doesn't seem to work.

Action buttons should be placed along the bottom. The default button should
be at the bottom right corner, and the Cancel button next to it. Either
stack the action buttons at the right/bottom, or space them out equally over
the edge that they occupy. In any dialogue box the items should be
approximately evenly balanced without large blank spaces, this might affect
the positioning of action buttons. Unless the size of wording prohibits it
the buttons should all be of the same width, rather than each one being
squeezed to precisely fit its text.

(If a layout is particularly difficult it may be acceptable to stack the
action buttons up the right hand side of the box, rather than along the
bottom. This might be particularly true of a wide dialogue box. The default
action button should still be at the bottom right, with Cancel next to it.)

Grouping, using a channel box with a label, allows related items to be
collected together. Do not put a group around a single item, simply label
it. Do not use nested groups.

default action button
---------------------

how to make it:      text icon, click button type,
                     foreground black, background grey (1),
                     v and h centred,
                     verify string "R6,3"
vertical size:       17 pixels,
                     and leave 8 OS units of spacing between boxed items
horizontal size:     enough for writing, plus at least 3 pixels either side, plus 6 pixels each side
                     Leave 8 OS units of spacing between boxed items
comments:            Try to word as an imperative verb, ie. "Print" rather than
                     OK, for easily understood concepts. But, use "OK" as a generic
                     if that's the best available (rather than "Go" or "Yes" or something).
                     Only one per dialogue box - hitting RETURN is equivalent to clicking here.
                     If possible, implement right-click here as 'do it, but do not remove
                     the dialogue box'. This is equivalent to doing the action, then re-opening
                     the dialogue box - ie. clicking Cancel just closes the box at this point.

NOTE - the click/drag button type is more convenient to edit with in FormEd,
BUT if your program talks to RISC_OSLib then they may not be recognised as
being action buttons. It is better to stick to the 'click' button type.

NOTE - if the dialogue box does not claim the caret then do not include a
default action button, simply use action buttons. It is usually more
friendly to claim the caret, however.

NOTE - see the note below about BorderUtils

action button
-------------

how to make it:      text icon, click button type,
                     foreground black, background grey(1),
                     verify string "R5,3"
vertical size:       13 pixels (3 below baseline, 10 above),
                     and leave 8 OS units of spacing between boxed items
horizontal size:     enough for writing, plus at least 3 pixels either side, plus 2 pixels each side
                     Leave 8 OS units of spacing between identical items
                     Make all action buttons in a matching set (eg. buttons at the bottom
                     of a dialogue box) of the same width.
comments:            As for default action button, but several are allowed on a box.
                     If this button leads to a further pop-up box, the text of this box
                     should end in "...".
                     The "Cancel" button is a button of this form.

NOTE - see the note above about the click/drag button type.

NOTE - the 'BorderUtils' problem. There is a fault in the Window Manager in
RISC OS 3.1, as follows. If a button is visually pressed in, and this leads
to the task or window that owns it being deleted, then a crash will occur.
The simplest way to solve this problem is that any button which can make the
task or window owning it quit, should be given a border type of "R1" instead
of "R5,3" - this will simply make it not move in when pressed. An
alterternative solution is the BorderUtils module, which solves the problem
in the Window Manager for the case of the task being deleted, but not for
the case of the window being deleted. BorderUtils is not needed for any
Window Manager later than the one in the RISC OS 3.10 ROM. Thus, it should
always be loaded using

  *RMEnsure BorderUtils 0 RMEnsure WindowManager 3.17 RMLoad ...BorderUtil

label
-----

how to make it:      text icon,
                     foreground black, background - don't fill
                     v centred, 12 pixels high (FormEd's creation default),
                     r justified if butting up to a feature at the right
vertical size:       9 pixels (7 above baseline, 2 below)
                     leave 1 pixel (above) between adjacent lines like this
                     If lines contain other items (e.g. writable fields) increase spacing
                     of the whole line.
horizontal size:     As required by string.
comments:            If a label for an item to the right then right-align, and do not terminate
                     the text with a colon - ie. say "Size" rather than "Size:".
                     Do not fill the background of this icon because if the background of the window
                     is textured (not possible yet on current window systems) then the background
                     of this icon may not be.
                     Note that the label that is part of a radio or option button is built
                     as part of the radio or option icon, rather than as described here.

display field
-------------

how to make it:      text icon,
                     foreground black (7), background grey (1),
                     valid string "R2"
vertical size:       13 pixels (3 below baseline, 10 above),
                     and leave 8 OS units of spacing between identical items
horizontal size:     enough for biggest likely writing, plus at least 3 pixels either side
                     Leave 8 OS units of spacing between boxed items
                     Leave 8 OS units of spacing between this and a related label
comments:            This is for an item which is filled in or computed in some way
                     at run time, such as an information display field. It is not
                     directly editable by the user, although changing other fields
                     may update its value.

writable field
--------------

how to make it:      text icon, writeable button type,
                     foreground black (7), background white (0),
                     valid string "Kat;Pptr_write"
vertical size:       13 pixels (3 below baseline, 10 above),
                     and leave 8 OS units of spacing between boxed items
horizontal size:     as for a default action button
comments:            RETURN should activate the default action button - a change
                     from the previous Style Guide. TAB and arrow keys move
                     between fields in the dialogue box. shift-TAB moves to the
                     previous field.

NOTE - the write/click/drag button type is easier to edit with, BUT leads to
problems concerning inserting the caret into a dialogue box automatically.
Sticking to the 'writable' button type is preferable.

If you have a large number of writable fields adjacent to each other, it may
be acceptable to immediately abut them vertically. For instance, the net
logon dialogue box does this, and it is acceptably clear. In such a case
they should all be of the same width.

The 'Kar' in the validation string handles movement between writable icons
using arrow keys etc. The new Style Guide specifies that RETURN in any
writable icon should activate the default action button. In RISC OS 3.10
'Kar' does not do this, but you should keep using this facility, and the
behaviour will be modified in a future version of the Window Manager.

adjuster buttons
----------------

These are a matched pair of arrow buttons which are used to increment or
decrement a numeric value - typically of a writable icon, a display icon or
a slider.

The sprites up, down, left and right are used to indicate these, but they
are used in a slightly different way to previously recommended use after
listening carefully to user feedback. Old templates should still look
comprehensible, but should be modified to the new format.

Note - some experiments were tried with the adjuster buttons being 'inside'
the slab-in of display and writable fields, but it doesn't seem to really
work well. One of the reasons for this is that it means they have to be
slightly smaller, particularly for the display field.

Here are instructions for up/down buttons.

how to make it:      two icons, up and down, placed adjacent to each other with
                     no clearance. 'down' is to the left of 'up'.
                     down     - text + sprite,
                                do not fill background,
                                just big enough to hold sprite,
                                button type auto-repeat,
                                border not set,
                                valid string "R5;sdown,pdown"
                     up       - text + sprite,
                                do not fill background,
                                just big enough to hold sprite,
                                button type auto-repeat,
                                border not set,
                                valid string "R5;sup,pup"
size:                the two sprites are each 32*32 OS-units.
position:            Position the adjuster buttons to the right of the item being controlled,
                     separated by 8 OS-units of clear space.

                     Align the item horizontally to match the display field box,
                     with their lower edge one pixel below the baseline of text.

                     Sometimes the buttons are either side of a horizontal line,
                     for instance in providing modification of the dimensions of
                     a square. In this case leave 8 OS-units between the line and
                     the arrow.

A left/right button pair is very similar to the up/down buttons in
appearance and operation. They are more rarely used, but are used for
adjustinging the value of a horizontal slider, or a setting represented by a
vertical line.

It is sometimes appropriate for a display or writable item to have a number
of units (or a percent sign) displayed after it, to show what is being
measured. In such a case the adjuster buttons should appear right next to the
item, with the units displayed (as a label) further to the right, separated
by 8 OS-units.

popup menu
----------

The symbol for these is chosen for a deliberate similarity to the submenu
pointer on a menu tree. Clicking either SELECT or MENU on it produces a
menu, in a position that relates to the arrow exactly as a submenu does to
the arrow on its parent menu. This is often used to fill in the value of a
display or writable field, from a selection of possible or probable values.
Pressing SELECT (unless writable) or MENU over the item being adjusted has a
similar effect.

how to make it:      A text+sprite icon
                     valid string 'R5;sgright,pgright;Pptr_menu',
                     button type click, border not set, do not fill background.
size:                The size of the sprite, 44 OS-units square
position:            To the right of the value affected, centred vertically.

(Aside: the name 'gright' is historical, the icon used to depict a grey
right-pointing arrow. The logical meaning, however, has always been
connected with pop-up menus and so the name is preserved.)

It is possible for a value to have both adjuster buttons and a pop-up menu. In
such a case the popup menu goes to the right of the adjuster buttons. Such a
case should be considered carefully, however - although it may seem most
ergonomic it leads to a somewhat cluttered appearance, and may be slightly
cluttered and 'fiddly' for the user (like a TV remote control with lots of
tiny mysterious buttons that never get used...)

slider
------

A slider is a visual representation of a value. Sliders can come in various
forms, depending on their use:
  input only, or input and output (by direct manipulation)
  approximate input only, or precision sometimes required
  a proportion being emphasised, or the actual value important
  appearing on its own, or as part of a large array of sliders

Sliders often represent spacial values, such as the two scroll bars on a
window - their physical orientation may thus be important. If great
precision is not required they can be made to look and behave like physical
controls (eg. a volume knob), which makes them easier for the user to
understand.

This document defines a simple, all-purpose slider appearance. However,
it does not attempt to exclude the usage of more complex sliders for
specialised purposes.

Horizontal and vertical forms of both sliders and bars are allowed.
Horizontal forms are more usual, unless the value being represented is
inherently vertical, or is perpendicular to a displayed horizontal value
(e.g. in a colour cube display).

Some sliders simply display a value, others allow the user to adjust the
value. A loose convention is that a red bar is an input and output device,
while a green one is an output only.

These instructions are for a horizontal thermometer-like slider. As a
general rule the choice between horizontal and vertical sliders is made on
their layout within the dialogue box. Usually horizontal sliders fit better
because writing is horizontal, and labels etc. can fit in better. Horizontal
sliders also give better accuracy on TV-resolution monitors.

how to make it:      The slider is constructed from three icons:
                     The well, the background, and the value.
                     They must have icon numbers in that order,
                     so that they stack correctly.
                     The well:
                       An icon with no text,
                       valid string "R2" (well),
                       don't fill background,
                       10 pixels high,
                       as long as the slider is to be.
                     The background:
                       An icon with white (0) background,
                       no border, no text,
                       4 pixels high,
                       10 pixels less wide than the well,
                       centred inside the well.
                     The value:
                       an icon with grey (5) background,
                       no border, no text,
                       4 pixels high,
                       vertically aligned with the background,
                       left end coincident with the left end of the background,
                       with a width that displays the value of the slider.

If the icon can be dragged by the user then a drag starting either on the
background icon, or on the value icon, should drag the edge of the value
icon to that point.

If great precision of input is required, add left/right adjuster buttons at the
right. It may also be appropriate to give a numeric display of the value,
but if a value has a slider, display or writable icon, adjuster buttons (AND a
pop-up menu?!) then the result will probably appear cluttered and
intimidating - there are no easy answers!

A vertical slider is made similarly, although TV pixels enforce slight
changes: the well is 18 pixels wide, the background and value are 8 pixels
wide, and the background is 6 pixels less tall than the well. The
positioning of adjuster buttons etc., if required, depends on the rest of
the dialogue box.

option button
-------------

This is used to turn a simple standalone choice on and off.

how to make it:      Use a text+sprite icon:
                     Create the icon, fill in the text,
                     turn off horizontal centring,
                     keep vertical centring,
                     click on 'sprite' too,
                     valid string 'soptoff,opton'
                     button type Release/drag,
                     turn off border,
                     foreground black (7), don't fill background
vertical size:       44 OS-units (reduce the sprite's height by one pixel,
                     in order to get the vertical alignment right)
horizontal size:     Ensure that the icon is long enough for the text.

radio button
------------

This is used to make a one-of-n choice, by having n radio buttons.
One of them should always be selected.

how to make it:      Each radio choice is a text+sprite icon:
                     Create the icon, fill in the text,
                     turn off horizontal centring,
                     keep vertical centring,
                     click on 'sprite' too,
                     valid string 'soptoff,opton'
                     button type Action,
                     ESG (Exclusive Selection Group) non-zero,
                     turn off border,
                     foreground black (7), don't fill background
vertical size:       44 OS-units (reduce the sprite's height by one pixel,
                     in order to get the vertical alignment right)
horizontal size:     Ensure that the icon is long enough for the text.

The button type 'Radio' leads to a slight mistake in behaviour, in that
ADJUST can lead to a situation in which no items are selected. This is
confusing for the user, and should really be regarded as a bug: you
should build the correct behaviour using action buttons, and simply
selecting the icon that is clicked. If a 'none selected' setting seems
a possibility then add another radio choice labelled 'none'.

group box
---------

A group box is for collecting together various items that relate to
a specific subject. It is easy to overuse them, but this can be
highly subjective. Do not put a group box around a single item,
or around all items in the dialogue box.

how to make it:      The group box consists of two icons,
                     the box itself and a label.
                     The box must have a lower icon number than the
                     label, and than any elements inside the box.
                     The box:
                       A large icon surrounding all the box contents,
                       no text,
                       indirection string "R4" (a channel)
                       don't fill background
                     The label:
                       a label item as described above,
                       positioned to overlay the top face of the box at the left,
                       leaving 16 pixels of the top face visible at the left,
                       foreground black (7), background grey (1).
                       
size:                Leave 8 pixels (or 4 vertically) clearance inside the box
                     and outside. This should be increased a little for very
                     large boxes.

scrolling pane
--------------

These are usually used to provide a choice from a large selection
of values. For this use, a pop-up menu is probably more appropriate,
as it provides a less cluttered appearance when the choice has been
made.

Another use is to pack a large dialogue box into a small space. This is
disliked by many users, and a dialogue box containing action buttons that
click to open 'nested' dialogue boxes is probably preferable See more
detailed comments earlier in this note about large dialogue boxes.

However, it can sometimes be appropriate to use a scrolling pane to a
dialogue box.

how to make it:      Use a real pane window, rather than creating
                     a dummy one with a faked scroll bar. This ensures
                     that the standard behaviour and appearance of the
                     window system is installed on this scroll bar.
                     Do not include a title bar.
                     Label the window using a simple label item,
                     without a group box around the window.
                     Allow some variation
                     in the precise size of the scroll bar, in case
                     a slightly unusual one is loaded.
size:                Whatever is appropriate. A scroll bar that is
                     very short, however, provides a quite cluttered
                     appearance.

Combinations and variations
---------------------------

The above items should be sufficient to construct the vast majority of
dialogue boxes. However, there are always special cases.

Use direct manipulation extensively. If setting the margins of a page,
let the user pick up the margins and move them around. If what is
being edited is visual, arrange the dialogue box to show this.

Use examples. Try to help the user to understand what he will get with
various combinations, and to include example displays as part of the
dialogue. For a colour selector, show what colour will result. For
a numeric format selector, show how numbers will appear or provide an
experimentation box.

Use pictures. Although above I have described labels as being textual, if
pictures can help then by all means use them. Beware of using pictures
alone, however - most usage of an icon on the desktop does not actually
require the user to 'understand' the icon, merely to make an association
with it. By using pictures alone it is easy to assume that the user
makes the same associations that you do for the picture.

Future work
-----------

The default action button, and the writable field, have quite a wide border
with quite a lot of associated visual clutter. This is copied from Motif,
but Windows uses rather less. The solution to this problem is to get
everyone to use what the Window Manager currently provides. If users find
this unacceptable we will change the Window Manager, or make the painting of
icons more configurable.

The visual feedback from action buttons is a point of contention. Some
believe they should jog down and to the right, rather than inverting. The
Wimp could be changed to do this, it does not affect templates. This might
even do away with the colour change.

The Mac and Windows use several different fonts in their dialogue boxes,
some of which are rather smaller than 12-point. This makes compatibility
with TV-resolution monitors harder. It also does not seem preferable for
those who use SVGA and higher resolutions on quite small video tubes,
a practice likely to increase as large video tubes are inherently expensive.
So, for the moment we stick with 12-point.
