I need a Professional Opinion about Form Design

[JesseL]

I am designing some forms right now for my database, and I would like some professional opinions regarding colors and fonts. I know what a attractive form looks like, but i do not know how to do any custom colors or anything. I would just want my forms to look professional.. Can i get some insight on this please

thanks
ksharp

 

[SeeJane]

Most of this is personal preference, and you'll get a dozen answers from a dozen people. The "right" answer is whatever looks nice to you.

As far as fonts go, Both Tahoma and Verdena look good on monitor screens around 8-10 pt (Tahoma is the narrower of the 2 if you are looking to save space).

I like Blues-blue gray as far as colors go, but there are lots of options out there. Just be careful of bright colors (they will make you eyeballs hurt if you need to be looking at the screen for a long time). To make a custom color...
1. Go to the properties dialog for the section (the gray bar at the top that reads "Detail"
2. In the format tab, look for the line that reads "back color" (there will be a long number there, can be either pos or neg)
3. Click the far right of the box to get an ellipsis
4. In the "color" dialog that pops up, choose "define custom colors
5. Drag the icon on the wide diagram to get hue, drag the arrow on the narrow daigram to get darkness/brightness).
6. When you're happy, click ok. The color will go into effect as soon as you close the properties dialog

When you choose a color, make sure you check it out on all the machines that will show the form. The same color can look great on one screen, and hideous on another.

Hope this helps you out,
CJ

 

[JesseL]

I went to a website called

http://www.justgetproductive.com,

and I notices that the forms they created were very professional looking. They had alot of fancy things on there forms, and I noticed that all their forms were created using MS Access 2000. I have MS Access 2002, and I have no idea where they got those colors from to create there forms. How did they get these colors?

:0
ksharp

 

[SeeJane]

I wasn't able to get onto the site, but chances are they used custom colors. If I were you I'd just go into the color dialog and experiment.

Good luck,
CJ

 

[JesseL]

Thanks CJ.. Your right, experimenting with the colors and such is a better way for me to learn.


ksharp

 

[SeeJane]

You're welcome. And keep checking out other forms to figure out what you do and don't like. Designing forms is actually sort of fun.

CJ

 

[markphsd]

Here's my thoughts on form design.

After you have been working on the form for a while, you'll start to see orgnization patterns. Start grouping things, building navigation bars on the corners or sides. Design around function. Play around with the different options until you get familiar with them, then just think about them before you start laying out your form. Try out conditional formating, thats one of the cooler features avalible. Keep your colors consistent, use colors to help draw attention to areas and increase understanding and memory retention of db functions by new users.

Don't forget to make splash screen. Make sure you put your name all over the db so people will know its your db; or make a cool logo and put it in the corner of every form would be appropriate--name recognition is highly important.

 

[CVigil]

