Application User Interface Design Guidelines

Beauty Is Only Skin Deep, But Its What Gets You Asked to Dance!
No matter how good your application is, people wont believe it if it doesnt look good. On the other hand, if your application looks great, people will think it is a good application. Fair? Maybe not. ut it isnt too hard to make your application look as great on the outside as you made it inside. Many of these ideas are our own sub!ective opinions. "se them if you want to, but more importantly, think about how they might apply to your applications, and make your own standards.

Make a Splash
#ou can display a custom logo while your $ccess loads. %f you name a bitmap the same name as your mdb file &#our$ppName.bmp' and put it in the same folder, it will be displayed instead of the $ccess startup screen &(his works in $ccess )* and later'. $lso, the first screen inside your application should be a splash screen that shows at least the application name, clients company name, version number, and your company name.

Easy on the Colors

+ont use a lot of colors on your screens. ,e always use the windows default background color &often set to gray' for our backgrounds. ,e only use white for the background of changeable fields. (o test, change your color scheme to something different and look through your screens to make sure there isnt any gray left. "se red sparingly. ,e use red for the fore color of the -.it button, but almost nowhere else.

Let Me Out of Here!

/rovide an easy, but safe, e.it from most of your screens. ,e put an -.it button on most screens, always in the same place. %t calls a function that asks if the user really wants to e.it the application. "sers like this a lot. +ont put this button on a screen where the user hasnt completed a particular action.

Speak in a Low, Calm Voice

"se e.clamation points very sparingly. %ts likely that nothing in your application is e.citing enough to warrant one. +ont let the user think you e.cite easily. (he message 0Order processing completed successfully12 tells the user that youre surprised that it finally worked. $lways end sentences with periods. %t looks more polished to say3 /roducts sales forecasts have been completed. than /roducts sales forecasts have been completed

Wheres hat !utton" Whats #t $o"

e consistent with button placement, si4e and color. -.it and 5lose buttons should always be in the same places on the screen. /rovide $lt keys for all buttons. Make them consistent1

66766768

9 : ;treet (echnology, %nc.

www.:;treet(ech.com

Hi%e hose Screens

<ide previous screens as you drill down, unless the ne.t one is directly related to the previous one and you open it in +ialog mode. +ont let the user click between open forms in most circumstances= they may get lost or take actions you didnt plan for.

Separate &ecor% 'in%in( from &ecor% E%itin(

,hen you need to edit records, dont !ust dump the user straight into the detail form where the poor 0alphabetically first2 record always appears. %nstead, build an in>between 0inde.2 form showing all the records, read>only, one row at a time. ,hen the user double>clicks on a row, open a detail form that allows the user to edit that particular record only. #ou can make this even fancier with other features, like sorting by a column when the user clicks the heading, using a 0Find2 utility, and using 0+?+2 buttons to move between records on the detail form. (hese all take some e.tra time to develop, but you may decide its worth it.

$rillin( for $ollars

,hen rows of information are displayed and there is more detail available, always allow the user to double> click anywhere in the row, including the record selector. #ou can respond to the record selector double>click by putting the code in the Forms double>click event procedure. ;ome people dont like to double>click. $ccommodate them by putting a button underneath the list, titled something clever like 0+etail2 or 05hange2. ,e always make it the left>most button, so users can see at a glance what will happen when they double>click. +ont make the information in the row changeable. ;ince the user needs to drill down to see the entire record, let them change the information there only.

Check )our Linka(e

#ou already have a split database that has a separate front>end and back>end, right? ,ell, dont let the user see an 0invalid table2 message. 5heck your table links every time you start your application. (here are some common routines out there to check table links, or you can write your own.

ranslate the *(ly $elete Messa(es

+epending on how 0slick2 you want your application to be, you may want to replace the messages $ccess gives you when you delete records with a friendlier versions of your own. #ou can confirm deletions for each record or for a whole group, and you can prevent $ccess messages from appearing. (his takes a bit more work, but it sure looks more professional. "se wording like 0$re you sure you want to delete product ,idget6@*?2

rap )our Errors!

#ouve heard this a hundred times &hopefully', but its important. #ou should have error handling in every module. #ou can get fancy with it, but at least display a message bo. indicating the error number and description, then gracefully e.it the procedure.

66766768

9 : ;treet (echnology, %nc.

www.:;treet(ech.com