>I was wondering of what do you think of a menu with long list (18 items)?
>
>I have 18 lookup tables in the application. And I need to provide user with ability to maintain these tables. Each table has a form (with Edit/Delete/Add,etc.). So I am thinking of having the following tree on the main menu:
>File -> Miscellaneous Table Maintenance -> Table 1, Table 2, and so on.
>
>Is the above reasonable; to have 18 items on the menu? TIA.

In my experience as a user, I hate long menus. Specially the menus which vanish on click, so I have to remember where I left off, instead of the software doing the remembering for me. Imagine your user wants to do ten out of your 18 - after seven, if not earlier, he will not be able to remember which was the last one he did. The phone rang, the coffee arrived, colleague sent an interesting utube link... he'll be lost.

Specially that activating anything from a menu requires at least two clicks and strictly vertical-horizontal mouse movement (if you accidentally click outside the menu, you clicked for nothing - you'll have to find your way through the menu again), and chances are you didn't put your 18 bars straight into the top menu, so it's click-down-click-side-click for each one of them.

Under FPD, the menus were smart enough (and modal, though) so they stayed open until you explicitly clicked elsewhere in the menu, or outside the menu system altogether (on _screen, that is). Under Windows, one misclick and you're lost (and Word tried to fix this by hiding rarely used bars, but started hiding them right away, before you accumulated any significant usage for it to measure, so you were lost right away).

So... menu for only the basic orientation, and for things which are traditionally stored there (help/about, File menu, Edit menu and such). For anything else, you're better off with a switchboard form, a toolbar or any other GUI.