(This is really long! Just warning you. Reading back over this, I'm prompted to say that if anyone thinks that this question and my answer are appropriate for a FAQ, I'm open to that. I'm not sure myself. And I don't know if there's a way to "convert" this to a FAQ once I've submitted this to the Forum. I'm also prompted to say that you may want to copy and print it from a word processor, and read it over a doughnut and a cup of Mountain Dew -- or your beverage of choice.)

First, SeeJane's earlier answers are good.

Next... The original question asked about forms. But most of this topic applies equally well to reports, and much applies equally well to other database objects. But I'll just go on carelessly saying "forms" throughout the rest of this post, and you should understand where else it applies intuitively.

Also, the original poster asked about colors & fonts, but I'm going to go a ways beyond that to address professionalism in the application's whole look & feel. I do think that this addresses the original poster's intent as well as their specific words. It will certainly also be good for some future reader(s).

To add to SeeJane's mention of the Color common dialog: In Access 97 at least (the version I am currently using here), there are also six textboxes in the Define Custom Colors section of the Color common dialog: Hue/Sat[uration]/Lum[inosity] and Red/Green/Blue. I list them like that because they are two sets of three numbers in each set; each set represents a numerical way to define a color. You can use the sliders to fairly quickly get to the range of color you want, which is good. However, both for fine tweaking of the color, and for consistency (reproducing the exact same color in multiple places), I recommend using either the H/S/L or R/G/B textboxes, too. When you do, note that if you make a change in one set, one or more of the values in the other set will change; because they are two different ways of representing the same colors, if you change the color, you change both representations and changing one representation is changing the other. I find that most people without art training understand the R/G/B numbers best. Like mixing different lights, you can set the amount of each color to a value from 0 (least) to 255 (most). 0/0/0 is black. 255/255/255 is white. 255/0/0 is red (all red, or "pure" red). 150/0/0 is a darker red. Any combination of R/G/B numbers all the same gives a color somewhere between black and white, inclusive -- mostly shades of grey. Red + Blue = Purple, so 255/0/255 is "pure" purple. Anyway, making little changes in these numbers (and/or in the S/H/L numbers)is a good precise way to tweak colors. And I find remembering a set of three short numbers (an RGB number) is easier than remembering the long numbers that Access stores as the value in various color properties. In fact, sometimes I just remember a single short number like 216: As a visual cue to the Access Developer, I always use a specific shade of yellow (close to "ToolTip Yellow&quot for the background of any control on a form that has its .Visible property permanently set to False (invisible controls). I can't right now tell you the color number for the specific yellow that I use, or even the RGB number; but I can tell you that when I don't want to open another form to copy and paste the color value, I open the Color common dialog, select the sort-of pale yellow in the second column, first row, then change the Blue value (the bottom one in the R/G/B set) to 216. The Red and Green stay whatever they are for the yellow from the standard button I pushed. I only remember the 216 for my custom color.

Additional feedback from me...

CONSISTENCY
-----------
The concept "professional" usually includes the concept "consistent". This does not mean that every instance of a single object type is absolutely identical to its counterparts in look & feel. It does mean maintaining similar look & feel for similar objects, and it does mean following the same *reasoning* when making similar choices. Even when your choices vary, then, they will be consistent.

For instance, if you have to exactly reproduce an official company form, down to the last detail, then all of your "look" design choices have been made for you by the designer of the original form. (Some of your "feel" -- how the form behaves and how the user uses it -- choices are still up to you.) You would use the same fonts, the same lines, the same colors, the same arrangement and spacing, and so on, as on the original form -- however professionally or unprofessionally it was designed, and however well or poorly it matches the rest of your database design if the rest of the database came first. This is an absolutely uninteresting and irrelevant case, because in it, you do not get to influence the professionalism of the look at all. Uninteresting and irrelevant, but still instructive: sometimes, you don't get your way.

But let us suppose that you need to reproduce an official company form on the computer, but that you are given leeway with the visual design, so long as it is substantially similar and gets the information into the computer in the right way.

(My current supervisor does that all the time for me. "Here, give me this XYZZY form in Access, will you? ... And oh, yeah, since you're always asking me -- No, I don't care what font you use or what text size, as long as I can read it. And this ingredients section with 6 blank lines to be filled in -- instead of 6 fields, just make it so the user just adds as many lines as they have to fill in, one new line for each ingredient they enter [perfect case for a subform and an extra table -- Editor.].&quot

I'm especially willing to make changes when I know that my form from Access will *replace* the old form. There won't be different-looking forms out in common use, then. (Consistency outside the database is good, too ;-) !)

And if there are similar-function forms in my database, I'll try to make them look similar to each other. External Inspection Sheets and Internal Inspection Sheets sound like good candidates for uniformity, don't they? Even if no other form in the database contains pictures, and these do, we can still make these two forms consistent in their treatment of the pictures. And if the two original forms had the pictures at the top and bottom of the pages, respectively, maybe I can put the pictures at the top of both Access forms for consistency within the database.

(My supervisor actually asked me what the picture was doing at the bottom of the second form when I was asked to develop it long after the first had been in frequent use here. When I told him that that's where the picture was on the official second form he handed me, he just responded, "Oh..." When he gets the chance to review it more than glance at it, I'll be asking him about moving the picture, and a few other things.)

Some specific tips & thoughts regarding consistency follow. (And occasionally, other things which add to professionalism will be thrown in.)



Relating Look & Feel
To Function And Object Type:
----------------------------
In general, objects of the same type with the same function should look the same and behave the same. In many cases, similar objects, or objects with similar functions, should look and behave as similarly as possible or practical. The visual and behavioral clues help the user realise that "these things are the same (or similar)". And they often help the user be more comfortable with your application.

"This thing looks like a spreadsheet grid," my friend Rich A. says to me, "so why doesn't it act like a spreadsheet? Why can't I use the arrow keys to move up and down between rows?" Good question, Rich! And when he asked me, I gave him the answer, "Because it isn't actually a spreadsheet; it just looks like one. The look is something I can change independently of what the stuff on the form is." But, having been given the idea, I also looked around for a way to change the behavior to match what he expected. I found the answer here on Tek-Tips and in a book called *Access 97 Developer’s Handbook Third Edition*, so I didn't have to recreate the code myself. But I gave him what he originally expected, and now I'm Rich's hero, "This is so much easier, and I'm not frustrated by this anymore." (It would have seemed more professional if the professional choice had been made from the start, even if Rich wouldn't have noticed. In software at companies, we often don't consciously notice professional qualities and features because we generally expect them.)

What are a few of the lessons do we learn from the previous example with Rich?
1) Expectations are sometimes set by the look. "If it looks like a WidgetX, then I expect it to act like a WidgetX." And this *can* work in your favor. If it is your own brand new WidgetX, and people recognise it by look throughout your application, then they'll know what to expect from a WidgetX anywhere it appears, after learning what to expect from it in one place.
2) And expectations for our work are sometimes set by others' work. In my case, Microsoft set Rich's expectations for my work, because my repeating records on a subform looked to him like an Excel spreadsheet. (Looked that way to me, too, but I just knew better.) So I made it behave "more like the original", since I could. In another case, my supervisor told me that the current functionality of a control was fine, but that I needed to make the control in question look different so it wouldn't fool him into thinking he could do other things with it. We both opted for this simplest way out.
3) ***Added functionality sometimes adds professionalism, too. "A professional fulfills our (reasonable) expectations." (See? I'm hitting on more than just consistency occasionally.) If you wrote a Windows application that didn't allow Cut/Copy & Paste -- for no discernible reason -- would your friends and coworkers think it was very professional? "If it is everywhere, it must be easy to do." This is also why I almost always leave .Locked controls still .Enabled, even if I set the .TabStop property to No. A given user might not be allowed to change the standard description for one of our parts, but they still might have plenty of reasons to want to copy and paste it elsewhere! So I let them use their mouse to select what they want, so that they can copy it. I often hate running into text I can't copy and paste elsewhere, especially as a "lazy developer"!

Some of this "the same function should breed the same look, and the same look should indicate the same function" concept is reiterated below in other specific topics.



Fonts & Colors:
---------------
(Because fonts always have the attribute of color -- even if we sometimes and often just rely on black as a default that we don't think about -- and because color is often integral to a font's use, I've lumped Fonts & Colors together in this single topic. Color is used for far more than just fonts, though, so remember that they really are different topics.)

Try to use the same sets of fonts and colors throughout your forms (and reports and queries-that-the-user-will-see-directly and...). (You *can* change the look & feel of tables and query grids and their header text, at least in Access 97; look through the help and right-click on column headers.)

On this note, in general it is better to use TrueType fonts than non-TrueType fonts. A TrueType font's look is more consistent, comparing screen output to printer output, and you will need to do less adjustment yourself to get prints to look like the screen.

Choosing commonly-used fonts for most objects is a good idea, because you are making choices consistent with the outside world, too ("commonly-used fonts&quot. For you, the relevant "outside world" might be the whole world, your country, your company, your division or department, your school's publications, your other family member's web-sites, published Windows software, your own other software, your industry, or almost anything else. What context will your end-users have in mind as they look at and use your software?

Strictly personal font choices: I like A) Tahoma, B) Times New Roman, and C) Courier New.
A) Tahoma is good for most stuff in my databases and computer applications. I like the look of it, and it is soft and easily readable; it just looks right on my computer screen, and fine when I print forms and so forth. I tend to use it for MS-Access and Visual Basic because these are the applications that first introduced me to this font, Tahoma.
B) I like Times New Roman for things that need a "business professional" look and/or a font with serifs. It is *the* most standard such font -- at least in my experience, which is, *among other things*, centered in and on the U.S. It is good for (formal) reports that are going to important people in the company, or outside the company. *Sometimes* I'll just use it for the report title and group/section headers and footer & header information, using another font for the detail data (making things stand out visually).
C) Courier New is my only choice (except in the rarest cases) for a monospace font or a font to use on text that will later be used on a computer or terminal that displays text, but does not use fonts. A monospace font is one in which all characters are exactly the same width; these are great for use in tables, some ASCII art, or other circumstances where characters on different lines must line up by position within the line. If the text I am working with will be seen in DOS, on a UNIX dumb terminal, or somewhere else where only the characters themselves will be preserved (NOT their exact shape and size or color or anything else), I use Courier New on my screen. Even when I send e-mail, I *always* send plaintext, and if sending from a PC I use Courier New to display my typing, so that I've got the best idea of what my text will look like when I send it to people who read e-mail in plaintext systems. And *please* don't ask me to read computer code -- where position is often a great aid to legibility -- in a font that isn't monospaced. And even these web pages might be viewed on a dumb terminal, so I mostly use characters to indicate the minimal formatting I include, such as surrounding asterisks to indicate emphasis and smileys that won't be interpreted. And when I include code in my Tek-Tip posts, I do use the code tag to force it to display monospace for greater legibility as code. That way it is monospaced for everyone. Courier New is my choice for these sorts of applications.

