[AccessD] User interface

William Benson (VBACreations.Com) vbacreations at gmail.com
Sat Aug 27 15:10:03 CDT 2011


John,

I think what is really important is to make sure what you build is stable
and predictable, but doesn't act too clunky or invite the user to screw
themselves. You will humiliate them, and they will think it is your fault if
you make it too easy to make an error -- just as much as they will whine if
you make them go through too many confirmation steps.

I like to make data areas expand and move controls out of the way - so I
tend to group controls across the top and near the right, in rectangular
areas. I reposition things on resize.

I like command buttons to be of uniform size if possible, which is hard to
set when the captions change. So I use a process of putting a label on a
hidden form, throw all similar command button captions into it, get the max
width that causes, then use that value to adjust all the command buttons
from a certain area on the active form.

If the same unbound controls are required to be displayed to the user on
many separate forms so that those values are knows whatever the user is
doing -- and if they take a particularly long time to calculate -- I have
found it necessary to create a convenient means of calculating once, so they
can be shown in many spots. Those "calculations" involve recordset related
computations, for example - slow stuff, relatively speaking. Along the way I
came up with the idea of using a hidden form to keep a base set of controls,
which is always open, and then letting the control source of controls on
other forms be bound to those base controls. Honestly I don't know if that
has worked out well or not. It is certainly faster than keeping all
recalculation activity local to every form... but I do wonder if I might
have done just as well using public functions and global variables to hold
the recalculated information. 

When it comes to double-click event. As a programmer and power user, who can
fix anything that goes wrong in the tables - I love it. But as a user who
"accidentally" double-clicks the wrong record, item, control -- or didn't
mean to double-click at all, sometimes the programmer gets blamed for the
result of their spasmodic gestures. But if you mitigate this risk by making
them confirm their intentions, they get upset with that. So I tend to not
confirm deletions, but I require them to hit the button marked DELETE ...
and if there are more than one type of thing on a form which can be deleted,
I keep a separate delete button next to each control with data that can be
deleted.

One item I have not been too sure about and don't mind asking -- what do
people think of buttons with + or - as a caption. In a group of values I
would think that automatically means Add or Remove, but some users might
think it means expand and contract the list.

Save ... now there is a sort of a problem. I confess I take the easy way...
every change is saved. Want it back again, change it again.

Good topic, by the way. I wish we as a user group would have a sort of
online symposium to show off examples of what we are doing and (if our skins
are thick enough) get feedback from one another on what we like and don't
alike about what we see.

Bill





More information about the AccessD mailing list