Do try to use the same fonts and colors for the same purposes throughout. The set of colors you choose to use is often referred to as a "color scheme", so I suppose that you could also talk about the set of fonts you choose as a "font scheme". It is a good idea to limit the number of elements in each, for most professional applications. And the word "scheme" is like "plan", implying that there is some reasoning in the choices and the use of each. There should be.

Main titles look more professional if they are all the same color, font, size, and style (bold, italic, underline...). Sub-titles or headings could have a different-but-consistent-amongst-themselves look. Buttons look more professional if they are all the same size, and if they use the same size, color, font, and style for their captions, and/or or the same artistic style (a thing harder to define) and color palette for their pictures. And they look more professional if buttons with the same or similar functions have the same look ("look" is short for "size, color, font, style, and whatever else fits, in terms of other visual properties that I've left out&quot.

Example: In one inherited application, I am continuing someone else's development. I took time to go through and set all button captions to the same font, color, style, and size.

Then I found special cases. All buttons that take the user back to the Main Menu still maintain the same font and point size, but are now captioned in bold and red, instead of my default black, so that they stand out more. But this is still consistent within my overall design: most button captions are my default font in black, but "Main Menu" button captions are the same font, bolded and red.

A couple of other "very special function" buttons also get special treatment. Any toggle button for which the user *needs* to be very aware of the current state uses what I call "State:On Green" and what I call "State:Off Red" for font color, which I programmatically change when the state of the toggle button changes.

For all such toggle buttons, I use the identical shade of green and the identical shade of Red; I make sure they are identical by copying and pasting the color values from the property sheet. And I always use the Green when the toggle button is "on", and the Red when the toggle button is "off", regardless of the actual meaning of the toggle button state. When the user sees that shade of green, they know the button is "on" or "down" or "pushed"; when they see that shade of red, they know at a glance that the button is "off" or "up" or " not pushed". Or they're mad at me ;-) .

They know what either of those states mean by reading the text and knowing how to use the form. But the look is consistent. I don't use blue & red on one form, and green & red on another.

And on forms where I use the form header as a sort of "control panel" containing buttons for the form, rather than as part of the form itself, I have set the form headers' BackColor properties to exactly the same shade of pale sky blue, which I think of as a kind of "ignore me a little" blue -- but which, more importantly, sets the form header apart from the rest of the form visually, and gives the user the message that these sections are all used the same way. I also keep the look of the buttons on the control panels consistent, as detailed above.



Text, Captions, Labels,
Descriptions, ControlTips,
And Other Words
(capitalisation):
--------------------------
Use capitalisation consistently, anywhere you see text for display, or for data entry where appropriate. Enforce consistency here where you can.

If you capitalise the first letter in each word of field labels (etc.), you should do so everywhere that there is not an explicit reason to do otherwise. Or if you capitalise the first letter only of "important words", then do so throughout the database, and be consistent about how you decide which words are not important. Meaning that if you decide that "the" is an unimportant word, not deserving of capitalisation (unless it is the first word in a piece of text), treat it as such everywhere and leave it lower-case. Treat every word the same way.

If there are fields where people enter only initials of a person's name, I programmatically capitalise each letter as it is typed (with the KeyPress event) and ignore non-letters. In all such fields. I am enforcing consistency in the way initials are entered. This also allows for consistency when searching for initials. My users finally know that they do not have to (should not) worry about whether or not to include periods or hyphens, or whether to capitalise letters, when searching initials fields. They don't have to worry about how the data entry was done, because I have forced it to be done a certain very specific way.



Text, Captions, Labels,
Descriptions, ControlTips,
And Other Words
(consistency of reference):
---------------------------
Use consistent references for the same thing(s). If something appears more than once, use the same words for it. If two or more buttons do the same thing, they should have the same caption. (Even if one button on one form prints that form, and another button on a different form prints that different form, they both "Print the current form", so both should bear a simple caption like "Print Form".) And so forth.

If a part number is displayed on multiple forms, try to always call it the same thing, or make consistent choices about what you call it. In literature, it is generally considered good to use a variety of words for the same thing(s) to keep readers from getting bored. In literature, it is often A Bad Thing if the hero is always called The Hero and the sword is always called Sword and the horse is always called Trusty Steed. In a database, the parallel cases are A Good Thing. Always use "Part Number" in labels, captions, etc. which apply to a part number, or always use "Part No.", or always use "Part Num.". But try to avoid using all of them (or more) at random. Even spelling it out in full of forms, but abbreviating in reports where the space is too cramped for the full form, is a consistent choice. (Of course, you could always use the abbreviation throughout, too.)

My next point under this heading is best made with a few specific examples. Please extrapolate to the general case for yourself.

1) Consider that "part" might mean "a (part) design", or "all things made according to a (part) design", or "an individual thing made according to a (part) design". The question, "How many new parts did our company make this month?" could mean different things, as could the label "Part Quantities" or "No. Of Parts" on a report meant to answer that question. Having different terms for each of these in your database is a good thing (in fact, not just in what the user sees, but in your own object names and database design). So you might call the design "part". ("We only made Circles and Squares this month, and both are new designs. So we made two new parts this month.&quot You might then call individual things made from the designs "pieces". ("This month we made 2,000 Circles and 312 cases of Squares which each contain 100 Squares, so we made 33,200 new pieces this month. I guess you could say 33,200 parts, but to make it clear and avoid confusion, we should say 33,200 pieces were made.&quot If this example applied to your situation, I'd tell you to be consistent throughout your database about when you refer to either one; say "parts" when you mean "parts" and "pieces" when you mean "pieces". And, of course, educate people about your terminology.

2) Another simpler common example to illustrate the same point: "Address" vs. "Street Address" vs. "Residential Address" vs. "Postal Address" vs. "Business Address" vs. "Street Number". If you use the 3rd, 4th, and 5th of these in different places throughout your database, **do not** use just "Address" or "strAddress" as a field or control name, label, description, caption, or whatever else. Use the full descriptors, so that it is clear on each and every form what you are displaying or what you want entered. It is common for businesses to have different Postal Addresses and Street Addresses, for instance. On the "How To Get To Our Customer's Site" form, label the Street Address field "Street Address". On the "Customer Shipping Information" form, label the Postal Address field "Postal Address".

3) In databases, it is common practice to refer to record numbers in many situations, especially as an artificial primary key. I never name a field numRecordNumber, and I never label a control with "Rec. No." I always use things like numCustomerRecord and "Parts Record No." and "Albums Record Number". So if I ever have to refer to multiple record numbers on the same form, I'll know which is which. And if the rest of the form doesn't make it clear, I'll know what the single record number displayed on the form is, because it is explicitly labeled. (Substitute "ID" for "Record Number" and its variants in this paragraph, and read the paragraph again. Then do the same with "Name" and with "Code". You'll get the idea again, hopefully more forcefully.)

Keep your references consistent and explicit!



Arrangement/Layout:
-------------------
Also try to use consistent arrangements for forms where practical and possible. This is also commonly referred to as "layout".

Try, where practical, to have fields/controls of a consistent size or size-range. And note that sometimes that consistent choice of size might indeed be "exactly the size needed to show the caption or contents of the current control". On a menu of buttons with rows and columns, having all of the buttons be exactly the same size is a consistent choice. So is having all buttons in each given column be the same width, and having all buttons in each given row be the same height. And having all such menus set up the same way is really consistent. Scattering the buttons of different sizes around the menu form at random does not seem to indicate a consistent (or professional) choice; but if you did it once and laid out each such menu form the same way, at least you'd have made the inconsistent choices in a consistent fashion.

Here is an example to support my claim that a consistent choice of size might indeed be "exactly the size needed to show the caption or contents of the current control". I have many forms with a pale blue form header containing nothing but buttons appropriate to the given form. These form headers are "control panels" of a sort (and were mentioned under an earlier heading). The buttons have captions which include "Main Menu", "Return To Part Record Form", "Print Form", "E-mail Form" and so on -- captions of differing widths. On some forms I don't have enough horizontal room to have all of the buttons in the form header be the width of the widest caption in the form header. So instead, I make each button (on all control panels) exactly as wide as it needs to be to display its own caption in a single row, which in every case so far, fits all buttons in the form header into a single row of buttons -- which is something else that I very much wanted. And I put the left-most and right-most buttons the same number of points away from their respective edges, then select all buttons and distribute them evenly, horizontally. So I get the same look on all control panels, with buttons as wide as they need to be and "full justified" across the form width. And the "Main Menu" buttons on all such forms are the same size, because they all have the same caption (as mentioned under an earlier heading). And the "E-Mail Form" buttons on all such forms are the same size. And .. you get the idea. The buttons differ from each other, but still in a consistent (and professional) manner. And the spacing of the control panel buttons differs from form to form, *depending* on which buttons are present on a given form, but that very dependency is what still gives a consistent look to my control panel form headers.

In fact, those control panels themselves give a consistent look to my forms. When I inherited the forms, many buttons inhabited space within the forms' Detail sections, sometimes just "wherever the button would fit". But I moved as many of these as possible up to the form header as described above, in some cases having to add the form header myself to create the control panel. And now the forms that have control panels look more like each other, more consistent, with uniform control panels and "button-free-er" Detail sections. (Some buttons just needed to stay in certain places to give better context for their use, and some were contained on subforms and so couldn't be moved. That's okay, because it still follows a consistent scheme, and the exceptions to the main rule are few.)

And layout consistency also applies to the printed versions of objects. Throughout my databases, I make sure that things like control panels, their controls, screen-related instructions that are irrelevant on a printed form, and so forth have their DisplayWhen property set to "Screen Only". In this way, they appear on the screen where they are needed, but they will never appear on a printed form. There is no need for "Main Menu" or "E-mail Form" buttons to show up on a printed recipe card or on printed workshop instructions. Get the idea?

Try to have fields (and all controls) "line up" in a consistent fashion. On the practical side, arrangement doesn't affect whether the user can enter data or not. But your forms will look more professional if you make consistent choices about the layout.

For instance, any of these arrangements for fields and their labels can work (here's hoping that line-wrap on your browser viewing this web page keeps each of my lines on one line):

    ### XXXXXXXX # XXXXXX
    ##### XXXXX ##### XXXXX
    # XXXXXX ### XXXXXXXX

or

    ###   XXXXXXXX      #     XXXXXX
    ##### XXXXX         ##### XXXXX
    #     XXXXXX        ###   XXXXXXXX

or

      ### XXXXXXXX          # XXXXXX
    ##### XXXXX         ##### XXXXX
        # XXXXXX          ### XXXXXXXX

However, the arrangement on the form can affect legibility, and can affect (or be affected by) overall form size. If the font of field and label are the same, the first of the above three arrangements might be less legible for quick scanning; nothing stands out and a single space isn't the greatest separator. (During design, think about usability, another hallmark of professionalism. It isn't very professional to provide things that can't be used or can't be used easily/comfortably, is it?) The first arrangement might be better than otherwise if either field or label were bolded or set apart some other way. But either of the other two arrangements sets apart the fields and their labels right away using space, and either one makes it much easier to scan the data, ignoring the labels once you know what they are. Horizontal and vertical alignment generally deserve equal attention, too.

Sometimes, the context of the individual form and space available make decisions for you, too. Sometimes you don't have enough room to be generous with empty space around your controls, and you can't change the room available. Okay, then make things fit. But do your best to be consistent about how and when you break your general rules. Or make your new layout your general rule, making other things match the new layout, if it doesn't harm functionality and ease-of-use.



Lines And Other (Strictly)
Graphic Elements:
--------------------------
I've already covered colors, size, arrangements, pictures (on buttons). So why am I mentioning Lines And Other (Strictly) Graphic Elements here? Mainly to point out that they can be an important consideration in your form design as well.

If you use dividing lines between forms, or between sections, or between different parts of your forms within sections, be consistent. (Getting to be a mantra, isn't it?) If your dividing line in one place goes all the way across the available space, they all should. If a dividing line starts at one edge of the available space and stops 90 twips (1/16&quot shy of the other edge, then they all should, and they should all start from the same edge, too. They should be the same color, size, dash style, and weight, too. And they should maintain consistent amounts of space between themselves and the things around them, too, rather than crowding against other screen elements in one place and being a quarter-inch away elsewhere.

If the dividing lines are used differently or to divide different things, then they can differ accordingly, remaining consistent for given usages. You might want a line all the way across to set off a form header from the detail section, and lines a little bit shy of each edge to set off portions of the detail from one another. The differing size makes sense, as might other differing properties.

Think of the same principle when you draw boxes around things. And when you choose a special effect and border-related properties for your controls.

Pictures are the last thing I'll mention here, with a bit about that "artistic style" I mentioned earlier under another heading.

If you grab clip-art from lots of different sources (or carelessly from the same source), you might well wind up with art that has different looks. If you mix photographs with computer-generated images and with scans of Japanese Animations and with black and white stick-figures and with images that use different color palettes and different drawing styles, your application might look like as much of a hodge-podge as the art. Even buttons with images should be consistently colored, and consistently styled. Don't use Picasso as inspiration for the picture on your "Place Order" button, and Monet as inspiration for the picture on your "Invoice" button, especially on the same form. Or maybe that's appropriate (?) for an art gallery's application, where the consistency is having a set of artistic styles used across the board. Art people would possibly appreciate it, anyway. So that you don't think I am only referring to formal art schools, I'll say that even "cartoony" and "kind of realistic" are different enough not to be intermixed too much. And 3-Dimensional and 2-dimensional pictures should not be mixed too much. In general, pick one. Create your own pictures and images if you have to.

The color palette thing I mentioned basically refers to the set of colors used in an individual graphic element (which might even include other graphic elements, say forms and controls). So the same way I was talking earlier about limiting the number of colors in your forms, you might want to limit the colors used in your graphics, or the sets of colors used in your graphics. If everyone else at graduation is in black caps and gowns, the guy who came in all blue and the girl who came in seven-color plaid stand waaaay out, don't they? In a simplified way, that's the kind of concern we have here. If most graphics on your forms use a four-color scheme, with just bold yellow, green, blue, and red, then having some forms with graphics in purple, grey, and orange will probably look weird. And photographs used for the same sorts of things as the four-color art would probably also look weird. For instance, maps of your corporate grounds' different gardens might be nice for the Facilities And Groundskeeping database that tracks the garden arrangements and the plants contained therein. But four-color maps showing simple detail for most of the gardens alongside photos of two of the gardens would look odd. Likewise, two four-color pictures of plants available to order would look poor against photos of all the rest of the plants available. These might do as temporary place-holders, until better (matching) graphics were available, but not as permanent professional choices. (I might even label the temp graphics as temporary.)



----------
IN THE END
----------
The above were certainly just some of the considerations and examples that would be appropriate. But I have to leave sometime ;-> , and these should amply address some of the underlying issues that you might well wish to consider in developing "professional-looking" forms (and etc.).

Before you use a different look and feel for a given form, ask yourself why you are doing so. If you have an answer that satisfies you, then do it. And decide if the new look and feel shouldn't become your new standard.

And, lastly, you are going to make all the final decisions. Art, media, marketing, sales -- all are fields in which people are notorious for wanting *splash*, *pizzazz*. No, theirs and others' are not necessarily the usual business mores and standards. But even while they are being bright, and varied, and *interesting*, they can still be self-consistent, and make their own decisions about exactly where and when to be different. Hopefully, they know their own needs. In this very real way, professionalism is a matter of opinion, and is also in the eye or the designer and each and every beholder.
-- C Vigil =)
(Before becoming a member, I also signed on several posts as
"JustPassingThru" and "QuickieBoy" -- as in "Giving Quick Answers&quot

 

[markphsd]

CVIGil

yah... uh, that's what i said....... in less then ONE Billion words.... i guess you don't leave anything to the imagination.

Excellent work. Something like that should be required reading before developing or learning any layout program.

 

[JesseL]

WowWowow..... I appreciate your insight!

ksharp :/

 

[WildHare]

I agree with virtually everything CVigil wrote, and my feeble attempts at adding to it would be like painting a mustache on the Mona Lisa, so I'll just point you to these two FAQs in this Forms forum I sent here many months ago:

FAQ 720-1743
FAQ 720-1631

and note that I have several sample databases on my site (bottom line on my signature) that illustrate many of these points.

Jim
How many of you believe in telekinesis? Raise my hand...
Another free Access forum:

http://www.forumco.com/jmhare

More Access stuff at

http://www.jmhare.com/wildhare2.htm

 

[SeeJane]

Add me to the list of VERY impressed people. Great work C Vigil!

CJ

 

[maetrix]

I whole-heartedly agree that C Vigil's post should be moved to the FAQ section. His wording is clear, consise and extremely detailed.

All I have to say, C Vigil, is "Thank you." You've have done all us budding programmers a great service.

--Toby Kliem--
Novice Programer
Expert Hack sapere aude: Dare to be wise

 

[Jusenkyo]

I am in the habit of copying Mac OSX screenshots into my form backgrounds. As you all know, this operating system is very pretty, to say the least. So I figured, why try to create something that is already avaliable?

So I past a screenshot into MS Paint, and tweek it to suit my form. Then I put txt boxes behind all of the Mac buttons so that they work , and do whatever. Voila!

A Beutifull form!

 

[Hasse]

Hey, guys,

In case you’re also interested in interface design in general, this might be useful information. If not, this risks to be too theoretical, beyond the scope of the question & more suited for an education/training, but… you never know.

Some web searching offered me the following extra links:

(1)

http://www.uideveloper.com/uideveloper/uidesign.htm

=> discusses a number of recommended books on user interface design, among which:

About Face: The Essentials of User Interface Design
by Alan Cooper
IDG Books Worldwide
580 Pages (August 1995)
ISBN: 1-56884-322-4

The Design of Everyday Things
by Donald A. Norman
Currency/Doubleday
257 Pages (March 1990)
ISBN: 0-385-26774-6

GUI Design for Dummies
by Laura Arlov
IDG Books Worldwide, Inc.
358 Pages (September 1997)
ISBN: 0-7645-0213-1

(2) Also highly recommended by Amazon reviewers:

The Non-Designer's Design Book
by Robin Williams
Paperback: 144 pages
Publisher: Peachpit Press
ISBN: 1566091594; 1st edition (January 15, 1994)

Maybe I would’ve better started reading CVigil’s suggestions in detail first (which I’ll do right now), but as I'm in a hurry & it might take a while before I return, I couldn’t resist sharing this… Sorry I’ve no time to exploit this further, but as at least I for myself wish I’d have some time to read one of those, it might be useful for others as well.

Already & again thanks for your contribution & effort, Vigil!

hans

ps Buy the way, any reference to a book / chapters from a book which apply this subject to VB(A) & Access remain welcome…